Casi todos los proyectos de ISO 27001 producen una declaración de aplicabilidad, y un número sorprendente de ellas falla de la misma manera. La hoja de cálculo recoge los 93 controles del Anexo A, marca casi todos como aplicables y da el mismo motivo de una línea para cada uno: «requerido por ISO 27001» o «aplica al negocio». Parece completa. Al auditor no le dice casi nada.
La declaración de aplicabilidad no es una lista de comprobación de la norma. Es el registro de las decisiones que tu organización ha tomado sobre su propia seguridad: qué controles necesita, por qué los necesita, cuáles no necesita y por qué no, y hasta dónde ha llegado al implantarlos. Escrita así, es uno de los documentos más útiles del sistema de gestión. Escrita como una lista, es el primer sitio donde el auditor encuentra un hueco.
Qué es la declaración de aplicabilidad
La declaración de aplicabilidad, conocida también como SoA por sus siglas en inglés (Statement of Applicability), es un documento obligatorio en ISO 27001. Recoge todos los controles del Anexo A de la norma y, para cada uno, registra si aplica a la organización, por qué y si está implantado. Es el vínculo entre el análisis de riesgos, donde decides qué podría salir mal, y los controles que realmente operas para evitarlo o limitarlo.
En la práctica, la SoA convierte un análisis de riesgos abstracto en una lista concreta de compromisos. El registro de riesgos puede decir que la pérdida de datos de clientes por un portátil comprometido es un riesgo alto. La SoA es donde ese riesgo se convierte en controles concretos: dispositivos de usuario final (8.1), uso de la criptografía (8.24), eliminación de la información (8.10), y el motivo por el que está cada uno.
También sirve a personas fuera del equipo de seguridad. Las entidades de certificación la usan para planificar la auditoría. Algunos clientes grandes piden verla, o un resumen, durante su due diligence. Las personas que se incorporan a IT o a cumplimiento la leen para entender a qué se ha comprometido la organización. Para todos ellos, lo que la hace útil es la calidad de las justificaciones.
Qué exige la cláusula 6.1.3 d
El requisito está en la cláusula 6.1.3 de ISO 27001:2022, que trata el tratamiento de los riesgos de seguridad de la información. La cláusula pide a la organización determinar todos los controles necesarios para aplicar las opciones de tratamiento elegidas (6.1.3 b), compararlos con el Anexo A para comprobar que no se ha omitido ningún control necesario (6.1.3 c) y, después, elaborar una declaración de aplicabilidad (6.1.3 d).
La SoA debe contener cuatro elementos: los controles necesarios; la justificación de su inclusión; si esos controles están implantados o no; y la justificación de la exclusión de cualquier control del Anexo A. Esos cuatro elementos son el mínimo. Una SoA que enumera controles sin justificarlos, o que marca exclusiones sin explicar por qué, no cumple la cláusula por muy ordenada que esté la hoja de cálculo.
Hay dos detalles que se pasan por alto con facilidad. El primero: los controles necesarios no tienen por qué salir solo del Anexo A. Si el tratamiento de un riesgo exige un control que el anexo no describe, por ejemplo una comprobación contractual concreta sobre los datos de un cliente crítico, también debe figurar en la SoA. El segundo: la norma pregunta si los controles están implantados, así que la SoA tiene que mantenerse fiel a la realidad con el tiempo. Marcar como implantado un control que todavía está en curso es uno de los hallazgos más habituales en una primera certificación.
Cómo se organiza el Anexo A en ISO 27001:2022
La revisión de 2022 reorganizó por completo el Anexo A. Los 114 controles de la versión de 2013, repartidos en 14 dominios, pasaron a ser 93 controles agrupados en cuatro temas. Muchos controles antiguos se fusionaron y se añadieron 11 nuevos, entre ellos la inteligencia de amenazas, la seguridad de la información en el uso de servicios en la nube, la preparación de las TIC para la continuidad de negocio, la prevención de fuga de datos y la codificación segura.
Los cuatro temas son los controles organizativos (37, numerados del 5.1 al 5.37), los de personas (8, del 6.1 al 6.8), los físicos (14, del 7.1 al 7.14) y los tecnológicos (34, del 8.1 al 8.34). Los temas son una forma de agrupar, no una jerarquía: un control físico no es menos importante que uno tecnológico, y la SoA debe leerse control a control, no tema a tema.
El periodo de transición desde la versión de 2013 terminó el 31 de octubre de 2025, así que cualquier certificado vigente hoy se emite conforme a ISO 27001:2022. Si tu SoA todavía usa la numeración antigua o los 14 dominios, hay que rehacerla y no solo renombrar las filas, porque varios controles cambiaron de alcance al fusionarse. El Anexo A solo describe cada control en una frase. ISO 27002 los explica en detalle y es la referencia que usan la mayoría de los equipos para decidir cómo implantarlos.
Cómo decidir qué controles del Anexo A aplican
La aplicabilidad es una decisión, y la norma espera que esa decisión salga de fuentes concretas. Un control aplica porque un riesgo lo exige, porque lo exige una ley o un contrato, o porque el alcance del sistema de gestión lo hace relevante. «Nos pareció sensato» no es una fuente, y tampoco lo es «lo incluyó el consultor».
Empieza por el plan de tratamiento de riesgos
El plan de tratamiento de riesgos es la entrada principal. Para cada riesgo que decidiste tratar, el plan indica los controles que lo reducen. Todos esos controles son aplicables, y la justificación en la SoA debe remitir al riesgo o los riesgos que abordan. Una buena justificación dice algo como «Trata R07 (acceso no autorizado a producción mediante cuentas de administración compartidas) y R12 (imposibilidad de trazar cambios en los datos de clientes)», no «el control de accesos es importante».
Trabajar a partir del plan también saca a la luz huecos en el análisis de riesgos. Si quieres incluir un control al que no apunta ningún riesgo, o el control no hace falta o al análisis se le escapó algo. Las dos respuestas son útiles. La segunda es más frecuente de lo que se espera, sobre todo con riesgos de proveedores y de la nube que nunca se escribieron porque «de eso se encarga el proveedor».
Añade las obligaciones legales, regulatorias y contractuales
Algunos controles aplican al margen de tu propio apetito de riesgo, porque los exige otra persona. La normativa de protección de datos trae consigo la privacidad y la protección de los datos personales (5.34). La regulación sectorial puede exigir registros de actividad, plazos de conservación o notificación de incidentes. Los contratos con clientes piden a menudo controles concretos, como la verificación de antecedentes del personal con acceso a sus datos (6.1) o el cifrado de los datos almacenados (8.24). El control 5.31 pide, precisamente, identificar estos requisitos legales, reglamentarios y contractuales.
Escribe esas obligaciones en la justificación de forma explícita. «Exigido por el contrato marco con nuestro mayor cliente, cláusula 14.2» es preciso y auditable. Además ayuda después: cuando ese contrato termine o cambie, sabrás qué filas de la SoA revisar.
Comprueba los límites del alcance
El alcance del sistema de gestión decide qué controles pueden aplicar. Una empresa cuyo alcance cubre una plataforma SaaS alojada por completo en un proveedor cloud, sin oficinas dentro del alcance, tratará los controles físicos de forma muy distinta a otra que opera su propio centro de datos. Eso no significa que los controles físicos desaparezcan: las oficinas donde se trabaja con datos de clientes, o el teletrabajo, siguen planteando riesgos físicos.
El alcance también es donde se ganan o se pierden muchas exclusiones. Si la declaración de alcance dice que la empresa desarrolla software, excluir los controles de desarrollo seguro (del 8.25 al 8.28) no superará la auditoría. Lee el documento de alcance y la SoA en paralelo antes de cerrar cualquiera de los dos.
Cómo justificar la exclusión de un control
Excluir un control está permitido y a veces es necesario. Lo que pide la norma es una justificación, y lo que comprueba el auditor es si esa justificación se sostiene frente a tu alcance, tus riesgos y las evidencias que encuentra. Una exclusión débil es peor que una inclusión honesta con una implantación parcial, porque indica que la organización no entiende su propio entorno.
Veamos tres casos habituales. En el 8.28, codificación segura, una empresa que compra todo su software y no desarrolla nada puede excluirlo. Una justificación débil dice «No aplica». Una sólida dice «La organización no desarrolla ni modifica software dentro del alcance; todas las aplicaciones son SaaS comerciales, evaluadas mediante los controles de proveedores del 5.19 al 5.22». La versión sólida le dice al auditor qué comprobar: que de verdad no hay desarrollo y que los controles de proveedores existen.
En el 7.4, monitorización de la seguridad física, una empresa en remoto puede argumentar que no tiene instalaciones que vigilar. Una justificación débil dice «Trabajamos en remoto». Una sólida dice «No hay instalaciones dentro del alcance; el personal teletrabaja según la política de trabajo en remoto (6.7) y los equipos fuera de las instalaciones están cubiertos por el 7.9. La monitorización del centro de datos la presta el proveedor cloud y se verifica mediante su certificado ISO 27001 y su informe SOC 2». Muestra que el riesgo se valoró y se trasladó a otro sitio, no que se ignoró.
En el 5.23, seguridad de la información en el uso de servicios en la nube, una exclusión casi nunca es creíble hoy. Incluso una empresa sin infraestructura cloud propia usa correo, almacenamiento de archivos y herramientas de colaboración en la nube. Una exclusión aquí suele significar que nunca se inventariaron los servicios en la nube, lo que ya es un hallazgo. La prueba para cualquier exclusión es la misma: ¿podría el auditor recorrer la empresa y encontrar algo que la contradiga?
Plantilla: las columnas que necesita toda SoA
Una declaración de aplicabilidad puede ser una hoja de cálculo, una tabla en un documento o una vista en una plataforma de cumplimiento. El formato importa menos que las columnas. Estas son las que necesita para cumplir la cláusula y para ser útil después.
- Referencia y nombre del control. El número y el título del Anexo A, por ejemplo 5.15 Control de accesos, más los controles adicionales que no salen del Anexo A.
- Aplica: sí o no. Una decisión clara para cada control, sin celdas vacías y sin «parcialmente».
- Justificación de la inclusión o la exclusión. Los identificadores de riesgo, las obligaciones legales o contractuales, o los motivos de alcance que sostienen la decisión.
- Estado de implantación. Implantado, parcialmente implantado o planificado, con fecha objetivo para lo que aún no esté.
- Cómo se implanta. Una descripción breve o una referencia a la política, el procedimiento o el sistema que lo aplica.
- Responsable. La persona o el puesto que opera el control.
- Evidencia. Dónde puede ver el auditor que el control funciona: un registro, un informe, un ticket, un acta de revisión.
Las tres últimas columnas no las exige estrictamente la cláusula 6.1.3 d, pero son las que convierten la SoA de una declaración en un documento de trabajo. Sin responsable, nadie mantiene el control. Sin referencia a la evidencia, cada auditoría empieza con una búsqueda.
Qué revisa el auditor en la SoA
Los auditores de certificación usan la SoA como mapa del sistema de gestión. En la auditoría de fase 1 la revisan junto con el alcance, el análisis de riesgos y el plan de tratamiento, y comprueban que los tres son coherentes. Los controles del plan de tratamiento deben figurar como aplicables en la SoA, y las exclusiones no deben contradecir el alcance ni los riesgos. Las incoherencias en esta fase suelen generar hallazgos antes de que empiece la auditoría principal.
En la auditoría de fase 2, el auditor toma muestras. Elige controles marcados como aplicables e implantados y pide verlos funcionar: la revisión de accesos que, según el control 5.18, se hace cada trimestre; la prueba de restauración de copias detrás del 8.13; la evaluación de proveedores detrás del 5.21. También elige exclusiones y las contrasta con lo que ve. Un control excluido que resulta ser relevante es una no conformidad, y hace dudar del resto del documento. En qué evalúa realmente una auditoría de certificación explicamos este muestreo con más detalle.
Por último, el auditor mira fechas y versiones. Una SoA actualizada por última vez hace un año, en una empresa que desde entonces ha cambiado de proveedor cloud o ha lanzado un producto, le dice que el documento no forma parte del funcionamiento real de la organización. Esa impresión suele influir en el resto de la auditoría.
Cómo mantener la SoA al día entre auditorías
La SoA debe cambiar cada vez que cambien las entradas que la produjeron. Un nuevo riesgo en el registro, un nuevo proveedor que trata datos sensibles, un nuevo contrato con cláusulas de seguridad, un cambio de alcance, un sistema nuevo o uno retirado: cada uno puede hacer aplicable un control, cambiar su justificación o modificar su estado de implantación. Esperar a la siguiente auditoría para ponerse al día convierte una actualización pequeña en una reconstrucción.
La forma más sencilla de mantenerla al día es vincularla a los procesos que ya existen. Cuando se revise el registro de riesgos, revisa en la misma reunión las filas de la SoA afectadas. Cuando se dé de alta un proveedor, comprueba si hay que actualizar los controles de proveedores. Cuando se celebre la revisión por la dirección que exige la cláusula 9.3, incluye la SoA entre las entradas y deja constancia de las decisiones. Cada versión de la SoA debe tener fecha, responsable y una nota breve de lo que cambió.
Aquí se ve la diferencia entre un sistema de gestión de seguridad de la información y un conjunto de documentos. En un SGSI que funciona, la SoA, el registro de riesgos y las evidencias están conectados, así que un cambio en uno se refleja en los demás. En la plataforma Qalea, la SoA y el registro de riesgos están en el mismo sitio que las evidencias, de modo que las decisiones de aplicabilidad y el estado de implantación siguen vinculados a los controles que describen.
La declaración de aplicabilidad en el ENS
En España, «declaración de aplicabilidad» designa también un documento del Esquema Nacional de Seguridad, y no es lo mismo que la de ISO 27001. El Real Decreto 311/2022 exige formalizar en una declaración de aplicabilidad la relación de medidas de seguridad seleccionadas del anexo II, y esa declaración la firma el responsable de la seguridad.
La diferencia de fondo está en cómo se seleccionan las medidas. En ISO 27001, los controles salen del análisis de riesgos de cada organización. En el ENS, el punto de partida es la categoría del sistema (básica, media o alta), que se determina valorando la información y los servicios en las dimensiones de seguridad. Esa categoría fija qué medidas del anexo II son exigibles y con qué refuerzos. El análisis de riesgos sigue siendo necesario, pero sirve sobre todo para justificar medidas adicionales o medidas compensatorias, que sustituyen a una medida exigida por otra que proteja de forma equivalente y que deben quedar documentadas.
Las organizaciones que necesitan ambos marcos pueden mantener un solo conjunto de controles y relacionarlo con las dos declaraciones, en lugar de llevar dos documentos que se desactualizan por separado. Lo explicamos en gestionar ISO 27001 y el ENS como un programa único. Si todavía no tienes claro qué categoría y qué tipo de conformidad te corresponden, empieza por si el ENS se aplica a tu empresa y en qué nivel. Para más sobre la norma, consulta los artículos de ISO 27001.
