La declaración de aplicabilidad ISO 27001, conocida como SoA por sus siglas en inglés (Statement of Applicability), es el documento que conecta el análisis de riesgos con los controles de seguridad que aplica una organización. Es obligatoria para certificar un SGSI y suele ser lo primero que pide el auditor, porque resume en una sola tabla qué controles tienes, por qué y en qué estado están.
Qué es la declaración de aplicabilidad ISO 27001 y por qué la mira primero el auditor
ISO/IEC 27001:2022 exige en su cláusula 6.1.3, dentro del proceso de tratamiento de riesgos, elaborar una declaración de aplicabilidad. No es un documento aislado: es la consecuencia directa de cómo has decidido tratar los riesgos de seguridad de la información.
Para el auditor es el mapa del sistema. A partir de la SoA elige qué controles revisar, comprueba que las exclusiones tienen sentido y verifica que lo declarado como implantado existe realmente. Una SoA incoherente con el análisis de riesgos es una de las no conformidades más habituales.
Qué debe contener según ISO 27001:2022
La norma pide que la declaración de aplicabilidad ISO 27001 incluya, como mínimo:
En la versión 2022, el Anexo A contiene 93 controles agrupados en cuatro temas: organizacionales, de personas, físicos y tecnológicos. La norma aclara que esta lista no es exhaustiva: puedes incorporar controles de otras fuentes si tu análisis de riesgos lo justifica, y deben figurar igualmente en la SoA.
Relación entre análisis de riesgos, plan de tratamiento y SoA
La declaración de aplicabilidad ISO 27001 no se redacta mirando el Anexo A en abstracto. El orden lógico es este:
- Identificas y valoras los riesgos de seguridad de la información dentro del alcance del SGSI.
- Decides cómo tratar cada riesgo y qué controles necesitas.
- Comparas esos controles con el Anexo A para asegurarte de que no has omitido ninguno necesario.
- Documentas el resultado en la SoA y en el plan de tratamiento de riesgos.
Si quieres profundizar en la primera fase, consulta nuestro artículo sobre análisis de riesgos ISO 27005.
Cómo elaborar la declaración de aplicabilidad ISO 27001 paso a paso
1
Parte del alcance y del análisis de riesgos aprobados
La SoA solo tiene sentido dentro de un alcance definido y con riesgos valorados.
2
Determina los controles necesarios
Para cada riesgo que vayas a tratar, decide qué controles lo reducen. Pueden venir del Anexo A, de ISO/IEC 27002 o de otros marcos.
3
Revisa los 93 controles del Anexo A uno a uno
Marca si aplica o no y comprueba que ningún control necesario se ha quedado fuera.
4
Justifica cada decisión
Incluir un control debe responder a un riesgo, a un requisito legal o contractual o a una decisión de la dirección. Excluirlo requiere una razón concreta y verificable.
5
Indica el estado de implantación y la evidencia
Implantado, en curso o planificado, con referencia al procedimiento, registro o herramienta que lo demuestra.
6
Aprueba, versiona y mantén
Es buena práctica que la dirección apruebe la SoA junto al plan de tratamiento, que los propietarios de los riesgos aceptan. Revísala cuando cambien el alcance, los riesgos o los controles.
Ejemplo de estructura de una SoA ISO 27001
La norma no impone un formato para la SoA ISO 27001. La mayoría de organizaciones usan una tabla con una fila por control y columnas como control, aplicabilidad, justificación, estado de implantación y evidencia. Así se verían dos filas:
5.23 Seguridad de la información para el uso de servicios en la nube
¿Aplica? Sí
Justificación: Servicios en la nube críticos identificados en el análisis de riesgos.
Estado: Implantado
Evidencia: Procedimiento de gestión de proveedores cloud.
8.30 Desarrollo externalizado
¿Aplica? No
Justificación: La organización no desarrolla ni contrata desarrollo de software dentro del alcance.
Estado: No aplica
Evidencia: —
Ejemplo ilustrativo: la justificación y la evidencia deben reflejar la realidad de cada organización.
Ejemplos de justificación en la declaración de aplicabilidad ISO 27001
La parte más débil de muchas SoA son las justificaciones. Una buena justificación en la declaración de aplicabilidad ISO 27001 permite a un tercero entender la decisión sin tener que preguntar. Estos ejemplos son ilustrativos: cada organización debe adaptarlos a su análisis de riesgos y a su alcance.
Excluir un control
Débil: «No aplica».
Sólida: «8.30 Desarrollo externalizado: no aplica porque la organización no desarrolla ni contrata desarrollo de software dentro del alcance del SGSI. Se revisará si cambia la estrategia de sistemas».
Incluir un control
Débil: «Aplica por buenas prácticas».
Sólida: «5.23 Servicios en la nube: aplica porque el correo, el almacenamiento y el ERP están en la nube y el análisis de riesgos valoró como alto el riesgo de pérdida de confidencialidad en estos servicios».
Declarar el estado
Débil: «Implantado».
Sólida: «8.13 Copias de seguridad: implantado. Evidencias: política de copias, configuración de la herramienta y registro de pruebas de restauración».
Controles cubiertos por un proveedor
Débil: «No aplica: no tenemos CPD».
Sólida: «Los controles físicos del centro de datos aplican y se cubren mediante el proveedor de alojamiento. Evidencias: contrato, cláusulas de seguridad e informes del proveedor».
Qué hace que una justificación sea sólida
Relaciona el control con un riesgo, un requisito legal o contractual o una decisión de la dirección; describe el contexto concreto (sistemas, procesos y ubicaciones); indica dónde está la evidencia, y fija cuándo se revisará la decisión. Con estas cuatro piezas, la declaración de aplicabilidad ISO 27001 se defiende sola en la auditoría.
Errores frecuentes que detectan los auditores
- Excluir controles sin justificación o con frases genéricas como «no aplica a nuestra empresa».
- Copiar una plantilla sin relación con el análisis de riesgos: aparecen controles de procesos que la organización no tiene.
- Mantener la estructura de 2013 (114 controles en 14 dominios) cuando la referencia vigente es la de 2022.
- Declarar como implantados controles sin evidencia que lo demuestre.
- No actualizarla tras cambios en el alcance, en los proveedores o en los sistemas.
- Incoherencias con el plan de tratamiento: controles que figuran en un documento y no en el otro.
Cómo revisa el auditor la declaración de aplicabilidad ISO 27001
Durante la auditoría de certificación, la SoA ISO 27001 es el punto de partida para planificar qué se revisa. Conocer cómo la utiliza el auditor ayuda a prepararla con criterio y a evitar sorpresas.
Qué suele comprobar el auditor
- Que todos los controles del Anexo A aparecen en la SoA, aplicados o excluidos, y que no falta ninguno.
- Que cada control incluido tiene relación con un riesgo, un requisito legal o contractual o una decisión documentada.
- Que las exclusiones están justificadas de forma concreta y son coherentes con el alcance.
- Que el estado declarado coincide con la realidad: suele pedir evidencias de una muestra de controles marcados como implantados.
- Que la SoA y el plan de tratamiento de riesgos dicen lo mismo y están aprobados.
- Que la versión está controlada: fecha, versión, responsable y cambios.
Checklist antes de la auditoría
Si alguna respuesta es «no», conviene corregirla antes de la etapa 1 de la auditoría, que es donde se revisa la documentación del sistema.
SoA de ISO 27001 frente a la Declaración de Aplicabilidad del ENS
El Esquema Nacional de Seguridad también utiliza un documento con el mismo nombre. El artículo 28 del Real Decreto 311/2022 establece que la relación de medidas de seguridad seleccionadas se formalice en una Declaración de Aplicabilidad firmada por el responsable de la seguridad.
Aspecto
ISO/IEC 27001:2022
ENS (RD 311/2022)
Base
Cláusula 6.1.3
Artículo 28
Catálogo de referencia
93 controles del Anexo A, no exhaustivo
Medidas del Anexo II
Criterio de selección
Resultado del análisis y tratamiento de riesgos
Categoría del sistema y gestión de riesgos, con posibles medidas compensatorias
Firma
La norma no fija un firmante
Firmada por el responsable de la seguridad
Naturaleza
Norma voluntaria y certificable
Obligatoria en el ámbito de aplicación del ENS
Si tu organización trabaja con ambos marcos, puedes mantener una tabla de correspondencias entre los controles de ISO 27001 y las medidas del ENS, siempre que cada declaración cumpla sus propios requisitos. En nuestro artículo sobre configuración segura en ISO 27001 y ENS verás un ejemplo de cómo se relacionan ambos marcos en la práctica.
Preguntas frecuentes
¿Se pueden excluir controles del Anexo A?
Sí, siempre que la exclusión esté justificada y sea coherente con el análisis de riesgos y el alcance. Lo que no se puede es omitir un control que el propio análisis señala como necesario.
¿Quién debe aprobar la declaración de aplicabilidad ISO 27001?
ISO 27001 no designa un firmante concreto. Lo habitual es que la apruebe la dirección o el responsable del SGSI junto al plan de tratamiento. En el ENS, en cambio, la firma el responsable de la seguridad.
¿Cada cuánto hay que actualizar la SoA ISO 27001?
Siempre que cambien el alcance, los riesgos o los controles, y conviene revisarla en cada ciclo de evaluación de riesgos y antes de las auditorías.
¿Sirve la misma SoA para ISO 27001 y para el ENS?
Puedes integrarlas en un único documento con correspondencias, pero cada una debe cumplir los requisitos de su marco: los controles del Anexo A en un caso y las medidas del Anexo II y la firma del responsable de la seguridad en el otro.
¿Qué relación tiene la SoA con ISO 27002?
ISO/IEC 27002:2022 desarrolla cómo aplicar cada control del Anexo A. Es la guía de referencia para redactar la justificación y definir la evidencia. Lo explicamos en nuestro artículo sobre los nuevos controles de ISO 27002:2022.
¿La declaración de aplicabilidad ISO 27001 debe incluir los 93 controles?
Debe tenerlos en cuenta todos: los que aplicas, con su justificación y estado, y los que excluyes, con el motivo de la exclusión. Así el auditor puede comprobar que no se ha omitido ningún control necesario.
¿En qué formato se puede hacer la SoA?
La norma no impone un formato. Lo habitual es una hoja de cálculo o una herramienta de gestión del SGSI, siempre que sea información documentada controlada: versión, fecha, responsable y aprobación.
¿Qué diferencia hay entre la declaración de aplicabilidad ISO 27001 y el plan de tratamiento de riesgos?
El plan de tratamiento recoge cómo, quién y cuándo se tratarán los riesgos. La declaración de aplicabilidad ISO 27001 resume qué controles se aplican, por qué y en qué estado están. Ambos nacen del mismo proceso de la cláusula 6.1.3 y deben ser coherentes entre sí.
¿Hay que compartir la SoA ISO 27001 con clientes o terceros?
La norma no obliga a publicarla. Es información documentada del SGSI y puede contener detalles sensibles sobre la seguridad de la organización. Si un cliente la solicita, lo habitual es compartirla bajo acuerdo de confidencialidad o en una versión resumida.
¿Necesitas ayuda con tu declaración de aplicabilidad ISO 27001?
En Gesdata Consulting ayudamos a pymes a elaborar o revisar su declaración de aplicabilidad ISO 27001 dentro de la implantación del SGSI: análisis de riesgos, plan de tratamiento, documentación y preparación de la auditoría. Conoce nuestra consultoría ISO 27001 en Valencia.
Solicitar revisión de mi SoA
