Declaración de Aplicabilidad (SoA) de ISO 27001: qué es y cómo hacerla
La Declaración de Aplicabilidad (SoA, por Statement of Applicability) es el documento obligatorio de ISO 27001 en el que la organización indica qué controles necesita para tratar sus riesgos, por qué los incluye, si ya están implantados y por qué excluye los controles del Anexo A que no aplica. Lo exige la cláusula 6.1.3 d).
Es uno de los documentos más consultados en la auditoría: conecta el análisis de riesgos con los controles que el auditor va a comprobar.
Qué debe contener la SoA según ISO 27001:2022
| Contenido | Explicación |
|---|---|
| Controles necesarios | Los que resultan del tratamiento de riesgos, sean del Anexo A o de otras fuentes |
| Justificación de su inclusión | Riesgo que tratan, requisito legal o contractual, o decisión de negocio |
| Estado de implantación | Si cada control está implantado o no |
| Justificación de las exclusiones | Por qué no se aplica cada control del Anexo A que se deja fuera |
La norma no fija el formato. Puede ser una hoja de cálculo, un documento o un informe de una herramienta de gestión.
Plantilla de columnas recomendada
| Columna | Ejemplo |
|---|---|
| Control | A.8.13 Copias de seguridad de la información |
| ¿Aplica? | Sí |
| Justificación | Riesgo R-07 de pérdida de datos por ransomware; contrato con cliente X exige recuperación en 24 h |
| Estado | Implantado |
| Cómo se aplica | Copias diarias, una copia inmutable, prueba de restauración trimestral |
| Documento o evidencia | Política de copias v2.1, informes de prueba de restauración |
| Responsable | Responsable de sistemas |
| Fecha de última revisión | [fecha] |
Las tres últimas columnas no las exige la norma, pero facilitan mucho la auditoría y el mantenimiento.
Cómo justificar una exclusión
Una exclusión se acepta cuando el control no responde a ningún riesgo identificado ni a ningún requisito aplicable. Ejemplos:
| Control | Exclusión bien justificada | Exclusión mal justificada |
|---|---|---|
| A.8.25 a A.8.31 (desarrollo) | La organización no desarrolla software; las aplicaciones se compran como servicio y se controlan con A.5.23 | «No aplica» |
| A.7.4 Supervisión de la seguridad física | Sin instalaciones propias en el alcance; el centro de datos es del proveedor cloud, certificado ISO 27001, y se controla con A.5.23 | «No tenemos oficinas» sin explicar dónde está la información |
| A.8.11 Enmascaramiento de datos | No se tratan datos personales ni confidenciales fuera de producción, según el análisis de riesgos | «Demasiado caro» |
El coste no es por sí solo una justificación. Si un control es necesario pero se decide aceptar el riesgo, esa aceptación la aprueba el propietario del riesgo y queda registrada en el tratamiento de riesgos.
Cómo elaborar la SoA paso a paso
- Completar la evaluación y el tratamiento de riesgos.
- Listar los controles necesarios según el plan de tratamiento.
- Recorrer los 93 controles del Anexo A y marcar cuáles aplican.
- Añadir controles de otras fuentes si se usan, como medidas del ENS.
- Justificar cada inclusión y cada exclusión.
- Indicar el estado de implantación y la evidencia.
- Aprobarla, versionarla y revisarla con cada cambio relevante en riesgos o alcance.
Relación entre la SoA, el análisis de riesgos y el plan de tratamiento
| Documento | Pregunta que responde | Cláusula |
|---|---|---|
| Informe de evaluación de riesgos | ¿Qué riesgos hay y cuánto pesan? | 6.1.2, 8.2 |
| Plan de tratamiento de riesgos | ¿Qué haremos con cada riesgo, quién y cuándo? | 6.1.3 e), 8.3 |
| Declaración de Aplicabilidad | ¿Qué controles aplicamos, por qué, en qué estado y qué excluimos? | 6.1.3 d) |
Los tres deben ser coherentes. Un riesgo tratado con un control que la SoA marca como excluido es una no conformidad habitual.
Errores frecuentes
- Hacer la SoA antes del análisis de riesgos.
- Justificar con «no aplica» o «no procede».
- No actualizarla tras cambios de alcance, de proveedores o de riesgos.
- Marcar como implantados controles sin evidencia.
- No indicar la versión de la SoA, que figura en el certificado.
Preguntas frecuentes sobre la Declaración de Aplicabilidad
Sí. La exige la cláusula 6.1.3 d) de ISO 27001:2022 y no se puede certificar sin ella.
Debe pronunciarse sobre todos los controles del Anexo A: los que aplica, con su justificación y estado, y los que excluye, con su justificación.
La norma no fija un plazo. Se revisa cuando cambian los riesgos, el alcance o los requisitos, y como mínimo en la revisión por la dirección.
El certificado suele hacer referencia a la versión vigente de la Declaración de Aplicabilidad en la fecha de emisión.
