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 te ayuda Factorial IT con la Declaración de Aplicabilidad?
Cada fila de la SoA pide una decisión y una prueba. Para los controles organizativos, esa prueba suele ser una política o un procedimiento. Para los tecnológicos, depende del estado real de los equipos, las cuentas y las aplicaciones, y es ahí donde el documento se desactualiza más rápido.
Factorial IT gestiona esa parte desde una sola plataforma conectada con RRHH, y aporta datos a varias columnas de la SoA.
- Justificaciones basadas en datos: el inventario muestra cuántos portátiles y móviles tiene la empresa, con qué sistemas operativos y quién trabaja fuera de la oficina. Con esa información, decidir si aplican controles como el trabajo en remoto (6.7) o los dispositivos de usuario final (8.1) deja de ser una suposición y la justificación se apoya en cifras.
- Controles que pasan de «en desarrollo» a «implementado»: la monitorización de la actividad (8.16) suele quedarse a medias en empresas sin un centro de operaciones de seguridad propio. Factorial IT ofrece servicios MDR con analistas que vigilan los equipos las 24 horas y responden a las amenazas, una forma de cubrir ese control sin montar un equipo interno.
- Parches más allá del sistema operativo (8.8): la gestión de vulnerabilidades exige corregir también las aplicaciones de terceros, que son las que más se olvidan. Con el módulo de parcheo del EDR, las actualizaciones de los programas instalados se aplican de forma centralizada en todo el parque.
- Evidencias con fecha: en la columna de evidencias, la referencia a un informe exportado con el estado del parque en una fecha concreta pesa mucho más que el nombre de un documento. El auditor puede contrastarla con la situación actual en el momento.
Además, cuando el parque cambia, la plataforma lo refleja al instante. Un nuevo tipo de dispositivo o un cambio en la forma de trabajar de la plantilla se ven en los datos antes que en el documento, y eso indica cuándo toca revisar la SoA.
