La ISO 27001 es la norma internacional de referencia para gestionar la seguridad de la información, y dentro de su sistema de gestión la Declaración de Aplicabilidad es uno de los documentos más importantes. Es lo primero que revisa el auditor cuando llega la certificación y el punto donde se conecta todo lo que la organización ha decidido hacer para proteger su información.
En este artículo verás qué es la SoA, para qué sirve, qué debe contener y cómo elaborarla paso a paso, con un ejemplo de tabla para que veas cómo queda.
¿Qué es la Declaración de Aplicabilidad (SoA) de la ISO 27001?
La Declaración de Aplicabilidad, conocida como SoA por sus siglas en inglés (Statement of Applicability), es el documento que recoge todos los controles de seguridad del Anexo A de la ISO 27001 e indica, para cada uno, si la organización lo aplica o no, con su justificación y su estado de implementación.
Dicho de otro modo, es la foto completa de qué controles ha decidido implantar tu organización, cuáles ha dejado fuera y por qué. En la versión vigente de la norma, la ISO 27001 de 2022, el Anexo A reúne 93 controles agrupados en 4 temas, así que la SoA repasa esos 93 controles uno por uno.
Conviene no confundir la SoA con el análisis de riesgos. El análisis de riesgos identifica a qué amenazas está expuesta la organización, mientras que la SoA recoge la decisión sobre qué controles se aplican para tratar esos riesgos. Son documentos distintos que trabajan juntos, y más abajo verás cómo se conectan.
¿Para qué sirve y por qué es obligatoria?
La SoA cumple varias funciones dentro del SGSI, pero hay tres que explican por qué es tan importante:
- Es un documento obligatorio para certificarse: la propia norma lo exige. La cláusula 6.1.3 d de la ISO 27001 de 2022 obliga a elaborar una Declaración de Aplicabilidad que contenga los controles necesarios, la justificación de por qué se incluyen, si están implementados o no y el motivo por el que se excluye cualquier control. Sin SoA no hay certificación posible.
- Conecta el análisis de riesgos con los controles: la SoA es el puente entre los riesgos que has identificado y las medidas que has puesto en marcha para tratarlos. Gracias a ella se ve la trazabilidad entre lo que pide la norma y lo que realmente hace la organización.
- Es la guía principal del auditor: cuando llega la auditoría, el auditor abre la SoA antes que ningún otro documento, porque le da el mapa completo del SGSI. A partir de ella comprueba que los controles que dices aplicar están de verdad implementados y que las exclusiones tienen sentido. Una SoA floja, sin justificaciones o con exclusiones sin fundamento, es una de las vías más rápidas a una no conformidad.
¿Qué debe contener la SoA?
La norma no impone un formato concreto, así que puedes usar el que mejor te encaje siempre que recoja la información necesaria. Para cada uno de los controles del Anexo A, la SoA debe reflejar cuatro cosas:
-
El control y su descripción: la referencia y el nombre del control tal como aparece en el Anexo A, por ejemplo A.5.1 Políticas de seguridad de la información.
-
Si aplica o no aplica: la decisión de incluir o excluir ese control en tu SGSI.
-
La justificación: el motivo de esa decisión, tanto si el control se aplica como si se descarta. Este punto es clave, porque justificar las exclusiones es lo que más revisa el auditor.
-
El estado de implementación y las evidencias: si el control está implantado, en desarrollo o pendiente, junto con la referencia a la política, el procedimiento o la evidencia que lo respalda.
Muchas organizaciones añaden columnas extra, como el responsable del control o el riesgo que trata, para reforzar la trazabilidad. No es obligatorio, pero ayuda a mantener el documento bajo control.
Ejemplo de tabla de una SoA
Así suele quedar una Declaración de Aplicabilidad en formato de tabla. Este es un ejemplo simplificado con unos pocos controles para que veas la estructura.
| Control | Descripción | ¿Aplica? | Justificación | Estado | Evidencia |
|---|---|---|---|---|---|
| A.5.1 | Políticas de seguridad de la información | Sí | Riesgo identificado en el análisis de riesgos | Implementado | Política de SI v1.2 |
| A.5.7 | Inteligencia de amenazas | Sí | Necesidad de anticipar amenazas externas | En desarrollo | Procedimiento de inteligencia de amenazas |
| A.6.7 | Trabajo en remoto | Sí | Parte de la plantilla trabaja fuera de la oficina | Implementado | Política de teletrabajo v2.0 |
| A.7.4 | Supervisión de la seguridad física | No | La organización no dispone de instalaciones propias | No aplica | Justificación documentada |
| A.8.23 | Filtrado web | Sí | Riesgo de acceso a sitios maliciosos | Implementado | Configuración del proxy corporativo |
¿Cómo hacer una Declaración de Aplicabilidad paso a paso?
Elaborar la SoA no es un trámite aislado, sale de forma natural del trabajo previo de gestión de riesgos. Estos son los pasos habituales para construirla.
1. Haz primero el análisis y el tratamiento de riesgos
La SoA no es el punto de partida, sino la consecuencia del trabajo de riesgos. Antes de tocarla necesitas tener identificados tus activos de información, evaluados los riesgos a los que están expuestos y decididas las opciones de tratamiento para cada uno. En ese momento es cuando se ve con claridad qué controles hacen falta para mitigar cada riesgo.
Si intentas rellenar la SoA sin este trabajo previo, acabarás marcando controles a ciegas y el auditor lo detectará enseguida, porque no habrá trazabilidad entre los riesgos identificados y los controles elegidos.
2. Selecciona los controles aplicables del Anexo A
Con los riesgos sobre la mesa, recorres los 93 controles del Anexo A de la versión 2022 y decides cuáles aplican a tu organización y cuáles no. La norma no obliga a implantarlos todos, solo aquellos que tu nivel de riesgo justifique, así que un control puede quedar fuera si no tiene sentido en tu contexto.
Ten en cuenta también que puedes añadir controles adicionales que no estén en el Anexo A si tu análisis de riesgos lo pide, ya que el Anexo A es una referencia y no una lista cerrada.
3. Documenta la justificación, el estado y las evidencias
Para cada control anotas si aplica o no y el motivo de esa decisión. En los que aplican, añades su estado de implementación, si está implantado, en desarrollo o pendiente, y la referencia a la política, el procedimiento o la evidencia que lo respalda.
No te saltes la justificación de las exclusiones, porque es justo lo que más revisa el auditor. Excluir un control es perfectamente válido siempre que expliques por qué no aplica a tu organización. Un motivo bien redactado vale más que una lista de controles marcados sin explicación.
4. Revisa y aprueba el documento
Por último, la SoA debe revisarse y aprobarse por la máxima autoridad de seguridad de la organización antes de darla por válida. Esa aprobación formal es la que convierte el borrador en el documento de referencia del SGSI.
A partir de ahí queda lista para la auditoría, aunque conviene recordar que no es una versión definitiva para siempre, sino la primera de muchas, porque la SoA se irá actualizando con el tiempo.
¿Cómo mantener y gestionar la SoA?
La SoA no se elabora una vez y se archiva. Es un documento vivo que hay que revisar y actualizar cada vez que cambia algo relevante en la organización, por ejemplo cuando aparece un riesgo nuevo, se incorpora un activo o una tecnología, cambia el contexto normativo o se modifica una decisión de tratamiento. Por eso conviene llevar un control de versiones que registre cada cambio y quién lo aprobó.
Aquí es donde muchas organizaciones se atascan. Mantener la SoA en una hoja de cálculo se vuelve inmanejable en cuanto tienes decenas de controles activos con sus responsables, sus evidencias y sus plazos cambiando a la vez. Es fácil que el documento se quede desactualizado y que llegues a la auditoría con evidencias caducadas o controles sin responsable asignado.
Aquí es donde una herramienta de gestión de IT y cumplimiento como Factorial IT marca la diferencia, porque cubre y documenta buena parte de los controles técnicos del Anexo A que aparecen en tu SoA:
- Inventario de activos IT automático, siempre actualizado y exportable para la auditoría.
- Gestión de dispositivos (MDM) con cifrado, antivirus y parches en Mac, Windows y Linux.
- Control de accesos que asigna y revoca permisos según el rol de cada empleado.
- Offboarding seguro que cierra todos los accesos al registrar una baja en RRHH.
- Evidencias de auditoría automáticas, listas para exportar cuando el auditor las pida.
Con los controles implantados y las evidencias recogidas de forma continua, mantener la SoA al día deja de ser una carrera de última hora antes de la auditoría.
