SoA de ISO 27001: la Declaración de Aplicabilidad sin líos

Publicado el 11 de agosto de 2026

Miguel Penadés

Consultor de ciberseguridad y cumplimiento

Revisado por el autor el 11 de agosto de 2026

¿Qué es la SoA de ISO 27001?

La SoA (Statement of Applicability, o Declaración de Aplicabilidad) es el documento obligatorio de ISO/IEC 27001:2022 donde declaras, control por control, cuáles aplican en tu SGSI y por qué, si están implementados o no, y la justificación de cada exclusión. No se rellena desde una plantilla: sale de tu análisis de riesgos.

Traducido: tu SGSI (el sistema de gestión de seguridad de la información que la norma te obliga a documentar) puede acumular cientos de decisiones sobre controles, y la SoA es donde quedan todas registradas y justificadas en un solo sitio. Es el documento que el auditor abre primero, porque le dice exactamente qué le vas a tener que enseñar.

Qué tiene que llevar la SoA: los cuatro elementos obligatorios

La cláusula 6.1.3.d de la norma exige que la Declaración de Aplicabilidad contenga cuatro elementos. La guía CCN-STIC 825 del Centro Criptológico Nacional recoge estos mismos cuatro elementos en español: qué controles son necesarios, por qué se incluye cada uno, si ya están implementados, y por qué se excluye, en su caso, cualquier control del Anexo A.

Desglosado, cada fila de tu SoA tiene que responder a esto:

1. Los controles necesarios. No los saca del Anexo A: salen de tu tratamiento de riesgos (6.1.3.b), y pueden venir de cualquier fuente.
2. La justificación de cada inclusión. Por qué ese control está ahí: qué riesgo trata o qué requisito lo exige.
3. El estado de implementación. Si está implantado o no. En la práctica muchas empresas lo expresan como grado de madurez —implantado y en qué nivel—, como describe el propio INCIBE.
4. La justificación de cada exclusión. El motivo por el que un control del Anexo A no aplica a tu empresa.

Un aviso que ahorra un disgusto en fase 1: no confundas la SoA con el plan de tratamiento de riesgos. Son dos documentos obligatorios distintos. La SoA es la foto completa de todos los controles (los aplicables con su estado, los excluidos con su motivo); el plan de tratamiento (6.1.3.e) es solo la agenda de acción sobre los que vas a implantar.

El Anexo A no es tu punto de partida, es tu red de seguridad: comparas los controles que has elegido con sus 93 para verificar que no se te ha olvidado ninguno necesario (6.1.3.c). Si te hace falta un control que no está en el anexo, también va a la SoA. Antes de tocar nada, revisa el detalle de los 93 controles que vas a declarar.

¿Quieres saber si esto aplica a tu empresa? Pide una evaluación de aplicabilidad gratuita.

La SoA es el contrato con tu auditor

Aquí está el matiz que casi ninguna plantilla te cuenta. La auditoría de certificación tiene dos fases: la fase 1 revisa que tu documentación existe y encaja; la fase 2 comprueba que lo documentado está implantado y funciona. Y el perímetro de esa fase 2 lo fijas tú, con lo que declaraste en la SoA. Cada fila «aplicable» es una promesa de evidencia.

De ahí sale la trampa. La intuición ingenua dice «cuantos más controles marque como aplicables, mejor imagen doy». Es justo al revés: como la 6.1.3.d obliga a declarar si cada control está implementado o no, marcar como “aplicable e implementado” algo que no opera es directamente refutable —el auditor solo tiene que pedir la evidencia—. Sobredeclarar por quedar bien es autoinfligirse no-conformidades.

Excluir bien, en cambio, es gratis y legítimo. Puedes excluir un control del Anexo A cuando se cumplen las tres condiciones a la vez:

• No existe la actividad ni el activo que ese control protege.
• Ningún riesgo de tu análisis lo requiere como tratamiento.
• Ningún requisito legal, contractual o de una parte interesada lo exige.

Si lo que pasa es que «todavía no lo hacemos», eso no es una exclusión: es un control aplicable con estado «no implementado» y una entrada en tu plan de tratamiento.

Así se ve una fila bien escrita. La norma solo exige los cuatro elementos de la 6.1.3.d; el formato de columnas es buena práctica, no un formato oficial —por eso las plantillas descargables «vacías» no valen nada hasta que las llenas con tu riesgo real—:

La versión mal hecha de esa segunda fila —«A.8.30 — No aplica — N/A»— es una no-conformidad directa: sin justificación, incumple la 6.1.3.d. Y marcar los 93 como «aplican» con un Excel descargado suma superficie auditable —más filas sobre las que el auditor puede exigirte evidencia— sin ningún beneficio.

Los errores de la SoA que un auditor caza en fase 1

Por experiencia de auditoría, estos son los fallos que saltan en la revisión documental, cada uno anclado a la cláusula que incumple:

• SoA desconectada del análisis de riesgos. Controles «aplicables» sin ningún riesgo ni requisito que los motive, o riesgos que se tratan con controles que luego no aparecen en la SoA. Rompe la cadena 6.1.3.b → d.
• Exclusiones sin justificar o justificadas «por coste» o «por ahora». La 6.1.3.d exige motivo; la inmadurez no es exclusión.
• Falta el estado de implementación de algún control. Es uno de los cuatro elementos obligatorios: sin él, la fila está incompleta.
• SoA contra la versión de 2013, con 114 controles. La CCN-STIC 825 pide expresamente actualizarla sustituyendo los 114 controles de la versión anterior por los 93 de la edición 2022. Los certificados emitidos contra 2013 perdieron la condición de acreditados el 31 de octubre de 2025 (IAF MD 26); hoy solo son válidos los certificados contra la edición 2022.
• Plantilla copiada sin adaptar al alcance. La SoA declara controles para el alcance concreto de tu SGSI (cláusula 4.3), no para una empresa genérica.
• Intentar «excluir» requisitos de las cláusulas 4 a 10. Solo el Anexo A admite exclusión; el resto de la norma es obligatorio en su totalidad.

La SoA no se escribe el primer día ni el último: se elabora justo después del análisis de riesgos. Para verla situada en el proyecto completo, con sus fases y sus tiempos, tienes en qué fase se elabora.

En España, la Declaración de Aplicabilidad también se firma

Un dato que le viene bien a cualquier pyme española: «Declaración de Aplicabilidad» no es solo jerga de ISO. En el Esquema Nacional de Seguridad es un documento legal con firma obligada. El art. 28.2 del Real Decreto 311/2022 exige que la relación de medidas seleccionadas se formalice en una Declaración de Aplicabilidad firmada por el responsable de la seguridad, y el 28.3 obliga a detallar en ella las medidas compensatorias.

Ese tramo adicional del art. 6.4 del Real Decreto 43/2021 solo aplica a los operadores declarados esenciales (OES): impone también una Declaración de Aplicabilidad que elabora y propone el responsable de la seguridad de la información, remitida a la autoridad competente y revisada al menos cada tres años.

ISO 27001, en cambio, no exige una firma concreta sobre la SoA: lo que pide es que los dueños de los riesgos aprueben el plan de tratamiento y acepten el riesgo residual (6.1.3.e-f). Ahí está la respuesta a «¿quién firma?»: en ISO firmas la aceptación del riesgo, no la SoA en sí.

Lo interesante es que la disciplina es la misma en los tres marcos. Si tu empresa convive con ENS e ISO, la guía CCN-STIC 825 apunta en esa dirección: una Declaración de Aplicabilidad compartida de ambas normas, aprobada por el responsable de la seguridad. Y la guía técnica de ENISA para NIS2 pide exactamente lo mismo: plan de tratamiento documentado y riesgo residual aceptado y justificado por la dirección. Quien aprende a escribir una SoA defendible reutiliza ese trabajo tres veces.

Por dónde empezar esta semana: no descargues una plantilla de SoA para ir marcando casillas. Haz antes el análisis de riesgos sobre un alcance bien delimitado y escribe cada fila pensando en que tendrás que enseñar la evidencia en fase 2. Una SoA corta y defendible te ahorra más no-conformidades que una larga y vistosa.

El contenido de esta página tiene carácter exclusivamente informativo y no constituye asesoramiento jurídico. La situación normativa descrita corresponde a la fecha de última actualización indicada; conviene verificar siempre el estado vigente de la legislación en las fuentes oficiales (BOE, EUR-Lex, CCN, INCIBE). Situación normativa a fecha de 12 de julio de 2026.