Declaración de Aplicabilidad (SoA) ISO 27001 paso a paso
El SoA es el primer documento que pide el auditor de certificación. Te explicamos cómo construirlo, las exclusiones que se permiten, las que NO se permiten y cómo mantenerlo vivo.
Qué es el SoA y por qué es el documento más auditado
La Declaración de Aplicabilidad (Statement of Applicability — SoA) es el documento exigido por la cláusula 6.1.3 d) de ISO/IEC 27001:2022. Es donde la organización declara, para cada uno de los 93 controles del Anexo A, si aplica o no aplica al alcance del SGSI, con justificación documentada en ambos casos.
El auditor de certificación lo lee primero porque le da el mapa completo de la implementación del SGSI: qué controles dice la organización que aplica + qué evidencia hay de su implementación + qué controles excluyó y por qué. Un SoA mal construido (sin justificaciones, con exclusiones masivas, sin trazabilidad al análisis de riesgos) genera no conformidad mayor en auditoría.
El SoA NO es un trámite formal — es un documento operativo. Las empresas maduras lo mantienen vivo, actualizándolo cada vez que cambia un riesgo, se incorpora un activo nuevo o cambia una decisión de tratamiento. Un SoA estático "del año pasado" es señal de SGSI dormido.
Qué debe contener un SoA según ISO 27001
La norma exige los siguientes elementos mínimos en el SoA. Cualquier SoA que omita alguno tiene riesgo de hallazgo en auditoría:
Lista de los 93 controles del Anexo A 2022 (texto literal del control).
Para cada control: declaración explícita "Aplica" o "No aplica".
Para los que aplican: justificación de aplicación + estado de implementación + evidencia.
Para los que NO aplican: justificación documentada de la exclusión (es lo que más mira el auditor).
Trazabilidad al análisis de riesgos: qué riesgo del análisis trata cada control aplicado.
Fecha de aprobación y aprobador (típicamente CISO / Comité de Seguridad / Alta Dirección).
Versión del SoA y fecha de última revisión.
Referencia al alcance del SGSI (qué procesos / sedes / sistemas cubre).
Exclusiones que SÍ se permiten
Excluir controles del Anexo A es válido siempre que la exclusión esté justificada y no comprometa la capacidad del SGSI de tratar los riesgos identificados. Estas son las exclusiones más comunes y aceptadas:
"No aplica porque la organización no opera con desarrollo de software propio" — excluye A.8.25 a A.8.31 (controles de desarrollo seguro). Válido para empresas no-tech.
"No aplica porque no se trata información clasificada gubernamental" — excluye controles de manejo de información clasificada en entornos militares/gov.
"No aplica porque no hay áreas físicas seguras distintas a oficina general" — excluye A.7.5 (delivery/loading areas) si no hay zonas de carga/recepción.
"No aplica porque la organización no presta servicios cloud" — excluye controles específicos de cloud provider (no del cliente cloud).
Exclusiones que NO se permiten (hallazgos automáticos)
Estos son intentos de exclusión que generan hallazgo automático en auditoría. El auditor los rechaza independientemente de la justificación:
Excluir controles porque "son costosos" o "complicados". El criterio de exclusión es operativo (no aplica al contexto), no económico.
Excluir A.5.1 (políticas de seguridad). Toda organización con SGSI debe tener política — sin política no hay SGSI.
Excluir A.5.24-A.5.27 (gestión de incidentes). Toda organización debe poder responder a incidentes; excluir esto es decir "no nos importan los incidentes".
Excluir A.6.3 (concienciación y capacitación). Toda organización con personas debe capacitarlas en SST de información.
Excluir A.5.36 (cumplimiento). Sin cumplimiento de las propias políticas, el SGSI es papel mojado.
Excluir A.8.2 (gestión de privilegios) o A.8.5 (autenticación segura) sin estar literalmente offline. Cualquier sistema digital requiere estos controles.
Cuándo actualizar el SoA
El SoA es un documento vivo. Estas son las situaciones que disparan actualización (cualquiera de ellas):
Anualmente, como mínimo, en la revisión por la dirección del SGSI.
Cada vez que cambia el alcance del SGSI (se agrega un proceso, sede o sistema).
Cuando el análisis de riesgos identifica un riesgo nuevo significativo que requiere control adicional.
Cuando se incorpora un activo de información nuevo crítico (sistema, base de datos, proveedor cloud).
Tras un incidente de seguridad relevante que demuestra brecha en controles vigentes.
Cuando sale nueva versión de la norma (ej. del Anexo A 2013 al 2022).
Cuando un control "no aplica" pasa a aplicar (ej. la empresa empieza a desarrollar software propio → ahora aplican A.8.25 a A.8.31).
Por qué construir el SoA en software dedicado (no Excel)
En Excel el SoA se vuelve inmanejable cuando hay más de 50 controles activos con responsables, evidencias y plazos cambiantes. Estas son las ventajas de un software SGSI dedicado para el SoA:
Plantilla pre-cargada con los 93 controles del Anexo A 2022 — no hay riesgo de olvidar uno.
Generación automática del documento SoA en el formato que exige la ISO 27001 para la certificación (PDF o Word) con un click.
Trazabilidad bidireccional: cada control vinculado a los riesgos que trata + evidencias subidas + responsable + plazo.
Filtros: "todos los controles aplicables sin evidencia vigente" o "controles que vencen evidencia este mes".
Flujo de aprobación: redactor → revisor técnico → CISO → aprobador final. Cada paso firma digital.
Historial de versiones: qué cambió entre la versión SoA del año pasado y la actual.
Cross-walk 2013 ↔ 2022: si migras de versión anterior, el sistema sugiere mapeos automáticos.
Automatiza lo que acabas de leer
HoldingSoft+ centraliza la matriz IPER, COPASST, indicadores y reportes Resolución 0312. Reduce 60-80% el tiempo de gestión SGI.
Cumple Decreto 1072 + Resolución 0312
Estándares mínimos SG-SST + ISO 9001/14001/45001IA SOFÍA con citas verificables
RAG sobre tus documentos, sin alucinacionesDesde USD 30/mes · +40 apps incluidas
Sin penalización por cambiar de planPreguntas frecuentes
Para los 93 controles del Anexo A 2022, el SoA típico tiene 40-80 páginas según el detalle de justificación. Empresas chicas con SoA minimalista: 25-30 páginas. Empresas grandes con justificaciones detalladas + trazabilidad completa: 80-120 páginas. El tamaño en sí no importa al auditor, importa la coherencia y completitud.
La política interna define el aprobador, pero la práctica aceptada es: redacción a cargo del responsable del SGSI (CISO o Oficial de Seguridad), revisión técnica por TI / Cumplimiento / Legal, aprobación final por el Comité de Seguridad o la Alta Dirección. El auditor verifica que la aprobación tenga el nivel jerárquico apropiado para el peso del documento.
No, es un documento interno y confidencial. Es información sensible porque revela qué controles tiene la organización y cuáles excluye — un atacante podría usarlo. Los auditores firman NDA antes de revisarlo. Si un cliente exige conocer el SoA como parte de due diligence, se entrega bajo NDA específico.
No, cada SGSI tiene su propio alcance y su propio SoA. Si la corporativa tiene SGSI global con alcance "toda la operación", el SoA es uno solo cubriendo todas las filiales. Si cada filial tiene SGSI con alcance local, cada una tiene su SoA. Para empresas multinacionales lo más común es un SGSI corporativo + adaptaciones locales por filial.
Entre 2 y 4 veces al año, dependiendo de la dinámica de cambios. Empresas estáticas (pocos cambios de procesos, sin nuevos sistemas): 1-2 actualizaciones formales. Empresas dinámicas (tecnología cambiando rápido, expansión): 4-6 actualizaciones. La revisión anual mínima es obligatoria; las intermedias son por cambio significativo.
Sí, pero no necesariamente en la auditoría de certificación inicial (que es muestral). En las auditorías de seguimiento (anuales) y la recertificación (cada 3 años), el auditor cubre progresivamente todos los controles aplicables a lo largo del ciclo. En el ciclo de 3 años entre certificación y recertificación, eventualmente revisará todos los controles del SoA.
¿Quieres aplicar esto en tu empresa?
HoldingSoft+ automatiza la gestión documental, los indicadores y los reportes que aquí se mencionan. Ahorras semanas de trabajo administrativo y reduces el riesgo de hallazgos en auditoría.