Declaración de Aplicabilidad (SoA): cómo elaborarla paso a paso

La Declaración de Aplicabilidad (Statement of Applicability o SoA) es el documento central de cualquier SGSI ISO 27001. Es donde se recoge, control a control, qué aplicas, qué no y por qué. Sin una SoA bien construida, la auditoría de certificación se complica mucho. En este artículo te explicamos qué tiene que contener, cómo se elabora paso a paso y cuáles son los errores más frecuentes.

Qué es la Declaración de Aplicabilidad

La SoA es un documento exigido explícitamente por la cláusula 6.1.3 d) de ISO 27001:2022. Debe identificar para cada uno de los 93 controles del Anexo A:

• Si el control es aplicable o no al alcance del SGSI
• La justificación de su inclusión o exclusión
• Si está implementado total, parcialmente o no implementado
• Los controles adicionales (fuera del Anexo A) incorporados por análisis de riesgos

Es el puente entre tu análisis de riesgos y los controles reales que estás aplicando. Un auditor puede descartar controles que no apliquen a tu organización, pero siempre exigirá que lo justifiques documentalmente.

Por qué es tan importante

La SoA cumple tres funciones críticas:

• Trazabilidad: conecta cada riesgo identificado con los controles que lo mitigan
• Auditoría: es el primer documento que revisa el auditor externo para planificar su trabajo
• Gestión interna: sirve como hoja de ruta para saber qué estado tiene cada control y qué falta por implementar

Qué debe contener la SoA para cada control

Una entrada tipo de la SoA, bien construida, incluye como mínimo:

• Código y nombre del control (por ejemplo, A.5.1 Policies for information security)
• Descripción breve del objetivo del control
• Estado de aplicabilidad: aplica / no aplica
• Justificación textual (no basta con "sí" o "no")
• Referencia al riesgo o riesgos que mitiga
• Estado de implementación: implementado / parcial / no implementado
• Evidencia: referencia a los documentos, procedimientos o sistemas que lo soportan
• Responsable del control
• Fecha de última revisión

Los pasos para elaborar una SoA

1. Definir el alcance del SGSI

Antes de cualquier análisis de controles, tiene que estar claro qué forma parte del SGSI y qué queda fuera. Unidades de negocio, localizaciones, sistemas, procesos. La SoA se elabora siempre sobre un alcance concreto, y cambiar el alcance obliga a revisar la SoA.

2. Realizar el análisis de riesgos

Los controles se eligen en función de los riesgos. Sin un análisis de riesgos previo (normalmente siguiendo ISO 27005), la selección de controles se convierte en un ejercicio arbitrario que el auditor te cuestionará.

3. Seleccionar los controles del Anexo A

Para cada riesgo identificado, se determina qué controles del Anexo A ayudan a mitigarlo. Un mismo control puede aplicarse a varios riesgos, y un mismo riesgo puede requerir varios controles. La trazabilidad explícita entre riesgo y control es fundamental.

4. Justificar las exclusiones

Excluir un control es legítimo, pero cada exclusión tiene que estar razonada. "No aplica porque no tenemos teletrabajo" o "excluido porque no desarrollamos software propio" son justificaciones válidas. "No aplica" a secas, no lo es.

5. Identificar la evidencia

Por cada control aplicable, hay que documentar qué evidencia demuestra su implementación: políticas, procedimientos, registros, configuraciones, logs, actas de reunión. Si no hay evidencia, para el auditor el control no está implementado, por muy bien que se haga en la práctica.

6. Revisar con dirección y aprobar

La SoA es un documento del máximo nivel: debe aprobarla la alta dirección y revisarla formalmente. Una SoA firmada solo por el responsable de seguridad no resiste una auditoría rigurosa.

7. Mantener viva la SoA

La SoA no se elabora una vez y se olvida. Se revisa al menos anualmente, cuando cambian los riesgos, cuando se modifica el alcance o cuando se añaden nuevos sistemas. Es el documento más dinámico del SGSI.

Errores frecuentes en la SoA

Estos son los problemas que detectamos con más frecuencia en auditorías internas:

• Justificaciones genéricas: "aplica porque sí". El auditor no se queda con eso
• Copiar la SoA del proveedor: cada organización tiene riesgos propios; copiar es la forma más rápida de fallar
• Excluir controles sin analizarlos: "no hacemos desarrollo de software" sin verificar si realmente no lo hay
• No actualizar la versión 2013 a 2022: la estructura cambió; la SoA tiene que reflejar los 93 controles actuales
• No incluir los 11 controles nuevos: hay que valorarlos de forma explícita uno por uno
• Falta de trazabilidad con riesgos: controles que no responden a ningún riesgo del análisis
• Evidencia inexistente: marcar "implementado" sin identificar qué lo demuestra

Formato de la SoA

La norma no impone un formato concreto. Lo más habitual es una hoja de cálculo con una fila por control, pero algunas organizaciones usan herramientas GRC (eRamba, OneTrust, Vanta) que integran la SoA con el resto del SGSI. Para empresas pequeñas, un Excel bien mantenido funciona perfectamente. Para empresas más grandes, conviene invertir en herramienta.

SoA y análisis de riesgos: la diferencia

Es una confusión habitual: la SoA no sustituye al análisis de riesgos, ni al revés. Son documentos complementarios. El análisis de riesgos identifica qué proteger y de qué; la SoA recoge qué controles aplicas para lograrlo. Sin uno, el otro pierde sentido.