Objetivos de aprendizaje
- Conocer el contenido mínimo de la Declaración de Aplicabilidad (SoA) según la cláusula 6.1.3 d).
- Redactar justificaciones de inclusión y de exclusión que resistan una auditoría.
- Relacionar la SoA con el análisis de riesgos, el plan de tratamiento y el alcance.
- Usar la SoA para integrar ISO/IEC 27001 con el Esquema Nacional de Seguridad.
1. Qué es la Declaración de Aplicabilidad
La Declaración de Aplicabilidad es uno de los documentos más importantes del SGSI. Es lo primero que revisa el auditor de certificación, y su referencia (código y versión) suele figurar en el propio certificado. La cláusula 6.1.3 d) exige que la SoA contenga:
- los controles necesarios, elegidos durante el tratamiento de riesgos, sean del Anexo A o de otras fuentes;
- la justificación de su inclusión;
- si están implantados o no;
- la justificación de excluir cualquier control del Anexo A.
La SoA debe mantenerse como información documentada, con control de versiones y aprobación.
Qué cambia respecto a 2013
El contenido exigido es en esencia el mismo que en 2013 (controles necesarios, justificación de inclusión, si están implantados y justificación de exclusiones), pero la versión 2022 lo enumera en cuatro elementos separados y deja más claro que se parte de «los controles necesarios» determinados en 6.1.3 b) y c), sean o no del Anexo A. La estructura de la SoA pasa a ser la de los 93 controles de 2022, sin «objetivos de control».
2. Columnas recomendadas
La norma fija el contenido mínimo, pero una SoA útil para la gestión diaria suele incorporar más columnas:
| Columna | Obligatoria | Comentario |
|---|---|---|
| Identificador y título del control | Sí | Los 93 del Anexo A, más los controles adicionales que se identifiquen. |
| Aplicable (Sí/No) | Sí | Decisión tomada durante el tratamiento de riesgos. |
| Justificación de inclusión | Sí | Referencia a los riesgos (ID del registro de riesgos), a un requisito legal o contractual, o a una expectativa de una parte interesada. |
| Justificación de exclusión | Sí (si se excluye) | Por qué no es necesario. |
| Estado de implantación | Sí | Implantado, parcialmente implantado, planificado o no implantado. |
| Documentos y evidencias de referencia | Recomendada | Política o procedimiento y registro que lo demuestran. |
| Responsable | Recomendada | Persona o área propietaria del control. |
| Correspondencia 2013 / ENS / otros | Opcional | Facilita la migración y el cumplimiento integrado. |
3. Cómo justificar bien
Las justificaciones genéricas («aplica por buenas prácticas», «no aplica») son una fuente habitual de no conformidades. Compare estos ejemplos:
| Control | Justificación débil | Justificación sólida |
|---|---|---|
| 8.13 Copias de seguridad | Aplica. | Trata los riesgos R-01 (ransomware que cifra la plataforma y las copias no aisladas) y R-05 (despliegue defectuoso que corrompe expedientes). Lo exigen además los contratos con los ayuntamientos (RPO de 24 h) y el ENS (mp.info.6). |
| 8.30 Desarrollo externalizado | No aplica. | Excluido: todo el desarrollo dentro del alcance lo realiza personal propio, según la política de contratación vigente. Se revisará si se contrata desarrollo a terceros (disparador de revisión). |
| 7.12 Seguridad del cableado | No aplica, está en la nube. | Aplicable. En el CPD del proveedor IaaS lo implanta el proveedor y se verifica con su certificación (5.22). En la oficina, el cableado del rack está canalizado y el armario permanece cerrado (riesgo R-08 sobre el CPD de oficina). |
Reglas prácticas:
- Toda exclusión debe ser coherente con el alcance y con el análisis de riesgos. Un auditor sospechará de un control excluido que trata un riesgo identificado.
- «Lo hace el proveedor» no es motivo de exclusión: el control es aplicable y se demuestra mediante la gestión del proveedor.
- Pocas exclusiones son razonables en la mayoría de las organizaciones. Las más habituales afectan a 8.30 (si no hay desarrollo externalizado), a 8.4 y 8.25–8.29 (si no hay desarrollo) y a algunos controles físicos en organizaciones sin instalaciones propias.
- Un control «aplicable, no implantado» es válido si figura en el plan de tratamiento con fecha y responsable.
4. La SoA dentro del proceso de riesgos
Así encaja la SoA con el resto del SGSI:
- La evaluación de riesgos (6.1.2 y 8.2) identifica y valora los riesgos.
- El tratamiento (6.1.3 y 8.3) decide la opción para cada riesgo y determina los controles necesarios.
- Los controles se comparan con el Anexo A (6.1.3 c) para detectar omisiones.
- La SoA recoge la decisión para cada control.
- El plan de tratamiento organiza la implantación de los controles pendientes.
- Los propietarios de los riesgos aprueban el plan y aceptan el riesgo residual (6.1.3 f).
Por tanto, la SoA, el registro de riesgos y el plan de tratamiento deben estar trazados entre sí. La plantilla GHG-27K-M6-01 incluye columnas para los ID de riesgo y para las referencias a documentos.
5. Integración con el ENS
Muchas organizaciones españolas, como las que prestan servicios al sector público, deben cumplir a la vez ISO/IEC 27001 y el ENS (RD 311/2022). Añadir a la SoA una columna con la medida equivalente del Anexo II del ENS permite reutilizar las evidencias en ambas auditorías. Algunas correspondencias frecuentes son estas (aplicabilidad según el Anexo II: «cat» = por categoría del sistema; «niv» = por nivel de la dimensión indicada):
| ISO/IEC 27001:2022 | ENS (Anexo II) | Aplicabilidad ENS |
|---|---|---|
| 5.1 Políticas de seguridad | org.1 Política de seguridad; org.2 Normativa de seguridad | cat Básica, Media y Alta; todas las dimensiones |
| 6.1.2 / 8.2 Evaluación de riesgos | op.pl.1 Análisis de riesgos (+ r1 semiformal; r2 formal) | cat BMA; r1 en Media; r2 en Alta |
| 5.9 Inventario de activos | op.exp.1 Inventario de activos | cat BMA |
| 5.23 Servicios en la nube | op.nub.1 Protección de servicios en la nube (+ r1 Servicios certificados; r2 Guías de configuración) | cat BMA; r1 en Media y Alta; r2 en Alta |
| 5.24–5.26 Gestión de incidentes | op.exp.7 Gestión de incidentes (+ r1 Notificación; r2 Detección y respuesta) | cat BMA; r1 y r2 en Media y Alta |
| 5.30 Preparación de las TIC para la continuidad | op.cont.1 Análisis de impacto; op.cont.2 Plan de continuidad | op.cont.1: niv Medio y Alto en Disponibilidad; op.cont.2: niv Alto en Disponibilidad |
| 6.3 Concienciación y formación | mp.per.3 Concienciación; mp.per.4 Formación | cat BMA |
| 8.5 Autenticación segura | op.acc.6 Mecanismo de autenticación (usuarios de la organización) | niv BMA en C, I, T, A; r8 (doble factor desde zonas no controladas) en todos los niveles |
| 8.7 Protección contra el código malicioso | op.exp.6 Protección frente a código dañino | cat BMA |
| 8.13 Copias de seguridad | mp.info.6 Copias de seguridad (+ r1 Pruebas de recuperación; r2 Protección de las copias) | niv BMA en Disponibilidad; r1 en Medio y Alto; r2 en Alto |
| 8.15 Registro de eventos | op.exp.8 Registro de la actividad | niv BMA en Trazabilidad (refuerzos r1–r4 desde Medio) |
| 8.32 Gestión de cambios | op.exp.5 Gestión de cambios | cat Media y Alta |
La correspondencia no siempre es completa: hay medidas ENS más exigentes o más específicas que el control ISO, y al revés. Úsela como apoyo para reutilizar evidencias, no como sustituto del análisis. Recuerde también que la lógica de exclusión es distinta. En el ENS, una medida exigible por la categoría o el nivel solo deja de aplicarse si el sistema no tiene el elemento al que se refiere, o si se sustituye por medidas compensatorias justificadas (art. 28 del RD 311/2022). No basta con que el análisis de riesgos la considere innecesaria.
Caso Nubia
La SoA de Nubia (versión 1.0) recoge:
- 91 controles aplicables. De ellos, 69 están implantados, 14 parcialmente y 8 planificados con fecha en el plan de tratamiento.
- 2 exclusiones: 8.30 (no hay desarrollo externalizado) y 7.6 (no existen áreas seguras con trabajo permanente dentro del alcance). En el primer borrador también se excluían 7.11 y 7.12 por no tener CPD propio. Se corrigieron a «aplicables», porque la oficina tiene un rack y el CPD del proveedor IaaS los cubre bajo supervisión.
- 2 controles adicionales del ENS: mp.info.3 Firma electrónica y mp.info.4 Sellos de tiempo, por requisitos de sus contratos públicos.
- Columna «Medida ENS»: permite usar la misma SoA para preparar la auditoría ENS de categoría MEDIA.
6. Errores frecuentes en la SoA
- Plantilla descargada con todo marcado como «Aplicable – Implantado» y sin evidencias detrás.
- Falta de coherencia entre la SoA y el registro de riesgos: controles que tratan riesgos que nadie ha identificado, o riesgos sin control.
- SoA no actualizada tras un cambio relevante, como un nuevo proveedor en la nube o una nueva línea de negocio.
- No indicar la versión de la SoA, o que no coincida con la citada en el certificado.
- Seguir usando la numeración A.5–A.18 de 2013.
Plantillas de esta lección
- GHG-27K-M6-01 Declaración de Aplicabilidad (93 controles), con columnas de justificación, estado, evidencias, responsable, correspondencia 2013 y medida ENS.
Ideas clave
- La SoA debe contener los controles necesarios, la justificación de su inclusión, su estado de implantación y la justificación de las exclusiones (6.1.3 d).
- Las justificaciones deben remitir a riesgos, requisitos legales o contractuales, o expectativas concretas.
- «Lo gestiona un proveedor» no equivale a «no aplicable».
- La SoA, el registro de riesgos y el plan de tratamiento deben estar trazados entre sí.
- Una columna de correspondencias con el ENS permite reutilizar evidencias, pero la lógica de exclusión es distinta en cada marco.