La Declaración de Aplicabilidad es el documento que más confunde a las organizaciones que se preparan para la certificación ISO 27001 — y el que más no conformidades genera en auditoría. No es una lista de verificación ni un catálogo de controles: es la justificación razonada de por qué su organización decidió aplicar o excluir cada uno de los 93 controles del Anexo A, respaldada por evidencia operativa de que los controles incluidos realmente funcionan.
Este artículo explica qué es el SoA, cómo se construye correctamente bajo ISO 27001:2022, qué columnas debe tener, cómo el auditor lo usa durante la certificación y los errores que convierten un SoA aparentemente completo en una fuente de hallazgos críticos.
¿Qué es la Declaración de Aplicabilidad (SoA) y por qué es el documento central del SGSI?
La Declaración de Aplicabilidad (Statement of Applicability, SoA) es el documento que conecta los resultados de la evaluación de riesgos con los controles de seguridad que la organización decide implementar. Está definida en la cláusula 6.1.3d de la norma ISO/IEC 27001:2022 como un requisito obligatorio para la certificación, sin el cual el proceso de auditoría no puede avanzar.
Su función no es descriptiva sino argumentativa: para cada uno de los 93 controles del Anexo A de la norma, el SoA debe responder tres preguntas:
¿Aplica o no aplica?
Cada control se marca como incluido o excluido del alcance del SGSI. No existe la opción de dejar controles sin decisión: la omisión es interpretada por el auditor como ausencia de análisis, lo que genera una no conformidad menor en el mejor de los casos.
¿Por qué se incluyó o excluyó?
La justificación debe derivarse directamente del análisis de riesgos. Un control se incluye porque existe un riesgo identificado que lo requiere, un requisito legal o contractual que lo exige, o una práctica organizacional que lo incorpora. Un control se excluye porque el riesgo asociado no aplica al contexto o fue aceptado formalmente por la dirección.
¿Está implementado y hay evidencia?
Para los controles incluidos, el SoA debe indicar el estado de implementación y referenciar la evidencia que lo respalda: políticas, procedimientos, registros, configuraciones de sistemas, logs. Sin esta referencia, el auditor no tiene dónde verificar y debe asumir que el control no opera.
Estructura correcta de un SoA bajo ISO 27001:2022
La norma no prescribe un formato específico, pero sí define qué información debe contener. En la práctica, el SoA se presenta como una tabla con al menos las siguientes columnas. Organizaciones que simplifican demasiado su estructura tienden a generar hallazgos en la columna de justificación o en la columna de evidencia.
| Columna | Contenido requerido | Error frecuente |
|---|---|---|
| ID del control | Número del control en Anexo A (ej. 5.1, 8.12, 8.23) | Usar numeración de la versión 2013 sin actualizar a 2022 |
| Nombre del control | Nombre exacto según la norma ISO/IEC 27001:2022 | Parafrasear o renombrar controles, lo que genera confusión en auditoría |
| Aplicable (Sí/No) | Decisión binaria para cada control | Dejar controles sin clasificar o marcar “parcial” sin justificación |
| Justificación de inclusión/exclusión | Razón documentada basada en: riesgo identificado / requisito legal / práctica existente / exclusión razonada | Justificaciones genéricas como “aplica por buenas prácticas” sin vincular al análisis de riesgos |
| Estado de implementación | Implementado / En proceso / Planificado (con fecha) | Marcar todos como “Implementado” sin evidencia real disponible |
| Referencia a documentación | Link o nombre del documento/procedimiento/política que respalda el control | Omitir esta columna — el auditor no puede verificar sin ella |
| Referencia a evidencia operativa | Registro, log, reporte o configuración que demuestra que el control opera | Confundir documentación con evidencia: un procedimiento escrito no prueba que el control funciona |
| Responsable | Rol o persona responsable de mantener el control activo | Asignar todos los controles al área de TI, ignorando controles organizacionales y de personas |
Los 93 controles del Anexo A en ISO 27001:2022: las 4 categorías
ISO 27001:2022 reorganizó los controles de seguridad en cuatro categorías, eliminando los 14 dominios de la versión 2013 y reduciendo el total de 114 a 93 controles. Esta reorganización no significa que haya menos exigencia — significa que los controles están mejor agrupados por naturaleza, lo que facilita la asignación de responsabilidades.
Categoría 1 — Controles Organizacionales (37 controles)
Gobierno, políticas, roles, gestión de riesgos, inteligencia de amenazas, gestión de activos, clasificación de información, proveedores, continuidad, cumplimiento legal y gestión de incidentes a nivel organizacional.
Nuevos en 2022: 5.7 Inteligencia de amenazas · 5.23 Seguridad en uso de servicios cloud · 5.30 Preparación de TIC para continuidad · 5.36 Cumplimiento con políticas y normas.
Categoría 2 — Controles de Personas (8 controles)
Selección de personal, términos y condiciones de empleo, concientización, capacitación, proceso disciplinario, responsabilidades post-empleo, trabajo remoto y reporte de eventos de seguridad.
Importante: Esta categoría suele subestimarse. Los auditores verifican evidencia real de capacitaciones, registros de aceptación de políticas y procedimientos de baja.
Categoría 3 — Controles Físicos (14 controles)
Perímetros de seguridad física, controles de acceso físico, oficinas y salas, monitoreo físico, protección contra amenazas físicas y ambientales, trabajo en áreas seguras, escritorio limpio, equipo fuera de instalaciones.
Nuevo en 2022: 7.4 Monitoreo de seguridad física.
Categoría 4 — Controles Tecnológicos (34 controles)
Control de acceso, gestión de identidades y autenticación, protección de datos, gestión de vulnerabilidades, seguridad en redes, filtrado web, DLP, criptografía, seguridad en desarrollo, gestión de incidentes técnicos, seguridad en la nube, monitoreo y logs.
Nuevos en 2022: 8.9 Gestión de configuración · 8.10 Eliminación de información · 8.11 Enmascaramiento de datos · 8.12 DLP · 8.16 Actividades de monitoreo · 8.23 Filtrado web · 8.28 Codificación segura.
Zero Trust e ISO 27001:2022
Los controles tecnológicos del Anexo A y cómo iboss los satisface
Una plataforma SASE Zero Trust como iboss cubre directamente controles de la Categoría 4: 8.2–8.4 (control de acceso), 8.12 (DLP), 8.15–8.16 (logs y monitoreo), 8.20–8.22 (seguridad de red) y 8.23 (filtrado web). Esto reduce el trabajo de implementación y genera evidencia operativa continua que el auditor puede verificar directamente.
Ver cómo Zero Trust cubre controles del Anexo ACómo construir el SoA paso a paso
El SoA no se construye de manera independiente. Es el resultado de un proceso previo y cualquier SoA elaborado sin ese proceso es inválido desde el punto de vista de la norma, independientemente de qué tan bien esté redactado.
Completar la evaluación de riesgos
El SoA referencia directamente los resultados del análisis de riesgos. Sin un inventario de activos, una metodología documentada de evaluación de riesgos y un plan de tratamiento aprobado por la dirección, no hay base para justificar ninguna decisión de inclusión o exclusión de controles.
Revisar requisitos legales, contractuales y del negocio
Algunos controles aplican no por riesgos identificados sino por obligaciones externas: regulaciones de CNBV, Banxico, LFPDPPP, contratos con clientes que exigen controles específicos, o estándares del sector. Estos requisitos deben estar documentados antes de construir el SoA porque determinan controles que no son opcionales aunque el análisis de riesgos no los priorice.
Decidir control por control (los 93)
Cada uno de los 93 controles del Anexo A debe analizarse. La decisión de inclusión o exclusión debe ser explícita y trazable al análisis de riesgos o a los requisitos documentados en el paso anterior. No es válido excluir controles simplemente porque son difíciles de implementar o porque no se cuenta con el presupuesto.
Documentar justificaciones en lenguaje auditable
Las justificaciones deben ser específicas. “No aplica porque la organización no tiene riesgo en esta área” no es aceptable sin evidencia del análisis de riesgos que respalda esa conclusión. Una justificación auditable dice: “Excluido: el riesgo R-14 fue evaluado con nivel bajo y la dirección lo aceptó formalmente en el Plan de Tratamiento de Riesgos v2.1, sección 4.”
Mapear evidencia operativa existente
Para cada control incluido, identificar la evidencia actual: ¿existe un procedimiento documentado? ¿hay registros operativos? ¿el sistema genera logs verificables? Los controles sin evidencia asociada deben marcarse como “En proceso” con fecha comprometida, no como “Implementado”.
Validar con la dirección y obtener aprobación formal
El SoA requiere aprobación de la alta dirección. Esta aprobación debe quedar registrada (acta, firma, correo formal con fecha) porque el auditor verificará que la dirección tuvo conocimiento y aprobó las decisiones de tratamiento de riesgos, incluyendo los controles excluidos y los riesgos aceptados.
Qué verifica el auditor en el SoA durante la certificación
En la Etapa 1 de la auditoría de certificación (revisión documental), el SoA es el documento más analizado. El auditor lo utiliza como mapa para planear toda la Etapa 2 (auditoría en sitio). Un SoA sólido permite que la Etapa 2 sea fluida; un SoA con inconsistencias o vacios convierte la Etapa 2 en una serie de hallazgos.
Consistencia interna
El auditor verifica que las decisiones del SoA son coherentes con el análisis de riesgos. Si un riesgo de alto nivel fue identificado pero el control correspondiente está excluido sin justificación de aceptación formal, es una no conformidad mayor.
Trazabilidad de exclusiones
Cada control excluido debe poder rastrearse hasta una decisión formal documentada. El auditor pregunta: ¿dónde está el registro de que la dirección aceptó este riesgo? Si no existe, el control no puede estar excluido.
Evidencia de operación
Para los controles marcados como “Implementado”, el auditor selecciona una muestra y solicita la evidencia referenciada en el SoA. Si la evidencia no existe, está desactualizada o no corresponde al control, genera hallazgo inmediato.
Cobertura de los 93 controles
El auditor verifica que ningún control está omitido. Un SoA que copia la estructura de la versión 2013 (con 114 controles) en lugar de la 2022 (93 controles) genera confusión y puede ser cuestionado si los 11 controles nuevos no están mapeados.
Actualización periódica
El SoA no es un documento de punto de partida: debe actualizarse cuando cambia el contexto de la organización, cuando se identifican nuevos riesgos o cuando se modifican controles. Un SoA sin fecha de revisión reciente levanta preguntas sobre si el SGSI es gestionado activamente.
Aprobación por la dirección
La aprobación formal de la dirección sobre el SoA es un requisito explícito. El auditor solicita evidencia de esa aprobación: acta de revisión por la dirección donde el SoA fue presentado y aprobado, con fecha y firma del responsable.
Los 5 errores más frecuentes en el SoA que generan no conformidades
Error 1 — Usar una plantilla genérica sin adaptar al análisis de riesgos propio
El error más frecuente. La organización descarga un SoA de plantilla, marca todos los controles como “Implementado” o “Excluido” con justificaciones genéricas, y lo presenta como documento propio. El auditor identifica esto en la Etapa 1 porque las justificaciones no referencian el análisis de riesgos específico de la organización ni los documentos existentes. Resultado típico: solicitud de revisión completa del SoA antes de continuar la auditoría, lo que retrasa el proceso varias semanas.
Error 2 — Excluir controles difíciles sin justificación formal de aceptación de riesgo
Controles como 8.16 (Actividades de monitoreo), 8.12 (Prevención de fuga de datos) o 5.23 (Seguridad en servicios cloud) suelen excluirse porque su implementación es compleja o costosa. Sin embargo, excluirlos sin un registro formal donde la dirección acepta los riesgos asociados es una no conformidad mayor. El auditor no cuestiona la exclusión en sí — cuestiona que no haya evidencia de que la dirección tomó esa decisión con conocimiento de los riesgos.
Error 3 — Confundir documentación con evidencia operativa
Tener una política de control de acceso documentada no demuestra que el control 8.3 (Restricción de acceso a información) opera correctamente. El auditor solicita registros de revisiones periódicas de permisos, logs de accesos, evidencia de desactivación de cuentas de empleados desvinculados. El SoA que referencia solo políticas sin registros operativos genera hallazgos en la Etapa 2 para todos los controles afectados.
Error 4 — No actualizar el SoA tras cambios organizacionales
Una fusión, la incorporación de trabajo remoto, la migración a servicios cloud o el lanzamiento de un nuevo producto modifican el contexto de riesgos. Si el SoA no se actualiza para reflejar estos cambios, controles que antes eran irrelevantes (como 5.23 Seguridad en cloud) pasan a ser obligatorios y su ausencia genera no conformidades en la auditoría de seguimiento. El SGSI es un sistema vivo — el SoA debe tratarse como tal.
Error 5 — Asignar todos los controles al equipo de TI
La Categoría 2 (Controles de Personas) y varios controles organizacionales (5.1 Políticas, 5.4 Responsabilidades, 5.10 Uso aceptable) son responsabilidad de Recursos Humanos, Legal o de la Dirección General, no de TI. Cuando el SoA asigna todos los controles a TI, el auditor lo interpreta como que la organización no tiene apropiación real del SGSI fuera del área técnica, lo que cuestiona la madurez del sistema de gestión.
Los 11 controles nuevos de ISO 27001:2022 que requieren atención especial en el SoA
Las organizaciones que se certificaron bajo ISO 27001:2013 y están en proceso de transición a 2022 deben añadir estos controles al SoA y documentar decisiones explícitas sobre cada uno. No pueden heredarse automáticamente de la versión anterior.
| Control | Nombre | Por qué es relevante en México |
|---|---|---|
| 5.7 | Inteligencia de amenazas | Feeds de threat intelligence para contexto de riesgos. Relevante para sector financiero y gobierno. |
| 5.23 | Seguridad en el uso de servicios cloud | Obligatorio para cualquier organización con workloads en Azure, AWS o SaaS. No puede excluirse si se usa cloud. |
| 5.29 | Seguridad de la información durante una disrupción | Conecta ISO 27001 con continuidad de negocio (ISO 22301). Exige plan documentado de seguridad durante incidentes. |
| 5.30 | Preparación de TIC para continuidad del negocio | Complemento técnico del anterior. Exige evidencia de pruebas de recuperación de sistemas críticos. |
| 7.4 | Monitoreo de seguridad física | CCTV, registros de acceso físico, alertas. Frecuentemente ignorado en organizaciones que se enfocan solo en controles técnicos. |
| 8.9 | Gestión de configuración | Baseline de configuración segura para sistemas. Conecta directamente con gestión de vulnerabilidades y hardening. |
| 8.10 | Eliminación de información | Procedimientos de borrado seguro de datos. Relevante para cumplimiento de LFPDPPP en México. |
| 8.11 | Enmascaramiento de datos | Tokenización o anonimización de datos sensibles en entornos de prueba, analytics o cuando los comparte con terceros. |
| 8.12 | Prevención de fuga de datos (DLP) | Control técnico de salida de información sensible. Exige herramienta o proceso documentado, no solo política. |
| 8.16 | Actividades de monitoreo | Monitoreo continuo de sistemas, redes y usuarios. Requiere logs, revisiones periódicas y evidencia de alertas gestionadas. |
| 8.28 | Codificación segura | Prácticas de desarrollo seguro. Aplica a organizaciones con desarrollo propio. Conecta con gestión de vulnerabilidades en código. |
Mantenimiento del SoA: la certificación no termina el día que se emite el certificado
El certificado ISO 27001 tiene vigencia de tres años con auditorías de seguimiento anuales. En cada auditoría de seguimiento, el auditor revisará si el SoA ha sido actualizado y si los controles siguen operando con evidencia vigente. Un SoA estático que no refleja los cambios organizacionales ocurridos desde la última auditoría es una señal de que el SGSI no se gestiona activamente — y eso es exactamente lo que la norma busca prevenir.
Cuándo actualizar el SoA obligatoriamente
- Cuando se identifican nuevos riesgos en la evaluación periódica
- Cuando cambia el alcance del SGSI (nuevas áreas, servicios o ubicaciones)
- Cuando se adoptan nuevos servicios cloud o proveedores críticos
- Cuando cambian requisitos legales o regulatorios aplicables
- Cuando un incidente de seguridad revela que un control no opera como se documentó
- Después de cada auditoría interna que genera cambios en controles
- Tras la revisión anual por la dirección (al menos una vez al año)
Control de versiones del SoA
El SoA debe tener control de versiones documentado: número de versión, fecha de aprobación, autor de la revisión y registro de cambios respecto a la versión anterior. El auditor en seguimiento comparará la versión actual con la del año anterior para verificar que los cambios organizacionales se reflejan en el documento.
Un SoA en versión 1.0 con fecha de dos años atrás en una organización que ha migrado a cloud, incorporado trabajo remoto y cambiado proveedores es una señal inequívoca de que el SGSI no se revisa — y eso genera no conformidades mayores en el seguimiento.
Gobierno, Riesgo y Cumplimiento
GRC como sistema continuo, no como proyecto puntual
El mantenimiento del SoA forma parte de un programa de Gobierno, Riesgo y Cumplimiento (GRC) que integra ISO 27001, cumplimiento regulatorio (CNBV, LFPDPPP) y operación de seguridad en un ciclo continuo. En QMA operamos ese ciclo con evidencia auditable en tiempo real.
Ver programa GRC de QMAPreguntas frecuentes sobre la Declaración de Aplicabilidad
¿El SoA debe cubrir los 93 controles o solo los que aplican?
Debe cubrir los 93 controles del Anexo A sin excepción. Para cada uno, la organización decide si incluye o excluye, y documenta la justificación. No es válido omitir controles del SoA aunque no apliquen: la omisión se interpreta como que no fueron analizados.
¿Puede el SoA referenciar controles de otros marcos como NIST o CIS?
Sí. La norma permite que los controles del Anexo A sean complementados o sustituidos por controles de otros marcos, siempre que la justificación explique cómo esos controles alternativos cubren el mismo objetivo de seguridad. Sin embargo, los 93 controles del Anexo A deben aparecer en el SoA de todas formas con decisión de inclusión o exclusión.
¿Cuántos controles suelen excluirse en una organización típica?
Depende del contexto. Organizaciones sin desarrollo de software propio suelen excluir 8.28 (Codificación segura). Organizaciones sin instalaciones físicas propias pueden excluir algunos controles físicos. En promedio, una organización de tamaño mediano excluye entre 5 y 15 controles con justificación sólida. Excluir más de 20 genera preguntas sobre si el alcance del SGSI es suficientemente amplio o si la evaluación de riesgos fue rigurosa.
¿Es lo mismo el SoA que el Plan de Tratamiento de Riesgos?
No, aunque están estrechamente relacionados. El Plan de Tratamiento de Riesgos (PTR) documenta qué se va a hacer con cada riesgo identificado: mitigar, aceptar, transferir o evitar. El SoA documenta qué controles se implementan para ejecutar esas decisiones de tratamiento. El SoA referencia el PTR, pero son documentos distintos con propósitos complementarios.
¿Qué herramientas se usan para gestionar el SoA?
Las organizaciones usan desde hojas de cálculo hasta plataformas de GRC especializadas. Lo que determina la calidad del SoA no es la herramienta sino el proceso: que las decisiones sean trazables, las justificaciones específicas y la evidencia referenciada esté accesible para el auditor. Un SoA en Excel bien estructurado supera a uno en plataforma GRC con justificaciones genéricas.
¿Con qué frecuencia debe revisarse el SoA?
Como mínimo, una vez al año en el marco de la revisión por la dirección. En la práctica, cada vez que ocurra un cambio significativo en el contexto de la organización que pueda afectar el perfil de riesgos: nuevos servicios, cambios en proveedores, incidentes de seguridad, nuevas regulaciones o modificaciones en el alcance del SGSI.
El SoA correcto desde el principio reduce el costo de la certificación
Un SoA mal construido no solo genera hallazgos en auditoría — obliga a repetir el análisis de riesgos, reescribir justificaciones y generar evidencia que debió haberse producido desde el inicio. En QMA construimos el SoA como parte del proceso de implementación del SGSI, asegurando que cada decisión sea trazable, cada exclusión tenga respaldo formal y cada control incluido tenga evidencia operativa verificable antes de que llegue el auditor.
