La Declaración de Aplicabilidad (SoA) de ISO 27001: qué es y cómo hacerla bien
Si el auditor de certificación solo pudiera pedirte un documento, pediría este. La Declaración de Aplicabilidad (Statement of Applicability, SoA) es la radiografía de tu SGSI: la lista de los 93 controles del Anexo A con la decisión, para cada uno, de si aplica o no, por qué, y su estado de implementación.
Qué exige exactamente la norma
La cláusula 6.1.3 d) pide que la SoA contenga: los controles necesarios (vengan del Anexo A o de cualquier otra fuente), la justificación de su inclusión, su estado de implementación, y la justificación de las exclusiones del Anexo A. Cuatro cosas. Todo lo demás que quieras añadir (responsable, evidencias, referencias a documentos) es opcional pero muy recomendable.
El vínculo que lo sostiene todo: riesgo → control
La SoA no nace de rellenar una plantilla: nace del tratamiento de riesgos. El recorrido lógico es: identificas riesgos, decides tratarlos, eliges controles que los mitigan, y la SoA documenta esa elección. Cuando un auditor encuentra una SoA donde todos los controles están "incluidos" sin conexión con ningún riesgo, sabe que el documento se hizo al revés — copiando el Anexo A entero para no pensar. Es la no conformidad más clásica del capítulo.
Cómo justificar inclusiones sin escribir una tesis
Una línea sincera basta. Buenos ejemplos de justificación: "mitiga los riesgos R-12 y R-15 del registro", "requisito contractual del cliente X", "obligación legal (RGPD art. 32)", "buena práctica ya implantada que se decide mantener". El patrón: cada control incluido apunta a un riesgo, un requisito legal o contractual, o una decisión de negocio explícita.
Cómo excluir controles sin miedo
Excluir es legítimo y esperable: una empresa 100 % remota sin oficinas puede excluir controles físicos; quien no desarrolla software puede excluir los de desarrollo seguro. La regla es que la justificación sea real y verificable: "no aplicable porque no existe desarrollo de software interno ni subcontratado". Lo que no cuela es excluir por pereza controles que sí te tocan ("concienciación: no aplica porque el personal es de confianza" es un clásico del humor auditor).
Los 93 controles y los 4 temas de la versión 2022
Desde ISO 27001:2022, el Anexo A organiza los controles en cuatro temas: organizacionales (37), de personas (8), físicos (14) y tecnológicos (34). Si vienes de la versión 2013 (114 controles en 14 dominios), hay una tabla de correspondencia oficial — pero la SoA hay que reescribirla contra la estructura nueva, no parchearla.
Mantenerla viva (o volver a sufrir cada año)
La SoA se revisa cuando cambian los riesgos, cuando hay incidentes, cuando entran servicios o proveedores nuevos, y como mínimo en cada ciclo de auditoría interna. Consejo práctico: añade columnas de "evidencia de implementación" y "propietario del control". Convierte la SoA de documento burocrático en cuadro de mando del SGSI — y las auditorías de seguimiento pasan de sufrimiento a trámite.
Fórmate para implantarlo tú: en el curso Gestor ISO 27001:2022 + ISO 27701 incluye un módulo específico de SoA con plantilla y el recorrido completo riesgo → control → evidencia.