Qué es la Declaración de Aplicabilidad y cómo elaborarla correctamente

El SoA como documento central del SGSI

La Declaración de Aplicabilidad, conocida habitualmente por sus siglas en inglés SoA (Statement of Applicability), es el documento que recoge las decisiones de la organización sobre cuáles de los 93 controles del Anexo A de ISO 27001:2022 son aplicables a su contexto y cuáles no. Para cada control aplicable, documenta el estado de implementación. Para cada control excluido, documenta la justificación de esa exclusión.

El SoA no es un formulario burocrático. Es la materialización escrita del razonamiento de seguridad de la organización: por qué se protege lo que se protege, con qué medios y con qué alcance. Un auditor experimentado puede leer un SoA y tener en minutos una imagen muy precisa del nivel de madurez real del SGSI.

Requisito normativo: cláusula 6.1.3 de ISO 27001:2022

La obligación de elaborar y mantener una Declaración de Aplicabilidad está recogida en la cláusula 6.1.3 de ISO/IEC 27001:2022, bajo el epígrafe "Tratamiento de los riesgos de seguridad de la información". Esta cláusula establece que la organización debe:

• Determinar todos los controles necesarios para implementar las opciones de tratamiento de riesgos seleccionadas.
• Comparar esos controles con los del Anexo A para verificar que no se ha omitido ningún control necesario.
• Elaborar una Declaración de Aplicabilidad que contenga todos los controles necesarios y la justificación de su inclusión o exclusión.
• Mantener la SoA como información documentada.

El estándar es taxativo: la SoA no es opcional. Su ausencia es una no conformidad mayor que impide la certificación.

Qué debe contener un SoA completo

Un SoA conforme a ISO 27001:2022 debe incluir, para cada uno de los 93 controles del Anexo A, al menos la siguiente información:

• Identificación del control: número y nombre del control según la norma (por ejemplo, 8.8 Gestión de vulnerabilidades técnicas).
• Aplicabilidad: si el control es aplicable (Sí) o no aplicable (No) al alcance del SGSI.
• Justificación de la inclusión (para los controles aplicables): la razón por la que el control está incluido. Puede ser una o varias de las siguientes: resultado del análisis de riesgos, requisito legal o reglamentario, obligación contractual, buena práctica adoptada voluntariamente.
• Estado de implementación (para los controles aplicables): si el control está implementado, en proceso de implementación o pendiente.
• Justificación de la exclusión (para los controles no aplicables): la razón por la que el control no aplica al contexto de la organización.

Muchas organizaciones añaden también referencias a los procedimientos, políticas o evidencias que documentan la implementación del control, lo cual facilita enormemente la auditoría.

Cómo justificar la inclusión de un control

Incluir un control en el SoA es la decisión que menos atención suele recibir, porque parece lo "seguro" por defecto. Pero la justificación debe ser explícita y fundamentada. Hay tres fuentes legítimas de justificación:

• Gestión de riesgos: el análisis de riesgos ha identificado una amenaza cuya probabilidad o impacto justifica la aplicación del control. Esta es la justificación más sólida y la más valorada por los auditores, porque demuestra que el control nace de un razonamiento de riesgo, no de una lista de verificación genérica.
• Requisito legal o reglamentario: una norma aplicable (RGPD, NIS2, regulación sectorial) exige medidas que se materializan en ese control.
• Obligación contractual: un cliente, socio o proveedor exige contractualmente la implementación de ese control como condición de la relación comercial.

Un control puede tener varias justificaciones simultáneas. De hecho, es habitual y refuerza la solidez del SoA.

Cómo justificar la exclusión de un control

Excluir un control es una decisión que requiere argumentación rigurosa. La cláusula 6.1.3 permite la exclusión, pero solo si la organización puede demostrar que esa exclusión no compromete los objetivos de seguridad ni el cumplimiento de los requisitos aplicables.

Las justificaciones de exclusión aceptables son, principalmente:

• El control hace referencia a una tecnología, proceso o situación que no existe en el contexto de la organización. Por ejemplo, excluir el control 7.1 (Perímetros de seguridad física) si la organización opera íntegramente en modalidad de trabajo remoto sin instalaciones físicas propias, siempre que esto sea real y verificable.
• El riesgo que el control mitiga no es relevante para el contexto de la organización según el análisis de riesgos.

Lo que no es una justificación aceptable: que el control sea difícil de implementar, costoso, o que la organización "no lo considere prioritario". El auditor rechazará estas justificaciones. No se excluye por comodidad.

Los errores más frecuentes en el SoA

• Justificaciones genéricas: "No aplicable por ser una empresa pequeña" o "No aplicable dado el alcance" son justificaciones que no dicen nada. Cada exclusión necesita una razón específica vinculada al contexto real de la organización.
• SoA desconectado del análisis de riesgos: si la selección de controles no se puede trazar hasta el análisis de riesgos, el SoA es un documento decorativo. El auditor pedirá esa trazabilidad.
• Estado de implementación optimista: marcar como "implementado" un control que en realidad solo tiene una política escrita pero no se aplica en la práctica es una de las principales causas de no conformidades en auditoría.
• SoA estático: elaborar el SoA una vez y no actualizarlo. El SoA debe reflejar la realidad del SGSI en cada momento. Si cambia el alcance, el contexto o el análisis de riesgos, el SoA debe actualizarse.
• Excluir controles nuevos de la versión 2022 sin revisarlos: los once controles incorporados en 2022 son novedosos y algunos equipos de implantación los omiten por desconocimiento. Todos deben ser evaluados.

Diferencia entre SoA y plan de tratamiento de riesgos

El SoA y el plan de tratamiento de riesgos son documentos distintos pero complementarios, y a menudo se confunden.

El plan de tratamiento de riesgos define qué riesgos se tratan, con qué opción (reducir, aceptar, transferir, evitar), qué controles se aplican para tratar cada riesgo, quién es responsable y en qué plazo. Es un documento orientado a la acción.

El SoA hace referencia a todos los controles del Anexo A (no solo a los que tratan riesgos específicos) y declara si cada uno es aplicable o no. Es un documento orientado a la declaración de conformidad.

La relación entre ambos: los controles seleccionados en el plan de tratamiento de riesgos deben estar marcados como aplicables en el SoA. Pero el SoA puede incluir controles adicionales que no provienen del análisis de riesgos, sino de obligaciones legales o contractuales.

Cómo mantener el SoA actualizado

La cláusula 6.1.3 exige mantener el SoA como información documentada, lo que implica que debe gestionarse con control de versiones, fecha de revisión y responsable de aprobación.

La revisión mínima recomendada es anual, coincidiendo con la revisión por la dirección del SGSI. Pero hay situaciones que deben desencadenar una revisión extraordinaria: un cambio significativo en el alcance del SGSI, la incorporación de nuevas tecnologías o servicios, un incidente de seguridad relevante, o cambios en la legislación aplicable.

En organizaciones con un SGSI maduro, el SoA se actualiza de forma continua a medida que avanzan los proyectos de implementación y se completan controles que estaban en estado "pendiente" o "en proceso".

El SoA en la auditoría: qué mira el auditor

En la auditoría de certificación, el SoA es uno de los primeros documentos que el auditor solicita. Las preguntas que guían su revisión son:

• ¿Están incluidos los 93 controles del Anexo A?
• ¿Las justificaciones de inclusión son trazables al análisis de riesgos o a requisitos legales y contractuales reales?
• ¿Las justificaciones de exclusión son coherentes con el contexto de la organización?
• ¿El estado de implementación declarado coincide con la evidencia observada durante la auditoría in situ?
• ¿El SoA está actualizado y aprobado por la dirección?

Una SoA sólida no garantiza la certificación por sí sola, pero una SoA deficiente casi garantiza no conformidades. Es el documento que mejor refleja si la organización ha comprendido el estándar o si simplemente lo ha copiado de una plantilla.