En breve: La Declaración de Aplicabilidad (SoA) es el documento que recoge los 93 controles del Anexo A de ISO/IEC 27001:2022, indica si cada uno aplica a tu organización y justifica por qué. Se construye a partir del análisis de riesgos, no al revés, y es la pieza que el auditor revisa primero durante la certificación.
¿Qué es la Declaración de Aplicabilidad (SoA) en ISO 27001?
La Declaración de Aplicabilidad, conocida por sus siglas en inglés SoA (Statement of Applicability), es el documento en el que tu organización recorre uno a uno los 93 controles del Anexo A de ISO/IEC 27001:2022 y decide, control por control, si aplica o no a su realidad. Para cada control que aplica, la SoA recoge además el estado de implantación y la evidencia asociada. Para cada control excluido, exige una justificación documentada.
No es un listado que se rellena de memoria ni una casilla que se marca por costumbre. Es, junto con el análisis de riesgos, el documento que da sentido a todo el sistema de gestión de seguridad de la información (SGSI). La norma la considera obligatoria: sin SoA no hay certificación posible, porque es la prueba escrita de que la organización ha razonado su postura de seguridad control a control, no que ha copiado un catálogo genérico.
Conviene tener presente que la edición 2022 de la norma trabaja con 93 controles, frente a los 114 que tenía la edición 2013. Si tu SoA todavía está redactada sobre la estructura antigua, es la primera señal de que necesita una revisión a fondo.
¿Por qué la SoA es el documento central de la certificación?
Porque es el punto de encuentro entre dos mundos que, en muchas pymes, viven separados: el análisis de riesgos (qué puede salir mal y con qué probabilidad e impacto) y los controles reales que se aplican en el día a día (qué se hace para evitarlo o mitigarlo). La SoA es la traducción de uno en el otro.
Cuando un auditor de certificación llega a tu organización, la SoA es habitualmente uno de los primeros documentos que pide. Con ella en la mano puede trazar el resto de la auditoría: qué políticas debería encontrar, qué registros y evidencias tiene que pedir, qué preguntas hacer a cada responsable. Si tu SoA dice que el control de copias de seguridad aplica y está implementado, el auditor irá a comprobar cómo gestionas tus backups (por ejemplo, si sigues la regla 3-2-1: tres copias de los datos, en dos soportes distintos, con una copia fuera de las instalaciones). Si la SoA no está bien construida, toda la auditoría se resiente, porque no hay hilo conductor que la sostenga.
Dicho de otro modo: puedes tener controles excelentes implantados y aun así fallar la auditoría si tu SoA no refleja con precisión la realidad, no está justificada o no coincide con lo que se observa sobre el terreno.
¿Cómo se construye la SoA paso a paso?
La SoA no se redacta de un tirón ni se copia de una plantilla que circula por internet. Se construye en varias fases, y cada una depende de la anterior.
1. Parte siempre del análisis de riesgos
Antes de tocar la SoA, debe existir un análisis de riesgos completo: activos identificados, amenazas y vulnerabilidades asociadas, valoración de probabilidad e impacto, y un plan de tratamiento que decide para cada riesgo si se acepta, se transfiere, se evita o se mitiga con controles. La SoA nace de aquí. Un control aparece como aplicable en la SoA porque el análisis de riesgos ha determinado que hace falta para tratar un riesgo concreto, no porque figure en una lista estándar.
2. Recorre el Anexo A control por control
Con el plan de tratamiento de riesgos ya cerrado, toca revisar sistemáticamente los 93 controles del Anexo A, agrupados en los cuatro temas de la norma: organizativos, personas, físicos y tecnológicos. Para cada uno, la pregunta no es "¿nos gustaría tenerlo?", sino "¿este control trata alguno de los riesgos que hemos identificado, o responde a una obligación legal, contractual o normativa?".
3. Marca aplica o no aplica, con criterio
Cada control recibe una decisión binaria: aplica o no aplica. Una pyme de servicios sin desarrollo de software propio, por ejemplo, puede excluir de forma razonable los controles de ciclo de vida de desarrollo seguro; una empresa sin oficinas físicas propias puede reformular (no necesariamente excluir del todo) los controles de seguridad física. Lo importante es que la decisión responda a la realidad del negocio, no a la comodidad de reducir trabajo.
4. Redacta la justificación de cada decisión
Este es el paso que más pymes se saltan y el que más piden los auditores. Cada fila de la SoA necesita una frase que explique el porqué: por qué aplica (referenciando el riesgo tratado o la obligación legal) o por qué no aplica (referenciando la ausencia de ese activo, proceso o riesgo en la organización). "No aplica" sin más, no es una justificación: es una casilla vacía disfrazada de respuesta.
5. Define el estado de implantación
Que un control aplique no significa que ya esté implementado. La SoA debe distinguir entre estados como implementado, en curso de implantación, planificado o pendiente de aprobación presupuestaria. Confundir "aplica" con "ya lo tenemos hecho" es uno de los errores que más problemas genera en auditoría.
6. Aprueba, versiona y mantén viva la SoA
La SoA se aprueba formalmente por la dirección (o quien tenga esa responsabilidad delegada dentro del SGSI) y se versiona como cualquier otro documento del sistema: fecha, número de versión, responsable de la revisión y motivo del cambio. No es un documento que se firma una vez y se olvida en un cajón; se revisa cada vez que cambia el análisis de riesgos, se incorpora un nuevo servicio, se pierde un proveedor crítico o se detecta una no conformidad.
¿Cómo se justifican correctamente las exclusiones de un control?
Excluir un control del Anexo A es perfectamente legítimo si está bien argumentado. Los motivos que suelen sostenerse en auditoría son, entre otros:
- El riesgo que trata el control no existe en la organización. Por ejemplo, controles relativos a la gestión de dispositivos móviles corporativos si la empresa no los utiliza.
- El riesgo ya está cubierto por otro control equivalente, y así se documenta la relación entre ambos.
- El riesgo se ha aceptado formalmente dentro del plan de tratamiento de riesgos, con la firma de quien tiene autoridad para asumirlo.
- No existe obligación legal, contractual o regulatoria que obligue a implantar ese control en el contexto concreto de la actividad.
Lo que no funciona en una auditoría es una exclusión motivada únicamente por el coste o la comodidad, sin trazabilidad hasta el análisis de riesgos. El auditor no exige que todos los controles estén implementados: exige que la decisión, sea cual sea, esté razonada y sea coherente con el resto del sistema.
¿Qué estructura debe tener cada fila de la SoA?
No existe un formato único obligatorio, pero la práctica habitual —y la que resiste mejor una auditoría— recoge, como mínimo, estas columnas por cada uno de los 93 controles:
| Campo | Contenido |
|---|---|
| Referencia del control | Código y nombre según el Anexo A (por ejemplo, control de copias de seguridad) |
| ¿Aplica? | Sí / No |
| Justificación | Motivo de inclusión (riesgo tratado, obligación legal) o de exclusión |
| Estado de implantación | Implementado / en curso / planificado / no aplica |
| Evidencia o referencia documental | Política, procedimiento o registro donde se demuestra la implantación |
Un ejemplo concreto ayuda a entenderlo. Para el control de copias de seguridad, una fila bien construida diría algo así: aplica (sí), justificación: "existe riesgo de pérdida de datos por fallo de hardware o ransomware, valorado como alto en el análisis de riesgos"; estado: implementado; evidencia: "política de copias de seguridad v2, siguiendo la regla 3-2-1-1-0 (tres copias, dos soportes, una fuera de las instalaciones, una inmutable, cero errores de restauración verificados)". Esa es la diferencia entre una SoA que sostiene una auditoría y una que se derrumba a la primera pregunta.
¿Qué errores cometen las pymes al redactar la SoA?
Después de acompañar procesos de certificación en pymes españolas, los fallos se repiten casi siempre en la misma lista:
- Copiar una plantilla genérica de internet sin adaptar ni una coma a la realidad de la organización. Se nota a la primera lectura: controles justificados con frases idénticas, sin relación con el análisis de riesgos propio.
- Excluir controles sin justificar de verdad, dejando un "no aplica" que no resiste ninguna pregunta.
- No vincular la SoA al análisis de riesgos. Son dos documentos que deberían leerse como uno solo; cuando se elaboran por separado, casi nunca cuadran.
- No versionar el documento. Cambia el negocio, cambian los proveedores, cambia la infraestructura, y la SoA se queda congelada en la fecha de la primera certificación.
- Confundir "aplica" con "está implementado". Son dos preguntas distintas que necesitan dos respuestas distintas en cada fila.
- Tratarla como un trámite en lugar de como una herramienta de gestión viva que debería consultarse antes de cualquier decisión de seguridad relevante.
¿Qué revisa el auditor sobre la SoA en la certificación?
El auditor no se limita a comprobar que la SoA existe. Contrasta que cada decisión de aplicación coincide con el análisis y el plan de tratamiento de riesgos, pide evidencia de los controles marcados como implementados, y revisa que las exclusiones tengan una justificación sólida y coherente con la actividad de la empresa. También comprueba que el documento se ha revisado y aprobado formalmente, y que existe trazabilidad de sus versiones anteriores.
Este mismo principio —justificar cada decisión con criterios de riesgo, no de comodidad— se repite en otros marcos normativos españoles, como el Esquema Nacional de Seguridad, que también exige categorizar el sistema según su impacto antes de decidir qué medidas de su propio catálogo se aplican. Entender la lógica de la SoA en ISO 27001 ayuda, de hecho, a entender cualquier otro marco de seguridad construido sobre análisis de riesgos.
Si estás preparando la certificación y quieres que la Declaración de Aplicabilidad se construya bien desde el primer día —ligada al análisis de riesgos real de tu empresa, no a una plantilla— en mi servicio de consultoría ISO 27001 me encargo de acompañar todo el proceso, desde el análisis de riesgos hasta la auditoría de certificación.