Declaración de Aplicabilidad ISO 27001:2022: qué es y cómo prepararla

Qué es la Declaración de Aplicabilidad

ISO/IEC 27001 pide a la organización que evalúe sus riesgos de seguridad de la información y decida cómo tratarlos. Tratar un riesgo suele significar aplicar controles. La Declaración de Aplicabilidad es el registro formal de esa decisión, y la exige el apartado 6.1.3 de la norma, dedicado al tratamiento de los riesgos.

El razonamiento que pide la norma tiene tres pasos:

1. Determinar los controles necesarios para aplicar el tratamiento de riesgos elegido. Pueden salir de cualquier fuente, no solo del Anexo A.
2. Comparar esos controles con el Anexo A para comprobar que no se ha omitido ninguno necesario. El Anexo A es una lista de referencia, no exhaustiva.
3. Elaborar la Declaración de Aplicabilidad con el resultado.

La edición vigente es ISO/IEC 27001:2022, con su modificación de 2024 sobre cambio climático, que añade a los apartados 4.1 y 4.2 la reflexión sobre si el cambio climático es una cuestión relevante. En España se publica como UNE-EN ISO/IEC 27001:2023, y la modificación como UNE-EN ISO/IEC 27001:2023/A1:2024.

Qué debe contener

La norma exige que la Declaración de Aplicabilidad recoja, como mínimo, cuatro elementos. Dicho con nuestras palabras:

1. Los controles necesarios, tanto los del Anexo A como los adicionales que la organización haya decidido.
2. La justificación de su inclusión: por qué se necesita cada uno (un riesgo, un requisito legal o contractual, una decisión de la dirección).
3. Si están implantados o no.
4. La justificación de excluir cualquier control del Anexo A.

En la práctica casi todas las organizaciones añaden columnas: responsable, referencia a la evidencia o al procedimiento, fecha prevista para los controles pendientes y relación con los riesgos que mitiga.

Los 93 controles del Anexo A

En la edición de 2022 los controles del Anexo A se reorganizan en cuatro temas, que se corresponden con los apartados 5 a 8 del anexo:

ISO/IEC 27002:2022, la guía que desarrolla cada control, añade además atributos para filtrarlos y agruparlos: tipo de control (preventivo, detectivo, correctivo), propiedades de seguridad (confidencialidad, integridad, disponibilidad), conceptos de ciberseguridad (identificar, proteger, detectar, responder, recuperar), capacidades operativas y dominios de seguridad. Son útiles para presentar la SoA desde otros ángulos, pero no forman parte de lo que exige la 27001.

Qué cambió respecto a 2013

Los 11 controles nuevos cubren áreas que en 2013 apenas aparecían:

Cómo preparar la SoA paso a paso

1. 1

   Cierra el alcance

   Qué procesos, sedes, sistemas y servicios entran en el SGSI. La SoA solo tiene sentido dentro de un alcance definido.
2. 2

   Evalúa los riesgos

   Con una metodología documentada: activos o escenarios, amenazas, vulnerabilidades, probabilidad e impacto. Es la base de casi todas las justificaciones.
3. 3

   Decide el tratamiento

   Para cada riesgo por encima de tu criterio de aceptación: mitigar, evitar, transferir o aceptar. Al mitigar, elige los controles concretos.
4. 4

   Contrasta con el Anexo A

   Recorre los 93 controles. Para cada uno, ¿lo necesitas por un riesgo, por la ley, por un contrato? Si no, documenta por qué no aplica.
5. 5

   Registra el estado y la evidencia

   Implantado, en implantación (con fecha y plan) o no implantado, y dónde está la prueba: política, procedimiento, registro, configuración.
6. 6

   Aprueba y versiona

   La SoA es información documentada: debe tener versión, fecha y aprobación, y revisarse cuando cambien los riesgos o el alcance.

Anatomía de una SoA

Cuatro filas de una SoA ficticia. Los números de las columnas remiten a los cuatro elementos obligatorios descritos antes:

Exclusiones: cómo justificarlas

Excluir un control del Anexo A es legítimo, pero es justo lo primero que mira un auditor. Una buena justificación:

• se apoya en un hecho verificable («no hay desarrollo externalizado»), no en una opinión («no es prioritario»);
• es coherente con el resto del sistema: si un riesgo del registro necesita ese control, la exclusión no se sostiene;
• se revisa cuando cambian el alcance o los riesgos.

SoA en ISO 27001 y en el ENS

Si trabajas con el sector público, el Esquema Nacional de Seguridad (Real Decreto 311/2022) exige su propia Declaración de Aplicabilidad (artículo 28), referida a las medidas de su anexo II y firmada por el responsable de la seguridad. No es el mismo documento que la SoA de ISO 27001, aunque gran parte del trabajo se reutiliza. El CCN publica la guía CCN-STIC 825 con la correspondencia entre ISO/IEC 27001:2022 y el ENS.

Qué revisará el auditor

• Que cada control incluido tenga una justificación trazable hasta un riesgo o un requisito.
• Que las exclusiones sean coherentes con la evaluación de riesgos.
• Que el estado declarado coincida con la realidad: si dice «implantado», pedirá la evidencia.
• Que la SoA esté aprobada, versionada y alineada con el plan de tratamiento de riesgos.

¿Quieres profundizar en cómo puntuar los riesgos que justifican cada control? Lee la guía de riesgo inherente y residual.

Preguntas frecuentes