Cómo hacer la declaración de aplicabilidad de ISO 27001: paso a paso, con un ejemplo y una plantilla
La respuesta corta: la declaración de aplicabilidad no se rellena, se deduce. Sale del tratamiento de riesgos. Primero decides cómo tratas cada riesgo y qué controles necesitas para hacerlo. Después comparas esos controles con los 93 del anexo A, para no dejarte ninguno. Y al final escribes, control a control, si lo necesitas, por qué, si ya está implantado y, si lo excluyes, por qué. Eso es lo que pide el apartado 6.1.3 d) de ISO/IEC 27001:2022, y es lo primero que abre el auditor.
El resto del artículo es el método en cinco pasos, aplicado a ACME, los errores que más veo en auditoría y una plantilla para hacer la tuya.
Qué tiene que llevar, según la norma
El apartado 6.1.3 d) pide cuatro cosas. Ni una más, ni una menos:
| Lo que pide | Pregunta que responde | De dónde sale |
|---|---|---|
| Los controles necesarios | ¿Qué controles aplicas? | Del plan de tratamiento de riesgos (6.1.3 b) |
| La justificación de su inclusión | ¿Por qué lo aplicas? | Del riesgo que trata, de una ley, de un contrato o de una decisión de la dirección |
| Si están implantados o no | ¿Funciona hoy? | De la evidencia del control |
| La justificación de las exclusiones | ¿Por qué no aplicas los demás controles del anexo A? | De que no hay riesgo, actividad ni obligación que lo pida |
Todo lo demás es útil, pero no obligatorio: el responsable, la referencia al riesgo, la evidencia, la fecha de la última revisión. Yo lo pondría siempre. Es lo que te ahorra explicaciones el día de la auditoría.
Paso 1. Parte del tratamiento de riesgos, no del anexo A
El error de partida más común es abrir el anexo A y recorrer los 93 controles preguntando «¿esto lo tenemos?». Así sale una lista de lo que ya haces, no de lo que necesitas.
El orden de la norma es el contrario. En el análisis de riesgos identificas qué puede pasar. En el tratamiento decides qué haces con cada riesgo. Si lo mitigas, eliges los controles que lo bajan. Esos controles pueden venir del anexo A, de otra norma o de tu propia organización. La norma lo admite: el anexo A no es obligatorio en sí, es la lista con la que te comparas.
Además de los riesgos, hay controles que entran porque alguien te los exige. Una ley como el RGPD o NIS2, un contrato con un cliente o un requisito de la dirección. Apúntalos también, con su origen.
Paso 2. Compara con los 93 controles del anexo A
Con tu lista de controles hecha, recorre el anexo A para comprobar que no te has dejado ninguno necesario. Es lo que pide el apartado 6.1.3 c). Desde la versión de 2022 son 93 controles en cuatro grupos:
| Grupo | Controles | Ejemplos |
|---|---|---|
| 5. Organizativos | 37 | Políticas, proveedores (5.19 a 5.23), incidentes, continuidad |
| 6. De personas | 8 | Selección, formación, teletrabajo (6.7) |
| 7. Físicos | 14 | Perímetros, puestos despejados, equipos fuera de las instalaciones |
| 8. Tecnológicos | 34 | Accesos, copias, registros, desarrollo seguro |
Si al comparar encuentras un control que mitiga un riesgo que no habías tratado, la conclusión no es «añadirlo a la SoA». Es volver al análisis de riesgos, porque te faltaba un riesgo.
Paso 3. Escribe la justificación de cada control
Para cada control incluido, una frase que diga por qué: el riesgo que trata, con su referencia, o la obligación de la que sale. «Buena práctica» no es una justificación. El auditor va a preguntar qué riesgo baja.
Para cada control excluido, una frase que diga por qué no hace falta. La exclusión válida siempre tiene la misma forma: no existe la actividad, el activo o la obligación que el control protege. «No desarrollamos software» justifica excluir la codificación segura (8.28). «No tenemos presupuesto» no justifica nada: eso es un riesgo aceptado, y va en el tratamiento de riesgos, firmado por quien lo acepta.
Paso 4. Marca el estado con su evidencia
La norma pide decir si cada control está implantado o no. En la práctica, tres estados son más útiles que dos: implantado, en curso y pendiente. Y para cada control implantado, dónde está la prueba: el procedimiento, el registro, la captura o el informe.
Un control marcado como implantado sin evidencia localizable es el hallazgo más fácil de la auditoría. Los que están en curso o pendientes deben aparecer en el plan de tratamiento, con responsable y fecha.
Paso 5. Apruébala y ponle versión
La SoA es información documentada. Tiene que llevar versión, fecha y quién la aprueba. Revísala, como mínimo, cada vez que revises el análisis de riesgos, y siempre que cambie el alcance, un proveedor importante o una obligación legal. Una SoA que no ha cambiado en dos años dice que el SGSI tampoco.
Un ejemplo completo: la SoA de ACME
ACME desarrolla y vende un software de gestión en la nube. Tiene 120 personas, la mayoría en teletrabajo. Aloja su producto en un proveedor de nube europeo y encarga parte del desarrollo de la aplicación móvil a un estudio externo. Su alcance de certificación es «el desarrollo, la operación y el soporte de la plataforma de ACME».
Estas son seis filas de su declaración de aplicabilidad. Las he elegido porque en cada una hay una decisión que no es obvia:
| Control | ¿Se aplica? | Justificación | Estado | Evidencia |
|---|---|---|---|---|
| 5.23 Seguridad en el uso de servicios en la nube | Sí | R-04: caída o pérdida de datos en el proveedor de nube que aloja el producto. Además, lo exigen los contratos con clientes | Implantado | Procedimiento de adquisición de servicios en la nube y evaluación anual del proveedor |
| 6.7 Trabajo en remoto | Sí | R-09: acceso desde equipos y redes fuera de la oficina. El 80 % de la plantilla teletrabaja | Implantado | Política de teletrabajo y configuración de la VPN y del gestor de dispositivos |
| 7.4 Monitorización de la seguridad física | Sí | R-12: acceso no autorizado a la oficina, donde están los equipos de red y el archivo de contratos | En curso | Cámaras instaladas; falta el registro de revisiones. Plan: T-07, marzo |
| 8.28 Codificación segura | Sí | R-02: vulnerabilidades en el código del producto. ACME desarrolla su propio software | Implantado | Guía de desarrollo seguro y análisis estático en cada integración |
| 8.30 Desarrollo externalizado | Sí | R-15: vulnerabilidades en la aplicación móvil que desarrolla un tercero | Pendiente | Plan: T-11, cláusulas y revisión de código en el próximo contrato, abril |
| 7.13 Mantenimiento de los equipos | No | ACME no tiene CPD propio ni equipos de producción en sus instalaciones: el mantenimiento de la infraestructura es del proveedor de nube y se cubre con 5.23 | No aplica |
Fíjate en tres cosas. La justificación de cada inclusión lleva la referencia del riesgo, así el auditor puede seguir el hilo hasta el análisis. Lo que está en curso o pendiente apunta a una tarea del plan de tratamiento, con fecha. Y la exclusión de 7.13 no dice «no aplica» a secas: dice por qué no existe lo que el control protege y qué otro control cubre el riesgo.
Mi criterio para los casos dudosos
La norma deja algunas decisiones a tu juicio. En estas tres, mi criterio es el siguiente:
- Controles cubiertos por un proveedor. Si tu proveedor de nube se encarga de la seguridad física del centro de datos, el control no se excluye sin más. Se incluye o se excluye según tu alcance, y el riesgo se trata con los controles de proveedores, de 5.19 a 5.23. Excluir todos los controles físicos porque «está todo en la nube» suele terminar en hallazgo: las oficinas, los portátiles y los papeles siguen existiendo.
- Controles «a medias». Si el control funciona en una parte del alcance y en otra no, márcalo como en curso y di dónde falta. Es mejor que un «implantado» que el auditor desmiente con una muestra.
- Controles de más. Incluir un control que no trata ningún riesgo ni responde a ninguna obligación no te protege de nada en la auditoría. Te obliga a enseñar su evidencia.
Y si además tienes el ENS
El Esquema Nacional de Seguridad también pide una declaración de aplicabilidad, firmada por el responsable de la seguridad, con las medidas del anexo II del Real Decreto 311/2022 que se aplican según la categoría del sistema. La lógica es parecida, pero las medidas no son los controles del anexo A. Si tienes que cumplir las dos, mantén una sola tabla de controles y evidencias y saca de ella las dos declaraciones. Lo que no conviene es llevar dos hojas de cálculo que se contradicen.
Los errores más frecuentes
- Hacerla antes del análisis de riesgos. Sale una lista de lo que ya tienes y nadie sabe explicar por qué cada control está ahí.
- Justificaciones genéricas. «Requerido por la norma» o «buena práctica» no responden a por qué lo necesitas tú.
- Implantado sin evidencia. Si no puedes enseñar la prueba en dos minutos, no está implantado a ojos del auditor.
- Exclusiones por coste. Lo que no haces por coste es un riesgo aceptado, no un control que no aplica.
- Una SoA que no cambia. Si el análisis de riesgos se revisa cada año y la SoA tiene la misma fecha desde la certificación, una de las dos no es cierta.
- Seguir con los controles de 2013. La transición a la versión de 2022 terminó el 31 de octubre de 2025. Una SoA con 114 controles está desfasada.
Plantilla para hacer la tuya
Estas son las columnas que yo usaría. Las cinco primeras cubren lo que pide la norma; las demás son las que te ahorran trabajo en la auditoría:
| Columna | Qué poner |
|---|---|
| Control | Número y nombre del anexo A, o el código de tu control propio |
| ¿Se aplica? | Sí o no |
| Justificación | La referencia del riesgo o la obligación, o por qué se excluye |
| Estado | Implantado, en curso o pendiente |
| Evidencia | Dónde está la prueba |
| Responsable | Quién lo mantiene |
| Plan | La tarea del plan de tratamiento, si no está implantado |
| Última revisión | Fecha |
Puedes descargarla en CSV, con las seis filas de ACME ya rellenas, y abrirla con Excel o con LibreOffice.
Cómo dejarla resuelta
Una SoA en una hoja de cálculo se queda vieja en cuanto alguien cambia un riesgo y no se acuerda de tocarla. Y la evidencia suele estar en otra carpeta, con otro nombre.
En Almenara, el módulo de Cumplimiento mantiene la declaración de aplicabilidad de cada norma con su justificación, su estado y su evidencia. El riesgo de cada proveedor entra en los controles 5.19 a 5.22 sin copiarlo a mano, y una evidencia subida una vez cuenta para todas las normas que la piden. La SoA se exporta en PDF, Word o Excel. Si prefieres empezar con nosotros, el análisis de diferencias deja el estado de cada control en tu declaración de aplicabilidad. Y en la guía de ISO 27001 tienes el resto de lo que pide la norma.
Preguntas frecuentes
¿Es obligatoria la declaración de aplicabilidad?
Sí. La pide el apartado 6.1.3 d) de ISO/IEC 27001:2022 y sin ella no hay certificación. El auditor la revisa en la primera fase de la auditoría.
¿Hay que incluir los 93 controles del anexo A?
Hay que pronunciarse sobre los 93: decir si cada uno se aplica o no y por qué. No hay que aplicarlos todos.
¿Se pueden añadir controles que no estén en el anexo A?
Sí. Si tu tratamiento de riesgos necesita un control que no está en el anexo A, inclúyelo en la SoA con su propio código y su justificación.
¿Quién tiene que aprobarla?
La norma no lo dice, pero lo habitual y lo sensato es que la apruebe la dirección o el responsable del SGSI con su autorización, porque con ella acepta qué se hace y qué no.
¿Cada cuánto hay que revisarla?
Cada vez que revises el análisis de riesgos, que debería ser al menos una vez al año, y siempre que cambie el alcance, la organización o una obligación legal.
¿La SoA es pública?
No. Es un documento interno del SGSI. Algunos clientes la piden al evaluar a un proveedor; puedes enseñarla con un acuerdo de confidencialidad o entregar una versión sin el detalle de la evidencia.
Fuentes
José Ramón Santos Crespo
Fundador de Almenara. Trabaja en gobierno, riesgo y cumplimiento de ciberseguridad y prepara organizaciones para sus auditorías.
Para comparar opciones
¿Quieres verlo aplicado a tus proveedores?
Una reunión con tus propios cuestionarios y evidencias, no una presentación genérica.
Solicitar información