La Declaración de Aplicabilidad ISO 27001, conocida por sus siglas en inglés como SoA (Statement of Applicability), es uno de los documentos más importantes y, a la vez, más temidos de todo el proceso de certificación. Es la pieza que conecta tu análisis de riesgos con los controles que decides aplicar, y el primer papel que un auditor pide ver cuando se sienta a revisar tu SGSI. En esta guía te explicamos qué es la Declaración de Aplicabilidad, cómo se relaciona con el Anexo A de la versión 2022, cómo redactarla paso a paso y cómo evitar los errores que más penalizan en auditoría.
Qué es la Declaración de Aplicabilidad (SoA)
La Declaración de Aplicabilidad es el documento que recoge, control por control, qué controles del Anexo A de la ISO/IEC 27001 aplica tu organización, cuáles no, y por qué en cada caso. No es una lista de buenas intenciones: es la justificación documentada de tus decisiones de seguridad y la prueba de que esas decisiones nacen de tu análisis de riesgos, no de una plantilla copiada.
La norma la exige de forma explícita en su cláusula 6.1.3. Sin SoA no hay certificación posible, porque es el puente entre lo que dice la teoría (los controles disponibles) y lo que hace tu organización (los controles realmente implantados). El auditor la usa como mapa: a partir de ella decide qué evidencias pedirte y dónde mirar.
Si todavía estás situando el conjunto de la norma, te vendrá bien repasar antes nuestra guía sobre qué es la ISO 27001 y cómo certificarse, donde explicamos el marco completo del SGSI.
La relación entre el SoA, el análisis de riesgos y el Anexo A
Para entender la Declaración de Aplicabilidad hay que ver de dónde sale. El proceso es una cadena lógica y el SoA es su último eslabón documental.
Todo empieza con el análisis de riesgos: identificas tus activos, las amenazas que les afectan y las vulnerabilidades que podrían explotarse, y valoras el riesgo resultante. A partir de ahí defines un plan de tratamiento del riesgo: para cada riesgo relevante decides si lo aceptas, lo evitas, lo transfieres o lo mitigas. Cuando la decisión es mitigar, eliges controles. Y es justo en ese momento cuando entra el Anexo A.
El Anexo A de la ISO 27001:2022 contiene 93 controles organizados en cuatro grandes grupos: organizativos (37), de personas (8), físicos (14) y tecnológicos (34). La versión de 2022 reorganizó y modernizó los controles que en la edición anterior estaban repartidos en 14 dominios. La Declaración de Aplicabilidad recorre esos 93 controles y deja constancia, para cada uno, de tu decisión y su justificación. Por eso el SoA no se puede redactar antes del análisis de riesgos: sería poner el tejado sin haber construido los muros.
Cómo redactar la Declaración de Aplicabilidad paso a paso
Un buen SoA tiene una estructura clara y, para cada uno de los 93 controles, recoge al menos cuatro datos. Esta es la anatomía de cada fila:
| Campo | Qué recoge |
|---|---|
| Control | El identificador y nombre del control del Anexo A (por ejemplo, 5.9 Inventario de información y otros activos asociados) |
| Aplicabilidad | Si el control aplica o no a tu organización (sí / no) |
| Justificación | El porqué de la decisión, ligado a tu análisis de riesgos o a requisitos legales, contractuales o de negocio |
| Estado de implantación | Si el control está implantado, en curso o pendiente, y cómo se materializa |
Decide la aplicabilidad con criterio
Marcar un control como no aplicable es legítimo, pero hay que justificarlo bien. Un ejemplo clásico: el control de desarrollo seguro no aplica si tu organización no desarrolla software propio. Lo que el auditor no perdona es excluir un control para ahorrarte trabajo sin una razón sólida detrás.
Justifica cada decisión
La justificación es la parte que distingue un SoA serio de uno de relleno. Cada inclusión debe poder rastrearse hasta un riesgo concreto o una obligación legal o contractual. Cada exclusión debe explicar por qué ese control no tiene sentido en tu contexto. Las justificaciones genéricas tipo «no procede» sin más son una invitación a la no conformidad.
Refleja el estado real
El SoA debe decir la verdad sobre dónde estás. Si un control está en proceso de implantación, dilo. Falsear el estado para que el documento luzca mejor se descubre en cuanto el auditor pide evidencias y no aparecen.
Revisa y mantén el SoA vivo
La Declaración de Aplicabilidad no es un documento que se firma una vez y se archiva. Tiene que revisarse cuando cambian los riesgos, cuando entran o salen activos relevantes, cuando se modifica un proceso de negocio o cuando la propia norma evoluciona. Un SoA que sigue diciendo lo mismo dos años después, mientras la organización ha cambiado de arriba abajo, es una señal de alarma para cualquier auditor. La recomendación práctica es ligar la revisión del SoA a la revisión periódica del análisis de riesgos, de modo que ambos se actualicen a la vez y nunca se desincronicen.
Las evidencias: el SoA no se sostiene solo
Aquí llega la parte que muchos subestiman. La Declaración de Aplicabilidad afirma que un control está implantado, pero el auditor querrá la prueba. Para el control de inventario de activos, esa prueba es un inventario actualizado y trazable. Para el de gestión de actualizaciones, el estado de parcheo de tus equipos. Para el de control de accesos, los registros de quién accede a qué.
Reunir esas evidencias a mano, repartidas en correos, capturas y carpetas, es lento y frágil. Y si el dato no está al día, la evidencia no vale. Por eso conviene apoyar el SoA en un sistema que genere evidencias de forma continua y no en una recopilación de última hora antes de la auditoría. Mantener un buen inventario de activos para ISO 27001 es, de hecho, la base sobre la que se apoyan buena parte de las evidencias de los controles del Anexo A.
Errores comunes al redactar el SoA
- Copiar una plantilla sin adaptarla. Un SoA que no nace de tu análisis de riesgos se nota a la primera y resta credibilidad a todo el SGSI.
- Excluir controles sin justificación sólida. Cada «no aplica» tiene que sostenerse con un motivo real y verificable.
- Justificaciones vacías. Frases genéricas que no enlazan con ningún riesgo ni requisito concreto.
- Estado que no coincide con la realidad. Decir que un control está implantado cuando las evidencias dicen lo contrario.
- SoA congelado. El documento no se actualiza cuando cambian los riesgos, los activos o los controles, y queda desfasado.
- Olvidar el marco normativo más amplio. Un SGSI no vive aislado; conviene tener en cuenta cómo encaja con otras obligaciones de compliance en España que afectan a tu organización.
Cómo Inventowry genera el SoA y las evidencias automáticamente
Redactar y mantener la Declaración de Aplicabilidad a mano es laborioso, sobre todo en la parte de evidencias. Aquí es donde Inventowry, el producto de Laworatory, marca la diferencia. Su módulo de cumplimiento evalúa de forma automática los controles contra ISO 27001, NIS2 y el ENS, y genera la Statement of Applicability junto con los registros y evidencias asociados.
El planteamiento es directo: la plataforma ya conoce tu parque tecnológico (inventario de hardware y software, estado de actualizaciones, incidentes, políticas), así que puede cruzar esa información con los controles y producir un SoA respaldado por datos reales, no por afirmaciones sin prueba. En lugar de declarar que un control está implantado, presentas la evidencia que lo demuestra.
Los reportes auditables (hallazgos, inventario de activos, software, actualizaciones del sistema operativo y cumplimiento) se generan en PDF listos para el auditor. Eso convierte la preparación de la auditoría, que suele ser una carrera contrarreloj, en una tarea de revisión. Y como el sistema se mantiene actualizado de forma continua, el SoA y sus evidencias no caducan entre auditoría y auditoría.
Si tu organización está además dentro del ámbito de la directiva europea de ciberseguridad, te interesa ver cómo el mismo enfoque cubre la preparación para NIS2, porque Inventowry evalúa también esos controles desde la misma plataforma.
Prepara tu SoA con evidencias reales
La Declaración de Aplicabilidad es el documento que demuestra que tu seguridad es deliberada y trazable, no improvisada. Hecha con criterio, conecta tu análisis de riesgos con controles justificados y respaldados por evidencias. Hecha de cualquier manera, se convierte en el primer punto donde el auditor encuentra grietas.
Puedes probar cómo Inventowry genera tu Declaración de Aplicabilidad y los evidence packs de cumplimiento con una prueba gratuita de 14 días, sin tarjeta. Verás tu nivel de cumplimiento contra los controles del Anexo A con datos reales de tu parque, y llegarás a la auditoría con el trabajo hecho.
Preguntas frecuentes
¿Qué es la Declaración de Aplicabilidad en ISO 27001?
Es el documento (exigido por la cláusula 6.1.3) que recoge, control por control del Anexo A, qué controles aplica la organización, cuáles no y por qué, junto con su estado de implantación. Es el puente entre el análisis de riesgos y los controles realmente implantados.
¿Cuántos controles tiene el Anexo A de la ISO 27001:2022?
La versión de 2022 tiene 93 controles repartidos en cuatro grupos: organizativos (37), de personas (8), físicos (14) y tecnológicos (34). La Declaración de Aplicabilidad debe pronunciarse sobre cada uno de ellos.
¿Se puede excluir un control en el SoA?
Sí, siempre que la exclusión esté bien justificada. Por ejemplo, el control de desarrollo seguro puede no aplicar si la organización no desarrolla software. Lo que no se admite es excluir controles sin una razón sólida ligada al contexto o al análisis de riesgos.
¿Qué evidencias hay que aportar para el SoA?
Para cada control implantado el auditor pedirá pruebas: inventario actualizado para el control de activos, estado de parcheo para la gestión de actualizaciones, registros de acceso para el control de accesos, etc. Lo recomendable es generar esas evidencias de forma continua y no recopilarlas a última hora.
