Si ISO/IEC 27001:2022 es el qué —el sistema de gestión que exige identificar riesgos, tratarlos y mejorar de forma continua—, ISO/IEC 27002:2022 es el cómo: el catálogo detallado de controles de seguridad de la información con su propósito, su orientación de implementación y su «otra información» asociada. Ningún auditor certifica una organización «contra» ISO 27002 —esa norma no es certificable por sí sola—, pero ningún SGSI serio sobrevive a una auditoría de certificación sin haberla usado a fondo para construir la Declaración de Aplicabilidad (SoA) que exige el Anexo A de ISO 27001.
La edición de 2022 no es un simple lavado de cara: reestructuró de arriba abajo un catálogo que llevaba desde 2013 organizado en 14 dominios y 114 controles, y lo convirtió en 93 controles agrupados en solo 4 temas, con un sistema de atributos que permite mirar el mismo catálogo desde ángulos distintos (por tipo de control, por propiedad de seguridad, por función NIST…). Este módulo te lleva por esa reestructuración, por los controles nuevos que reflejan ocho años de evolución de las amenazas —nube, teletrabajo, fuga de datos, ingeniería de configuración— y por un recorrido representativo de los cuatro temas, para que sepas exactamente qué documento abrir cuando tengas que justificar o descartar un control en tu SoA.
Qué aprenderás
- Qué es ISO/IEC 27002:2022, cuál es su relación exacta con ISO/IEC 27001:2022 y por qué no es una norma certificable.
- La reestructuración de 2013 a 2022: de 114 controles en 14 dominios a 93 controles en 4 temas, con las cifras exactas por tema.
- Los 5 atributos que introduce la edición de 2022 y para qué sirven en la práctica (filtrado, mapeo a otros marcos, informes a dirección).
- Los 11 controles completamente nuevos de 2022, con su número, nombre y motivo de incorporación.
- Un recorrido con ejemplos representativos de cada uno de los 4 temas: organizacionales, personas, físicos y tecnológicos.
- Cómo se traduce cada control de ISO 27002 en una línea de la Declaración de Aplicabilidad (SoA) de tu SGSI.
- Los errores más habituales al usar el catálogo: aplicarlo entero sin priorizar por riesgo, y confundir «tema» con «obligatoriedad».
Qué es ISO/IEC 27002:2022 y en qué se diferencia de ISO/IEC 27001
ISO/IEC 27002:2022, Information security, cybersecurity and privacy protection — Information security controls, se publicó el 15 de febrero de 2022, unos meses antes que la revisión correspondiente de ISO/IEC 27001:2022 (25 de octubre de 2022). Esto no es casualidad: 27002 tenía que estar lista primero porque el Anexo A de 27001 —la lista resumida y numerada de controles que un SGSI debe evaluar— se limita a citar el nombre y el número de cada control; es 27002 quien explica en qué consiste, por qué existe y cómo se implementa.
La relación exacta entre las dos normas
Conviene ser preciso aquí porque es una de las confusiones más frecuentes en las entrevistas y en los exámenes de certificación:
- ISO/IEC 27001 es la norma de requisitos de un SGSI. Es la única de las dos que es certificable: un organismo acreditado audita tu sistema de gestión y emite (o no) el certificado. Su Anexo A enumera 93 controles con su número y nombre, pero sin desarrollo.
- ISO/IEC 27002 es una guía de implementación (en la terminología ISO, un «código de buenas prácticas» o code of practice). Para cada uno de esos 93 controles ofrece cuatro elementos: control (qué se exige, en una frase), propósito (por qué existe, el «objetivo» que sustituye a los antiguos objetivos de control agrupados de 2013), orientación (guidance: cómo implementarlo, con detalle práctico) y otra información (referencias cruzadas, notas, matices).
- Nadie se certifica «en» ISO 27002. Lo que se certifica es el SGSI conforme a ISO 27001, y dentro de esa auditoría el auditor comprueba que los controles del Anexo A que declaraste aplicables en tu SoA están bien seleccionados, bien justificados y bien implementados —y para juzgar «bien implementados» el auditor usa, precisamente, el desarrollo de ISO 27002 como vara de medir.
En otras palabras: 27001 te dice que necesitas un control de acceso; 27002 (control 5.15) te explica qué debe cubrir una política de control de acceso, qué principios seguir (mínimo privilegio, necesidad de conocer, segregación de funciones) y qué aspectos documentar. Sin 27002 delante, escribir una SoA rigurosa es prácticamente imposible.
La reestructuración de 2022: de 114 controles en 14 dominios a 93 controles en 4 temas
La edición de 2013 organizaba los controles en 14 dominios (A.5 Política de seguridad, A.6 Organización, A.7 Recursos humanos, A.8 Gestión de activos… hasta A.18 Cumplimiento), con 35 objetivos de control y 114 controles. Era una estructura que había envejecido: mezclaba criterios organizativos con criterios temáticos, no reflejaba conceptos como la nube o el teletrabajo masivo, y no permitía mapear fácilmente los controles a marcos más modernos como el NIST Cybersecurity Framework.
La edición de 2022 sustituye esos 14 dominios por 4 temas (en inglés, themes) y reduce el total a 93 controles: 11 son completamente nuevos, 24 resultan de fusionar controles antiguos que se solapaban, y los 58 restantes se mantienen pero con texto revisado. La tabla siguiente resume la distribución exacta, que conviene memorizar porque aparece en cualquier examen de Lead Implementer o Lead Auditor:
| Tema | Cláusula en ISO 27002:2022 | Nº de controles | Qué cubre en esencia |
|---|---|---|---|
| Organizacionales (Organizational) | Cláusula 5 | 37 | Políticas, roles y responsabilidades, gestión de activos, control de acceso, relación con proveedores, gestión de incidentes, continuidad, cumplimiento legal. |
| Personas (People) | Cláusula 6 | 8 | Selección, condiciones de contratación, concienciación y formación, procesos disciplinarios, teletrabajo, notificación de eventos. |
| Físicos (Physical) | Cláusula 7 | 14 | Perímetros de seguridad, control de entrada, protección de oficinas y salas, cableado, mantenimiento de equipos, escritorio y pantalla limpios. |
| Tecnológicos (Technological) | Cláusula 8 | 34 | Dispositivos de usuario, gestión de accesos privilegiados, protección contra malware, copias de seguridad, redes, criptografía, desarrollo seguro. |
| Total | 93 | — | |
Un matiz que se pregunta mucho en las auditorías: el «tema» no implica jerarquía ni orden de importancia. Que Organizacionales tenga 37 controles y Personas solo 8 no significa que el bloque de personas sea «menos crítico» —de hecho, el error humano sigue siendo el vector de entrada más citado en los informes de incidentes del sector—; simplemente hay menos controles catalogables bajo ese tema porque muchos aspectos de «personas» (por ejemplo, la política de teletrabajo) se solapan y se han fusionado con controles organizacionales o tecnológicos.
Los atributos: cinco formas nuevas de mirar el mismo control
La novedad estructural más profunda de 2022, más incluso que la reducción a 4 temas, es la introducción de atributos (attributes). Cada uno de los 93 controles lleva asociado un conjunto de valores en cinco categorías de atributo, publicadas también como tabla resumen en el Anexo A informativo de la propia ISO 27002:2022. La idea es que el mismo catálogo de controles se pueda «recortar» y presentar de formas distintas según para quién sea el informe, sin tener que reescribir nada.
Los 5 atributos y su utilidad práctica
| Atributo | Valores posibles | Para qué sirve |
|---|---|---|
| Tipo de control (Control type) | Preventivo, Detectivo, Correctivo | Distingue si el control evita que ocurra el incidente, lo detecta cuando ya está ocurriendo, o corrige/recupera después de que ha ocurrido. Útil para comprobar que tu SoA no está desequilibrada (por ejemplo, todo preventivo y nada detectivo). |
| Propiedades de seguridad de la información (Information security properties) | Confidencialidad, Integridad, Disponibilidad | Indica qué pilar(es) de la tríada CIA protege principalmente el control. Ayuda a comprobar cobertura: ¿tienes controles suficientes para disponibilidad, o todo está sesgado a confidencialidad? |
| Conceptos de ciberseguridad (Cybersecurity concepts) | Identificar, Proteger, Detectar, Responder, Recuperar | Mapea cada control a las cinco funciones del NIST Cybersecurity Framework. Es el puente directo para justificar ante dirección o ante un cliente que exige NIST CSF que ya lo estás cubriendo vía ISO 27002. |
| Capacidades operativas (Operational capabilities) | Gobierno, gestión de activos, protección de la información, seguridad de RRHH, seguridad física, seguridad de sistemas y redes, seguridad de aplicaciones, configuración segura, gestión de identidad y acceso, gestión de amenazas y vulnerabilidades, continuidad, seguridad en relaciones con proveedores, cumplimiento legal, gestión de eventos, aseguramiento de seguridad de la información | Es la vista «de gestor de seguridad»: agrupa los controles por la capacidad operativa del día a día que sostienen, con independencia del tema al que pertenezcan formalmente. |
| Dominios de seguridad (Security domains) | Gobierno y ecosistema, Protección, Defensa, Resiliencia | Una vista de muy alto nivel, orientada a comités de dirección y a comparar el catálogo con otros marcos de gobierno de seguridad a nivel corporativo. |
En la práctica, estos atributos se explotan sobre todo con herramientas (hojas de cálculo o software GRC) que permiten filtrar y pivotar la tabla de 93 controles. Por ejemplo, si un consejo de administración pregunta «¿cómo estamos de preparados para detectar un incidente?», puedes filtrar por atributo «Tipo de control = Detectivo» y por «Conceptos de ciberseguridad = Detectar», y mostrar en segundos qué controles de tu SoA cubren esa capacidad y cuáles no.
Los 11 controles nuevos de la edición 2022
Ocho años separan la edición de 2013 de la de 2022, y en ese tiempo cambió radicalmente el terreno de juego: la nube pasó de ser una opción a ser el modelo de despliegue por defecto, el teletrabajo se generalizó tras 2020, la fuga de datos y el ransomware se convirtieron en el riesgo operativo número uno para la mayoría de organizaciones, y el desarrollo de software se aceleró con metodologías ágiles y DevOps que exigen seguridad integrada desde el código, no añadida al final. Los 11 controles nuevos son la respuesta directa del comité técnico a ese cambio de contexto:
| Número | Nombre | Tema | Por qué se añadió |
|---|---|---|---|
| 5.7 | Inteligencia de amenazas | Organizacional | Formaliza la recopilación y el análisis de información sobre amenazas (indicadores de compromiso, TTPs, campañas activas) para anticipar ataques, algo que en 2013 era una práctica emergente y hoy es estándar en cualquier SOC. |
| 5.23 | Seguridad de la información para el uso de servicios en la nube | Organizacional | En 2013 la nube apenas se mencionaba. Este control cubre todo el ciclo de vida: selección, contratación, uso y baja de servicios cloud, y se apoya en normas complementarias como ISO/IEC 27017 (controles cloud) e ISO/IEC 27018 (datos personales en la nube). |
| 5.30 | Preparación de las TIC para la continuidad de negocio | Organizacional | Separa explícitamente la continuidad «de negocio» (procesos, personas) de la continuidad «de las TIC» (infraestructura, sistemas), reconociendo que la dependencia tecnológica de cualquier proceso crítico es hoy total. |
| 7.4 | Supervisión de la seguridad física | Físico | Exige vigilancia activa y continua (CCTV, sistemas de alarma, personal de seguridad) de las áreas sensibles, no solo controles de entrada pasivos como en 2013. |
| 8.9 | Gestión de la configuración | Tecnológico | Formaliza el establecimiento, la documentación, la implementación, la supervisión y la revisión de configuraciones seguras de hardware, software, servicios y redes, clave para evitar el «configuration drift» que explota tanto el atacante oportunista. |
| 8.10 | Borrado de información | Tecnológico | Responde directamente a las exigencias del RGPD (derecho de supresión) y a la necesidad de eliminar datos de forma verificable e irreversible cuando ya no son necesarios, no solo «borrarlos» a nivel de sistema de archivos. |
| 8.11 | Enmascaramiento de datos | Tecnológico | Cubre técnicas como la seudonimización o el enmascaramiento dinámico para reducir la exposición de datos sensibles en entornos de prueba, desarrollo o analítica, en línea con el principio de minimización del RGPD. |
| 8.12 | Prevención de fuga de datos (DLP) | Tecnológico | La fuga de datos —accidental o intencionada— es hoy uno de los escenarios de riesgo más citados en cualquier análisis MAGERIT; este control formaliza las medidas técnicas (DLP) para detectarla y bloquearla. |
| 8.16 | Actividades de supervisión | Tecnológico | Exige monitorización continua de redes, sistemas y aplicaciones para detectar comportamiento anómalo, el fundamento de cualquier capacidad SOC/SIEM moderna. |
| 8.23 | Filtrado web | Tecnológico | Gestiona el acceso a sitios web externos para reducir la exposición a malware y contenido malicioso, una medida que en 2013 se daba por hecha vía proxy pero que no estaba formalizada como control propio. |
| 8.28 | Codificación segura | Tecnológico | Formaliza los principios de secure coding a lo largo del ciclo de desarrollo, reflejo directo del auge de DevSecOps y de la necesidad de integrar la seguridad desde el diseño del software, no como una revisión final. |
Fíjate en el patrón: 8 de los 11 controles nuevos son tecnológicos. No es casualidad —es la cláusula que más ha tenido que renovarse para reflejar nube, DevOps y protección de datos avanzada—, y es un dato que conviene tener presente al leer la tabla de distribución por temas: aunque Tecnológicos «solo» tiene 34 de los 93 controles totales, concentra la mayor parte de la novedad normativa de esta edición.
Recorrido por los cuatro temas con controles representativos
No es realista (ni el objetivo de este módulo) desarrollar los 93 controles uno a uno —para eso está la norma oficial, con su propósito y orientación completos—. Lo que sí puedes llevarte de aquí es un recorrido por 3-4 controles representativos de cada tema, suficiente para entender el nivel de detalle y el tipo de decisión que vas a tomar al construir tu SoA.
Organizacionales (cláusula 5, 37 controles)
Es el bloque más extenso porque recoge todo lo que no depende de un dispositivo, una persona concreta o un espacio físico: la capa de gobierno, gestión de activos, control de acceso lógico a nivel de política, gestión de proveedores, gestión de incidentes y cumplimiento legal.
- 5.1 Políticas de seguridad de la información. Exige que exista una política de seguridad de la información y políticas específicas por tema, aprobadas por la dirección, comunicadas y revisadas periódicamente o ante cambios significativos. Es, en la práctica, el control «raíz»: sin política aprobada por dirección, el resto del SGSI carece de mandato formal.
- 5.9 Inventario de información y otros activos asociados. Obliga a mantener un inventario actualizado de la información y de los activos que la procesan (hardware, software, servicios), con un propietario asignado a cada activo. Es la base de cualquier análisis de riesgos serio: no puedes analizar el riesgo de un activo que no sabes que existe.
- 5.15 Control de acceso. Fusiona varios controles de la edición 2013 en uno solo: exige que las reglas de acceso a la información y a los recursos se establezcan e implementen según los requisitos del negocio y de seguridad, aplicando principios como el mínimo privilegio y la necesidad de conocer.
- 5.24 Planificación y preparación de la gestión de incidentes de seguridad de la información. Exige roles, responsabilidades y procedimientos definidos antes de que ocurra un incidente, no improvisados durante la crisis —el terreno que desarrolla en profundidad nuestro curso de DFIR: respuesta a incidentes.
Personas (cláusula 6, 8 controles)
El tema más corto en número, pero uno de los que más impacto tiene sobre el riesgo real: la mayoría de brechas de seguridad siguen implicando, en algún punto de la cadena, un error o una decisión humana.
- 6.1 Selección. Exige verificaciones de antecedentes proporcionales al puesto (confidencialidad de la información a la que va a acceder, criticidad del rol) antes de contratar, respetando siempre la legislación laboral y de protección de datos aplicable.
- 6.3 Concienciación, educación y formación en seguridad de la información. Obliga a que todo el personal —empleados y también terceros relevantes— reciba formación periódica y actualizada, alineada con las políticas y procedimientos de la organización. No basta con un curso de bienvenida el primer día: la norma exige actualización continua.
- 6.7 Trabajo remoto. Formaliza las medidas de seguridad que se aplican cuando el personal trabaja fuera de las instalaciones (VPN, cifrado de dispositivo, políticas de red doméstica), un control que en 2013 apenas existía y que hoy es prácticamente universal.
- 6.8 Notificación de eventos de seguridad de la información. Exige que exista un mecanismo simple y conocido para que cualquier persona pueda reportar un evento sospechoso, y que sepa que debe hacerlo cuanto antes: la primera línea de detección en cualquier organización es su propia plantilla.
Físicos (cláusula 7, 14 controles)
Cubre todo lo que tiene una dimensión de espacio: perímetros, salas, cableado, equipos y el comportamiento del personal en el puesto de trabajo físico.
- 7.1 Perímetros de seguridad física. Exige definir y usar perímetros de seguridad para proteger áreas que contienen información y otros activos asociados: vallas, puertas controladas, recepción con control de acceso.
- 7.2 Controles de entrada física. Va más allá del perímetro: exige que las áreas seguras estén protegidas por controles de entrada y puntos de acceso apropiados, con registro de quién entra y cuándo, y acompañamiento de visitantes.
- 7.7 Escritorio despejado y pantalla despejada. Un control aparentemente menor pero que aparece en prácticamente todas las no conformidades de auditoría: exige políticas de «mesa limpia» para papeles y soportes extraíbles, y de «pantalla limpia» (bloqueo automático) para los equipos informáticos.
- 7.10 Soportes de almacenamiento. Regula la gestión de los soportes extraíbles a lo largo de su ciclo de vida: adquisición, uso, transporte y eliminación segura, alineado con el control tecnológico 8.10 de borrado de información.
Tecnológicos (cláusula 8, 34 controles)
El tema más extenso tras Organizacionales, y el que concentra la mayoría de controles nuevos, como se ha visto. Cubre dispositivos, identidad, redes, criptografía y desarrollo.
- 8.5 Autenticación segura. Exige que las tecnologías y procedimientos de autenticación se implementen según las políticas de control de acceso, cubriendo desde la robustez de contraseñas hasta la autenticación multifactor (MFA) para accesos privilegiados o remotos.
- 8.7 Protección contra malware. Exige protección contra código malicioso combinada con una adecuada concienciación de usuario, y no se limita al antivirus tradicional: cubre listas blancas de aplicaciones, control de macros y análisis de contenido.
- 8.16 Actividades de supervisión (nuevo, ya visto en la tabla anterior). Es el control que sostiene técnicamente la detección temprana y conecta de forma directa con las capacidades de threat hunting y respuesta que se trabajan en el curso de DFIR: respuesta a incidentes.
- 8.24 Uso de criptografía. Exige reglas para el uso eficaz de la criptografía, incluyendo la gestión de claves: cuándo cifrar en reposo, cuándo en tránsito, qué algoritmos y longitudes de clave son aceptables, y cómo se protegen y rotan las claves.
- 8.28 Codificación segura (nuevo). Formaliza principios de desarrollo seguro que cualquier equipo que aplique pruebas de intrusión sobre aplicaciones propias reconocerá al instante; es el terreno que profundiza nuestro curso de Hacking Web desde la perspectiva ofensiva, el complemento perfecto para entender qué falla cuando este control no se aplica bien.
De ISO 27002 a la Declaración de Aplicabilidad (SoA)
El puente entre «leer ISO 27002» y «tener un SGSI auditable» es la Declaración de Aplicabilidad (Statement of Applicability, SoA), el documento obligatorio que exige la cláusula 6.1.3 d) de ISO/IEC 27001:2022. La SoA es, en esencia, una tabla con una fila por cada uno de los 93 controles del Anexo A, y para cada uno:
- Indica si el control es aplicable o no aplicable a tu organización, con justificación en ambos casos (que no aplique 7.2 «Controles de entrada física» porque toda tu infraestructura es cloud y no tienes oficina propia es una justificación válida; omitirlo sin explicación no lo es).
- Si es aplicable, indica el estado de implementación (implementado, parcialmente implementado, planificado) y la referencia al documento, procedimiento o evidencia que lo soporta.
- Enlaza el control con el riesgo o los riesgos que trata, cerrando el círculo con la evaluación de riesgos previa (ver los módulos de análisis y tratamiento de riesgos de este mismo curso).
Aquí es donde ISO 27002 se vuelve indispensable: cuando un auditor pregunta «¿por qué habéis marcado el control 8.23 (filtrado web) como implementado?», la respuesta no puede ser «porque tenemos un proxy» —tiene que remitir a la orientación de implementación de 27002 para ese control y demostrar que la implementación real cubre lo que esa orientación describe. Sin haber leído el desarrollo completo del control en 27002, es fácil marcar algo como «implementado» cuando en realidad solo cubre una parte de lo que el control exige.
Caso práctico
Un despacho de abogados mediano (80 empleados, infraestructura mixta on-premise y cloud, sin desarrollo de software propio) está construyendo su primera SoA. El consultor de GRC le pide clasificar cinco controles recién revisados, asignando tema, tipo de control y propiedad de seguridad principal según los atributos de ISO 27002:2022. Así quedaría el ejercicio resuelto:
| Control | Tema | Tipo de control | Propiedad CIA principal | Justificación breve |
|---|---|---|---|---|
| 5.9 Inventario de activos | Organizacional | Preventivo | Confidencialidad / Integridad / Disponibilidad (las tres) | Sin inventario no se puede proteger nada: es la base que sostiene el resto de controles, por eso toca las tres propiedades a la vez. |
| 7.7 Escritorio y pantalla despejados | Físico | Preventivo | Confidencialidad | Evita que expedientes de clientes queden visibles o accesibles sobre la mesa o en pantallas desbloqueadas. |
| 8.12 Prevención de fuga de datos (DLP) | Tecnológico | Detectivo / Preventivo | Confidencialidad | Bloquea (preventivo) o alerta (detectivo) ante intentos de exfiltrar expedientes o correo con datos de clientes fuera del perímetro autorizado. |
| 6.3 Concienciación y formación | Personas | Preventivo | Confidencialidad / Integridad / Disponibilidad (las tres) | Reduce la probabilidad de phishing exitoso y de errores de manejo de información, con impacto transversal en las tres propiedades. |
| 8.13 Copias de seguridad de la información | Tecnológico | Correctivo | Disponibilidad | No evita el incidente (un ransomware puede cifrar igualmente los sistemas), pero permite recuperar el servicio: es el control que da sentido al RTO/RPO del despacho. |
Nota cómo el ejercicio obliga a razonar, no a memorizar: 5.9 y 6.3 tocan las tres propiedades CIA porque son controles «de base» que sostienen a todos los demás, mientras que 7.7 y 8.12 son claramente de confidencialidad, y 8.13 es puramente de disponibilidad porque actúa después del incidente, no antes.
Errores comunes
- Intentar implementar los 93 controles sin priorizar por riesgo. ISO 27002 no exige que apliques todos los controles: exige que justifiques cada exclusión en la SoA a partir de tu análisis de riesgos. Organizaciones que se lanzan a «marcar todo como aplicable» para «ir sobre seguro» terminan con una SoA inflada, imposible de sostener con evidencias reales, y que en la auditoría de certificación genera más no conformidades que una SoA más corta pero bien razonada.
- Confundir «tema» con «obligatoriedad» o con «orden de prioridad». Que un control esté en el tema «Tecnológico» no lo hace ni más ni menos obligatorio que uno del tema «Personas»; los cuatro temas son una clasificación editorial para facilitar la navegación del catálogo, no una jerarquía de importancia ni de riesgo. La prioridad la marca siempre tu evaluación de riesgos, nunca la posición del control en la tabla.
- Copiar la SoA de otra organización o de una plantilla genérica de internet. Los atributos y la orientación de 27002 son genéricos por diseño: la Declaración de Aplicabilidad tiene que reflejar el contexto, los activos y los riesgos concretos de tu organización. Una SoA «de plantilla» sin adaptar es una de las banderas rojas más fáciles de detectar para un auditor experimentado.
- Tratar ISO 27002 como si fuera certificable por sí sola. Es un error conceptual que aparece a menudo en ofertas comerciales poco rigurosas («te certificamos en ISO 27002»). No existe tal certificado: lo que existe es la certificación del SGSI conforme a ISO/IEC 27001, apoyada en la implementación de los controles que desarrolla ISO 27002.
Ejercicio
Coge tres controles de ISO/IEC 27002:2022 que consideres relevantes para tu organización (o para un caso ficticio de una pyme que gestiona datos de clientes en la nube) y, para cada uno, redacta una entrada de Declaración de Aplicabilidad completa: (1) número y nombre del control; (2) aplicable / no aplicable, con justificación; (3) tema y atributo de tipo de control (preventivo/detectivo/correctivo); (4) referencia a la evidencia o al documento que soportaría su implementación en un caso real (por ejemplo, «Política de copias de seguridad v2, revisada trimestralmente»); (5) el riesgo concreto que ese control mitiga. Si tienes dudas sobre si un control es preventivo o detectivo, pregúntate: ¿actúa antes de que el incidente ocurra, o después de que ya ha empezado a ocurrir?
Preguntas frecuentes
¿Puedo certificarme en ISO/IEC 27002:2022?
No. ISO 27002 es una guía de implementación, no una norma de requisitos de sistema de gestión, y por tanto no existe un certificado «ISO 27002». Lo que se certifica es el SGSI conforme a ISO/IEC 27001:2022, apoyándose en los controles que ISO 27002 desarrolla en detalle para justificar la Declaración de Aplicabilidad.
¿Tengo que implementar los 93 controles obligatoriamente?
No. ISO 27001 exige que evalúes los 93 controles del Anexo A frente a tu análisis de riesgos y documentes en la SoA cuáles aplican y cuáles no, con justificación en ambos casos. Un control puede quedar marcado como «no aplicable» de forma perfectamente legítima si tu contexto lo justifica (por ejemplo, controles de seguridad física en una organización cien por cien remota y sin oficina propia).
¿Qué diferencia hay entre un «objetivo de control» de la edición 2013 y el «propósito» de la edición 2022?
En 2013, los 114 controles se agrupaban bajo 35 objetivos de control compartidos entre varios controles a la vez. En 2022 se elimina esa capa intermedia: cada uno de los 93 controles tiene su propio elemento de «propósito» (purpose) individual, que explica de forma directa por qué existe ese control concreto, sin depender de un objetivo compartido con otros controles del mismo grupo.
¿Los atributos son obligatorios en la SoA?
No, la norma no exige que tu Declaración de Aplicabilidad incluya los cinco atributos de ISO 27002. Son una herramienta opcional pensada para facilitar vistas y filtrados del catálogo (por tipo de control, por función NIST, etc.), muy útil en informes a dirección o en el mapeo hacia otros marcos, pero la exigencia normativa de ISO 27001 se limita a indicar aplicabilidad, justificación y estado de implementación.
Si ya tenía una SoA basada en la edición 2013 (114 controles), ¿qué tengo que hacer?
Tienes que hacer una transición mapeando cada control antiguo a su equivalente (o equivalentes, en el caso de fusiones) en el catálogo de 93 controles de 2022, revisando de nuevo la aplicabilidad y la justificación de cada uno, y actualizando referencias y evidencias. Los organismos de certificación han fijado plazos de transición para las organizaciones certificadas contra la edición de 2013; conviene comprobar con tu entidad certificadora el plazo concreto aplicable a tu certificado.
«ISO/IEC 27002:2022 — Information security, cybersecurity and privacy protection — Information security controls» es la norma internacional publicada por ISO/IEC JTC 1/SC 27 el 15 de febrero de 2022, disponible en su versión oficial a través de iso.org.