El Anexo A de ISO/IEC 27001:2022 contiene 93 controles de referencia, agrupados en cuatro categorías: organizacionales, de personas, físicos y tecnológicos. La norma no exige implementar los 93: los controles necesarios se determinan a partir del tratamiento de riesgos y después se comparan con el Anexo A para comprobar que no falta ninguno. Tampoco son un catálogo para elegir a gusto, porque cada inclusión y cada exclusión tiene que justificarse.
Esas decisiones se registran en la Declaración de Aplicabilidad, el documento que conecta los riesgos con los controles; qué contiene y cómo se construye está en Statement of Applicability (SoA) ISO 27001. Este artículo se ocupa de los controles: cómo se organizan, cómo se decide cuáles aplican y qué significa que uno funcione de verdad.
¿Cómo se organizan los 93 controles?
La edición 2022 reemplazó las catorce secciones y los 114 controles de la versión 2013 por cuatro categorías, tomadas de ISO/IEC 27002:2022.
| Categoría | Identificadores | Cantidad | Qué aborda, en términos generales |
|---|---|---|---|
| Organizacionales | A.5.1 a A.5.37 | 37 | Políticas, roles, activos, proveedores, nube, incidentes, continuidad, cumplimiento y privacidad |
| De personas | A.6.1 a A.6.8 | 8 | Selección, condiciones de empleo, concientización, trabajo remoto y reporte de eventos |
| Físicos | A.7.1 a A.7.14 | 14 | Perímetros, acceso físico, protección de instalaciones, equipos y medios |
| Tecnológicos | A.8.1 a A.8.34 | 34 | Identidad y accesos, configuración, malware, vulnerabilidades, respaldos, registro, redes, criptografía y desarrollo seguro |
Este artículo no reproduce los nombres ni los textos de los controles: son material protegido de ISO/IEC 27001:2022 y de ISO/IEC 27002:2022, y la lista oficial se consulta en la publicación de ISO. Lo que sí se puede explicar, y es lo que importa para aplicarlos, es qué tipo de medidas cubre cada categoría:
- Organizacionales: políticas de seguridad y su revisión, roles y segregación de funciones, inteligencia de amenazas, inventario y clasificación de la información, gestión de proveedores y de servicios en la nube, gestión de incidentes, continuidad de las TIC, requisitos legales y contractuales y protección de datos personales.
- De personas: verificación de antecedentes, condiciones del empleo, formación, procesos disciplinarios, responsabilidades al terminar la relación, acuerdos de confidencialidad, trabajo remoto y reporte de eventos.
- Físicos: perímetros y entradas, áreas seguras, equipos dentro y fuera de las instalaciones, medios de almacenamiento, energía y cableado, y escritorio y pantalla despejados.
- Tecnológicos: dispositivos de usuario, privilegios y control de acceso, autenticación, protección contra malware, gestión de vulnerabilidades y de configuración, borrado y enmascaramiento de datos, respaldos, redundancia, registro y monitoreo, seguridad de redes, criptografía y desarrollo seguro.
¿Cómo se determina cuáles aplican?
¿Son obligatorios los 93? No, y tampoco son opcionales en el sentido de "elige los que quieras". Lo que ISO/IEC 27001:2022 exige es un proceso: evaluar los riesgos, decidir su tratamiento, determinar los controles necesarios, compararlos con el Anexo A para verificar que no se omitió ninguno y registrar cada inclusión y cada exclusión con su justificación. La cantidad de controles aplicables es una consecuencia de ese análisis; la lógica completa está en el artículo sobre el SoA.
¿Se pueden excluir controles? Sí, cuando el tratamiento de riesgos muestra que un control no es necesario, y siempre con la justificación registrada. Dos ejemplos hipotéticos: una organización cuyo alcance no incluye desarrollo de software puede excluir los controles de desarrollo seguro, y una sin equipos que operen fuera de sus sedes puede excluir el control de equipos fuera de las instalaciones. En ambos casos la justificación se apoya en el alcance y en los riesgos, y se revisa si cambian.
¿Se pueden usar controles que no están en el Anexo A? Sí. La norma indica que los controles necesarios pueden diseñarse por la organización o identificarse a partir de cualquier fuente, y que el Anexo A no es exhaustivo. Un control de otro marco, exigido por un regulador o diseñado a medida entra al sistema con la misma lógica: trata un riesgo, se justifica y se declara con su estado.
ISO 27001 e ISO 27002: ¿dónde están realmente los controles?
ISO/IEC 27001 es la norma de requisitos del SGSI, la única de las dos contra la que se certifica, e incluye en su Anexo A los 93 controles enunciados de forma breve. ISO/IEC 27002 es la guía: describe cada control con su propósito y orientación de implementación, y es la fuente de la que el Anexo A los toma. Por eso conviven: 27001 obliga a compararse con el Anexo A y justificar la aplicabilidad; 27002 ayuda a entender qué significa cada control y cómo implementarlo, sin contener requisitos certificables.
ISO/IEC 27002:2022 asocia además a cada control cinco atributos: tipo (preventivo, detectivo o correctivo), propiedad de seguridad que protege (confidencialidad, integridad o disponibilidad), concepto de ciberseguridad (identificar, proteger, detectar, responder o recuperar), capacidad operativa y dominio de seguridad. Sirven para filtrar los controles ("cuáles detectan", "cuáles protegen la disponibilidad") y cruzarlos con otros marcos; no son requisitos adicionales de ISO 27001.
Un control no es una herramienta
Un control es una medida que modifica un riesgo. Puede ser un proceso, una política, una responsabilidad asignada, una capacitación, una revisión periódica, una configuración, una medida física, una tecnología o, casi siempre, una combinación de varias. Un producto puede ser parte de un control; rara vez es el control completo.
"Gestionar accesos", por ejemplo, implica una fuente de identidades, un proceso de altas, modificaciones y bajas con aprobaciones, autenticación reforzada donde el riesgo lo justifique, revisión periódica de quién tiene qué y la evidencia de todo eso. Comprar la herramienta de autenticación resuelve una parte; el control es el conjunto.
¿Qué significa implementar un control?
Hay una escalera de estados, y la auditoría los distingue:
- Comprado
- Configurado
- Implementado
- Operando
- Evidenciado
- Efectivo
Comprado es tener la herramienta o haber escrito el procedimiento. Configurado es haberlo ajustado al entorno. Implementado es que cubra el alcance previsto con responsables asignados. Operando es que se ejecute cada vez que corresponde. Evidenciado es que deje registro verificable. Efectivo es que logre el resultado esperado sobre el riesgo que trata.
Un caso hipotético: una organización tiene autenticación multifactor. Antes de declarar el control implementado conviene responder en qué sistemas aplica y en cuáles no, qué identidades cubre, qué excepciones existen y quién las aprueba, cada cuánto se revisa, qué pasa con las cuentas privilegiadas y de servicio, y qué evidencia queda. La herramienta por sí sola no responde nada de eso.
Implementado tampoco significa efectivo: un control puede existir y no cubrir todo el alcance, tener excepciones sin gestionar, no ejecutarse con la frecuencia prevista o no lograr el resultado esperado. Por eso el sistema no termina en la implementación: la medición, la auditoría interna y la revisión por la dirección existen para detectar controles que están pero no funcionan, y la mejora continua para corregirlos. Cómo encaja cada pieza está en ¿Qué es un SGSI y cómo funciona según ISO 27001?.
¿Cómo se demuestra que un control funciona?
Con la evidencia que produce su operación: registros de altas y bajas, tickets, logs, configuraciones exportadas, reportes de respaldo y de pruebas de restauración, aprobaciones, actas de revisión, constancias de capacitación o métricas, según el control. No existe una lista universal de evidencias obligatorias; la norma exige que la organización determine qué monitorear y medir y conserve la información documentada como evidencia de los resultados.
La regla práctica es una: la evidencia es el resultado verificable de la operación, no documentación creada para la auditoría. Si hay que producirla antes de una auditoría, el control no estaba operando.
Ejemplo: del riesgo al control
Un caso hipotético, no una receta. El riesgo: acceso indebido a información crítica de clientes por cuentas que nadie gestiona. El tratamiento: reducir la probabilidad de acceso no autorizado. Los controles necesarios: un proceso de gestión de accesos con responsables y revisiones, más autenticación reforzada y registro de accesos en los sistemas del alcance. La evidencia: los tickets de altas y bajas, las actas de revisión y los registros de acceso. La evaluación: comprobar que el proceso cubre todos los sistemas del alcance, que las revisiones se hicieron y que las excepciones están aprobadas y vigentes.
Cada control tiene así un porqué, un dueño, una operación y una forma de demostrarse. Un catálogo de controles desconectado del análisis de riesgos no es un SGSI.
Errores frecuentes al trabajar con los controles
- Empezar por los 93 controles antes de entender los riesgos.
- Implementarlos todos "por si acaso", con el costo y la evidencia que eso exige.
- Excluir controles sin justificación, o copiar los controles y sus justificaciones de otra organización.
- Confundir una tecnología con un control.
- Declarar implementado algo que no opera, o generar la evidencia solo antes de la auditoría.
- No revisar los controles cuando cambian los riesgos o el alcance, y perder la trazabilidad entre riesgos, SoA y controles.
Por dónde empezar
No por una lista de 93 casillas. Por el alcance, después los riesgos, después el tratamiento, después los controles necesarios y la Declaración de Aplicabilidad, y recién entonces la implementación y la evidencia. El sistema completo está en ¿Qué es un SGSI? y el proceso paso a paso en Cómo implementar ISO 27001 en Chile.
Si los controles ya existen y la pregunta es cuántos están de verdad en el escalón de "efectivo" y cuántos en el de "comprado", un Gap Assessment los revisa uno por uno dentro del alcance: aplicabilidad, implementación, operación, evidencia y dependencias.
¿No sabes todavía qué tan preparado está tu SGSI?
Una primera lectura, en quince preguntas
Nivel estimado de preparación para ISO/IEC 27001:2022, incluidos controles, evidencia y gestión de riesgos. Sin registro. Es orientativo y no sustituye un Gap Assessment ni una auditoría.
Preguntas frecuentes
¿Cuántos controles tiene ISO 27001:2022 y cómo se agrupan?
El Anexo A contiene 93 controles de referencia, tomados de ISO/IEC 27002:2022, en cuatro categorías: 37 organizacionales (A.5), 8 de personas (A.6), 14 físicos (A.7) y 34 tecnológicos (A.8). La edición 2013 tenía 114 controles en catorce secciones.
¿Hay que implementar los 93 controles?
No necesariamente, y tampoco se eligen libremente. La norma exige determinar los controles necesarios desde el tratamiento de riesgos, compararlos con el Anexo A y justificar en la Declaración de Aplicabilidad cada inclusión y cada exclusión.
¿Se pueden excluir controles del Anexo A?
Sí, cuando el tratamiento de riesgos muestra que un control no es necesario y la justificación queda registrada en la Declaración de Aplicabilidad. La justificación se apoya en el alcance y en los riesgos, y el auditor evalúa si es defendible.
¿Puedo usar controles que no estén en el Anexo A?
Sí. ISO/IEC 27001:2022 indica que los controles pueden diseñarse o tomarse de cualquier fuente y que el Anexo A no es exhaustivo. Un control propio o de otro marco entra al sistema con su justificación y su estado.
¿Cuál es la diferencia entre ISO 27001 e ISO 27002?
ISO/IEC 27001 contiene los requisitos certificables del SGSI e incluye el Anexo A con los 93 controles enunciados brevemente. ISO/IEC 27002 es la guía que describe cada control con su propósito, orientación de implementación y atributos; no contiene requisitos obligatorios y no es certificable.
¿Un control es siempre una tecnología?
No. Muchos controles son organizacionales, de personas o físicos, y los tecnológicos casi siempre necesitan un proceso, responsables, revisiones y evidencia alrededor de la herramienta. La norma no prescribe productos ni tecnologías concretas.
¿Existe un checklist oficial de los 93 controles?
No como herramienta de cumplimiento. El Anexo A lista los controles de referencia, pero la norma no lo concibe como una lista para marcar: exige determinar los controles necesarios desde los riesgos y justificar cada decisión en la Declaración de Aplicabilidad.
Fuentes
- ISO/IEC 27001:2022, Information security management systems. Requirements: el proceso de tratamiento de riesgos, la determinación de controles necesarios desde cualquier fuente, la comparación con el Anexo A, la Declaración de Aplicabilidad, y el Anexo A con sus 93 controles en cuatro categorías.
- ISO/IEC 27002:2022, Information security controls: la guía de los 93 controles con su propósito, orientación de implementación y los cinco atributos.
- ISO/IEC 27005:2022, Guidance on managing information security risks: la orientación sobre evaluación y tratamiento de riesgos que antecede a la selección de controles.
Este artículo parafrasea la estructura y la lógica de ISO/IEC 27001:2022 e ISO/IEC 27002:2022 sin reproducir el texto, los nombres oficiales ni la orientación de los controles, que son material protegido de ISO. Las descripciones por categoría, los ejemplos y la escalera de estados corresponden a la metodología de JanusNet, empresa de ciberseguridad en Chile que acompaña la implementación de SGSI sin actuar como organismo certificador.