Declaración de Aplicabilidad (SoA): qué es y cómo se elabora en ISO 27001

Por Kike Gandia · Co-Fundador y CEO, OSCP

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.

Qué columnas tiene una SoA que aguanta una auditoría

La norma dice qué información debe contener, no cómo maquetarla. En la práctica, la estructura que menos preguntas genera en auditoría es una tabla con cinco columnas, y lo que la hace creíble es la cuarta y la quinta. Un ejemplo con controles reales del Anexo A de la edición 2022:

Control	¿Aplica?	Justificación	Estado	Evidencia
5.7 Inteligencia de amenazas	Sí	Riesgo R-04: ataques dirigidos al servicio expuesto a internet	Implementado	Procedimiento de seguimiento de avisos y registro de revisiones
5.23 Seguridad para el uso de servicios en la nube	Sí	Toda la plataforma se aloja en un proveedor cloud	Implementado	Matriz de responsabilidad compartida y contrato del proveedor
7.4 Monitorización de la seguridad física	No	No hay CPD propio; la oficina no aloja sistemas del alcance	No aplica	Alcance del SGSI y contrato de alojamiento
8.11 Enmascaramiento de datos	Sí	Riesgo R-11: uso de datos reales en entornos de prueba	En implantación	Plan de tratamiento, hito con fecha y responsable
8.23 Filtrado web	No	Los puestos no acceden a la red interna del alcance	No aplica	Diagrama de red y política de dispositivos

Dos detalles que marcan la diferencia. El primero: la justificación cita el riesgo concreto por su identificador, lo que permite al auditor recorrer el camino inverso desde la SoA hasta el análisis de riesgos en segundos. El segundo: la columna de estado distingue entre implementado y en implantación, con fecha en el plan de tratamiento. Declarar todo como implementado cuando no lo está es un hallazgo seguro, porque el auditor va a pedir la evidencia de dos o tres controles al azar.

SoA y plan de tratamiento de riesgos no son el mismo documento

Se confunden constantemente y son dos entregables distintos que el auditor va a pedir por separado. La SoA es una fotografía por control: para cada uno de los 93 del Anexo A, si aplica, por qué y en qué estado está. El plan de tratamiento de riesgos es una fotografía por riesgo: para cada riesgo identificado, qué decisión se ha tomado (mitigar, transferir, evitar o aceptar), qué acciones concretas se van a ejecutar, con qué responsable, con qué plazo y con qué riesgo residual esperado. Uno mira controles, el otro mira riesgos, y ambos deben ser coherentes entre sí: cada control marcado como aplicable en la SoA debería poder rastrearse hasta al menos un riesgo del plan, y cada riesgo mitigado debería apuntar a los controles con los que se mitiga. La incoherencia entre ambos documentos es de los hallazgos más frecuentes en una primera certificación, y también de los más fáciles de evitar si se construyen a la vez y no uno después del otro.

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.

¿En qué formato se entrega y cuánto ocupa?

Lo habitual es una hoja de cálculo con una fila por control y control de versiones, porque es el formato con el que trabaja el auditor y el que permite filtrar y comentar. La extensión depende de la longitud de las justificaciones, no del tamaño de la empresa: siempre son 93 filas. Lo que sí varía es el detalle: en una organización pequeña, una justificación de una o dos líneas por control es suficiente si cita el riesgo y la evidencia.

¿Se le puede enseñar la SoA a un cliente que la pide?

Se puede, pero conviene pensarlo antes: la SoA describe con precisión qué controles no tienes implantados y por qué, que es información sensible en manos de un tercero. Lo habitual es compartirla bajo acuerdo de confidencialidad, o entregar en su lugar el certificado con su alcance, que es lo que suele resolver la petición. Si el cliente insiste en la SoA, es señal de que está haciendo una evaluación de proveedor seria y merece la pena preguntarle qué necesita comprobar exactamente.

¿Qué pasa si añadimos un servicio nuevo a mitad de ciclo?

Se revisa primero si el servicio queda dentro del alcance certificado. Si queda dentro, hay que actualizar el análisis de riesgos, revisar si el cambio activa controles que estaban excluidos —el caso típico es empezar a tratar datos en un país nuevo o incorporar un proveedor cloud— y reflejarlo en la SoA con fecha. El auditor de seguimiento compara la SoA con la del año anterior: un cambio de arquitectura sin ningún rastro en la SoA es justo lo que le hace mirar más de cerca.

¿Cuánto se tarda en elaborarla desde cero?

Recorrer los 93 controles con criterio lleva varias sesiones de trabajo repartidas en semanas, no días, y la razón no es la redacción: es que cada control obliga a comprobar qué se hace realmente y quién lo hace. Ese recorrido es, en la práctica, el diagnóstico más completo que va a tener la organización, y por eso conviene hacerlo al principio del proyecto y no como último trámite antes de la auditoría.