La Declaración de Aplicabilidad, o Statement of Applicability (SoA), es el documento que ISO/IEC 27001:2022 exige como parte del tratamiento de riesgos. Registra qué controles necesita la organización para tratar sus riesgos, por qué, si están implementados, y por qué se excluyen los controles del Anexo A que no resultan necesarios.
Es el documento que conecta los riesgos con los controles, y uno de los que la auditoría revisa con más detalle. No es una lista de 93 casillas para marcar cuáles "se tienen": es un registro de decisiones, y cada decisión tiene que poder explicarse a partir de los riesgos.
¿Para qué sirve la Declaración de Aplicabilidad?
Para dejar trazable una cadena de decisiones: qué riesgo existe, qué se decidió hacer con él, qué control lo trata, si aplica y si ya está implementado. Con el SoA, un auditor, un cliente o un nuevo responsable entiende por qué el sistema tiene los controles que tiene y no otros.
Es también el mapa que usa el organismo certificador: los controles declarados aplicables son los que verifica en operación, y las exclusiones son las que pide justificar.
¿Hay que implementar los 93 controles del Anexo A?
No necesariamente, y tampoco se eligen a gusto. La norma exige un proceso, y el SoA es su resultado:
- Riesgos
- Decisiones de tratamiento
- Controles necesarios
- Comparación con el Anexo A
- Declaración de Aplicabilidad
- Implementación
- Evidencia
La organización evalúa sus riesgos, decide cómo tratar cada uno, determina los controles necesarios para hacerlo y recién entonces los compara con el Anexo A, para comprobar que no omitió ninguno. Un control del Anexo A queda dentro cuando trata un riesgo de la organización y queda fuera cuando no lo hace. La cantidad final de controles aplicables es una consecuencia del análisis, no un objetivo.
Por eso el Anexo A funciona como red de seguridad, no como punto de partida: empezar por sus 93 controles invierte el proceso. Sus controles vienen de ISO/IEC 27002:2022, la guía que describe cada uno y que no es certificable; cómo se organizan y qué significa implementar uno está en Controles ISO 27001:2022. Esta secuencia es una representación explicativa de JanusNet, no un diagrama oficial de la norma.
¿Qué debe contener un SoA?
Cuatro elementos son requisito de la norma; el resto es lo que hace que el documento sirva de verdad al sistema.
| Elemento | ¿Requisito o práctica? | Para qué sirve |
|---|---|---|
| Los controles necesarios | Requisito | Identificar qué controles forman parte del tratamiento, del Anexo A o de otra fuente |
| Justificación de la inclusión | Requisito | Explicar por qué cada control es necesario |
| Estado de implementación | Requisito | Declarar si cada control está implementado o no |
| Justificación de las exclusiones del Anexo A | Requisito | Explicar por qué un control de referencia no es necesario |
| Riesgo o decisión de tratamiento relacionada | Práctica recomendada | Trazabilidad entre el riesgo y el control |
| Responsable del control | Práctica recomendada | Saber quién responde por su operación |
| Referencia a la evidencia | Práctica recomendada | Encontrar rápido cómo se demuestra que opera |
| Fecha de revisión | Práctica recomendada | Saber si el documento sigue vigente |
Las cuatro columnas adicionales son la forma en que JanusNet construye el SoA para que resista una auditoría sin buscar información en otros documentos.
¿Cómo se construye una Declaración de Aplicabilidad?
Del riesgo al control, en este orden. Los pasos 2 a 8 responden a requisitos de la norma; el 1 es la condición previa y el 9 es lo que mantiene el documento vigente.
- Definir el alcance del SGSI: sin alcance no se sabe qué riesgos evaluar ni a qué aplican los controles.
- Evaluar los riesgos con la metodología y los criterios de aceptación definidos.
- Decidir el tratamiento de cada riesgo: modificar, retener, evitar o compartir, con la aprobación de su dueño.
- Determinar todos los controles necesarios para ejecutar esas decisiones, vengan del Anexo A o de cualquier otra fuente.
- Comparar los controles determinados con el Anexo A y verificar que no se omitió ninguno necesario.
- Registrar los controles aplicables, con la justificación de cada inclusión.
- Registrar las exclusiones del Anexo A, con la justificación de cada una.
- Declarar el estado de implementación de cada control.
- Revisar el SoA cuando cambien los riesgos, el alcance o los controles, manteniendo la coherencia con el plan de tratamiento y con la operación.
El lugar de estos pasos dentro del proyecto completo está en Cómo implementar ISO 27001 en Chile.
Ejemplo simplificado de un SoA
Ejemplo ilustrativo, con descripciones propias y resumidas de cuatro controles. No es una plantilla oficial ni reproduce el texto de la norma.
| Control | Aplicable | Justificación | Estado |
|---|---|---|---|
| Control de acceso a la información y a los sistemas | Sí | Trata el riesgo de acceso no autorizado a datos de clientes por cuentas sin gestión | Implementado, con revisión de accesos operando |
| Seguridad en el trabajo remoto | Sí | Parte del personal opera fuera de la oficina con acceso a sistemas críticos | Parcialmente implementado: falta el control de dispositivos personales |
| Respaldo de la información | Sí | Trata el riesgo de pérdida de datos por falla o cifrado malicioso | Implementado, con pruebas de restauración registradas |
| Seguridad física de los equipos fuera de las instalaciones | No | El alcance no incluye equipos que operen fuera de las sedes; el riesgo asociado no existe en el alcance | No aplica |
La cuarta fila muestra una exclusión bien justificada: no dice "no queremos", dice por qué el riesgo que ese control trataría no existe dentro del alcance.
Exclusiones y controles propios
Se puede excluir un control del Anexo A cuando el tratamiento de riesgos muestra que no es necesario, siempre con la justificación registrada en el SoA. La norma no fija criterios universales de exclusión: exige la justificación, y el auditor evalúa si es defendible con el análisis de riesgos y el alcance a la vista.
Se pueden usar controles que no están en el Anexo A. La norma indica que los controles necesarios pueden diseñarse por la propia organización o tomarse de cualquier fuente, y que el Anexo A no es exhaustivo. Un control propio, uno de otro marco o uno exigido por un regulador entra al SoA con la misma lógica: trata un riesgo, se justifica y se declara con su estado.
SoA, plan de tratamiento y matriz de riesgos
Los tres salen del mismo proceso y no se sustituyen entre sí.
| Statement of Applicability | Plan de tratamiento de riesgos | |
|---|---|---|
| Pregunta principal | ¿Qué controles son necesarios, cuáles del Anexo A no lo son, y por qué? | ¿Cómo vamos a ejecutar el tratamiento de cada riesgo? |
| Foco | Aplicabilidad y estado de implementación | Acciones, responsables y plazos |
| Relación | Registra las decisiones sobre controles | Organiza su ejecución; requiere la aprobación de los dueños de los riesgos y la aceptación de los residuales |
El SoA dice qué; el plan dice cómo y quién. La norma exige ambos, y un control "no implementado" en el SoA debería tener en el plan la acción que lo implementará.
La matriz o registro de riesgos es el origen de los dos: la trazabilidad va del riesgo al tratamiento, del tratamiento al control y del control a su fila en el SoA. Un SoA sin riesgos detrás es una lista de controles sin razón.
Del SoA a la evidencia
Que un control figure como implementado en el SoA no demuestra que opere. Hay cinco estados, y la auditoría los distingue: declarado, implementado, operando, evidenciado y efectivo. El SoA registra los dos primeros; los tres siguientes se demuestran con registros, revisiones, indicadores y resultados.
Un control declarado como implementado sin evidencia de que opera es un hallazgo seguro. Cómo el sistema completo produce esa evidencia está en ¿Qué es un SGSI y cómo funciona según ISO 27001?.
Errores frecuentes al construir el SoA
- Empezar por los 93 controles sin haber evaluado riesgos.
- Copiar el SoA de otra organización, con sus riesgos y su alcance.
- Excluir controles sin justificación, o con una que no resiste una pregunta.
- Declarar implementados controles sin evidencia de que operan.
- Perder la coherencia entre riesgos, plan de tratamiento y SoA cuando cambia uno y no los otros.
- Confundir el SoA con el plan de tratamiento y dejar uno de los dos sin hacer.
- Darlo por terminado para siempre: un SoA desactualizado es uno de los hallazgos más frecuentes en auditoría.
Siguiente paso
Una plantilla ahorra el trabajo administrativo, pero no decide nada: ISO no publica una plantilla oficial, y un SoA idéntico al de otra empresa suele ser señal de que se llenó antes de analizar. Las decisiones que registra nacen del contexto, del alcance y de los riesgos, y se sostienen con la operación, la auditoría interna y la revisión por la dirección; cómo encaja cada pieza está en el ciclo del SGSI.
Si el SoA ya existe y no hay certeza de que se sostenga, un Gap Assessment revisa la coherencia entre riesgos, tratamiento, SoA, implementación y evidencia. Es una de las revisiones que más hallazgos produce, porque el SoA suele envejecer más rápido que el resto del sistema.
¿No sabes todavía qué tan preparado está tu SGSI?
Una primera lectura, en quince preguntas
Nivel estimado de preparación para ISO/IEC 27001:2022, incluida la gestión de riesgos y la Declaración de Aplicabilidad. Sin registro. Es orientativo y no sustituye un Gap Assessment ni una auditoría.
Preguntas frecuentes
¿Qué es el Statement of Applicability?
Es la Declaración de Aplicabilidad (SoA): el documento exigido por ISO/IEC 27001:2022 que registra los controles necesarios para tratar los riesgos, la justificación de cada uno, su estado de implementación y la justificación de los controles del Anexo A que se excluyen.
¿El SoA es obligatorio?
Sí. ISO/IEC 27001:2022 exige producirlo como parte del tratamiento de riesgos, y el organismo certificador lo revisa en detalle: le dice qué controles va a verificar en operación y qué exclusiones va a pedir justificar.
¿Hay que implementar los 93 controles de ISO 27001?
No necesariamente. Los controles necesarios se determinan a partir del tratamiento de riesgos y se comparan con el Anexo A para no omitir ninguno; la cantidad de controles aplicables es consecuencia del análisis. El detalle está en Controles ISO 27001:2022.
¿Se pueden excluir controles del Anexo A?
Sí, cuando el tratamiento de riesgos muestra que un control no es necesario y la justificación queda registrada en el SoA. El auditor evalúa si esa justificación es defendible.
¿Quién debe preparar el SoA?
La organización, dentro de su SGSI: en la práctica, el responsable del sistema con los dueños de los riesgos y de los controles, con apoyo de una consultora si corresponde. Las decisiones que registra, incluida la aceptación de riesgos residuales, son de la organización.
¿El SoA debe actualizarse?
Sí. Cuando cambian los riesgos, el alcance, las decisiones de tratamiento o el estado de los controles, el SoA tiene que reflejarlo; de lo contrario deja de describir el sistema.
¿Existe una plantilla oficial de SoA?
No. ISO no publica una plantilla oficial; cualquier estructura sirve mientras contenga lo que la norma exige. Lo que ninguna plantilla determina son los riesgos, la aplicabilidad, las justificaciones y la evidencia de la organización.
Fuentes
- ISO/IEC 27001:2022, Information security management systems. Requirements: el proceso de tratamiento de riesgos, la determinación de los controles necesarios, la comparación con el Anexo A, el contenido de la Declaración de Aplicabilidad, el plan de tratamiento y la aprobación de los dueños de los riesgos.
- ISO/IEC 27002:2022, Information security controls: la guía de los controles de referencia que el Anexo A toma como base.
- ISO/IEC 27005:2022, Guidance on managing information security risks: la orientación sobre evaluación y tratamiento de riesgos, incluidas las opciones de tratamiento.
Este artículo parafrasea los requisitos de ISO/IEC 27001:2022 sin reproducir texto de la norma ni de los controles. Las columnas adicionales, la secuencia de construcción y el ejemplo corresponden a la metodología de JanusNet, empresa de ciberseguridad en Chile que acompaña la implementación de SGSI sin actuar como organismo certificador.