Declaración de Aplicabilidad (SoA): qué es y cómo se elabora en ISO 27001
Por el equipo de QuantumSec
La Declaración de Aplicabilidad —Statement of Applicability o SoA— es, junto con la política de seguridad, el documento más revisado por cualquier auditor de ISO 27001. Es la prueba escrita de que tu empresa ha analizado los 93 controles del Anexo A uno por uno y ha decidido, con criterio, cuáles aplican y cuáles no. Un SoA copiado de una plantilla genérica es la señal más rápida de que el resto del SGSI tampoco es real.
Qué exige la norma sobre la SoA
La cláusula 6.1.3.d) de ISO/IEC 27001:2022 exige producir una Declaración de Aplicabilidad que contenga: los controles necesarios según el análisis de riesgos, la justificación de su inclusión, si están implementados o no, y la justificación de exclusión de cualquier control del Anexo A que no se aplique. No es opcional ni un anexo decorativo: es un requisito auditable.
Los 93 controles del Anexo A (edición 2022) y sus cuatro categorías
La revisión 2022 reorganizó los antiguos 114 controles en 93, agrupados en cuatro temas: organizativos (37 controles: políticas, roles, relación con proveedores...), de personas (8: teletrabajo, formación, términos de empleo...), físicos (14: perímetro seguro, equipos, cableado...) y tecnológicos (34: control de acceso, criptografía, gestión de vulnerabilidades, desarrollo seguro...). La SoA debe recorrer los 93, no solo los que resulta cómodo aplicar.
Cómo se construye: del análisis de riesgos a la justificación control por control
El proceso correcto parte del análisis de riesgos, no del Anexo A: primero identificas qué riesgos existen y qué tratamiento decides darles (mitigar, transferir, evitar o aceptar); después, para cada riesgo mitigado, identificas qué controles del Anexo A lo abordan. Solo entonces rellenas la SoA marcando ese control como aplicable, con una justificación que cite el riesgo concreto que trata —no una frase genérica de plantilla.
Excluir un control (con justificación) es tan válido como incluirlo
Un error habitual es asumir que "más controles marcados" es mejor. No lo es: un control de criptografía en tránsito que no aplica porque no existe ningún flujo de datos que lo requiera debe excluirse, con esa justificación exacta. Un auditor experimentado detecta enseguida una SoA donde todo está marcado como aplicable sin excepciones: es la señal de que nadie ha hecho el ejercicio real de análisis, solo ha marcado casillas.
FAQ
¿La SoA se revisa una sola vez o hay que actualizarla?
Se revisa cada vez que cambia algo relevante: un nuevo activo, un nuevo riesgo identificado, un cambio de alcance del SGSI, o como mínimo en cada revisión anual del sistema. Una SoA desactualizada frente al análisis de riesgos vigente es un hallazgo típico en auditorías de seguimiento.
¿Podemos usar una plantilla de SoA como punto de partida?
Como estructura, sí. Como contenido, no: cada justificación debe reflejar el análisis de riesgos real de tu organización. Una plantilla con justificaciones genéricas copiadas es exactamente lo que un auditor experimentado detecta y cuestiona en la primera revisión.
¿Quién debe firmar o aprobar la Declaración de Aplicabilidad?
La alta dirección, como parte de su responsabilidad sobre el SGSI (cláusula 5.1 de ISO 27001). No es un documento exclusivamente técnico: implica una decisión de negocio sobre qué riesgos se asumen y cuáles se mitigan.