Declaración de Aplicabilidad (SoA) de ISO 27001: Cómo Crearla
Aprenda a crear una Declaración de Aplicabilidad de ISO 27001. Guía paso a paso sobre los requisitos del SoA en ISO 27001, justificaciones y preparación para auditoría.
GRCTrail Team
La Declaración de Aplicabilidad es el documento más importante de su ISMS de ISO 27001. Esto no es una exageración. Es el documento que conecta su evaluación de riesgos con sus controles, justifica por qué implementó lo que implementó (y excluyó lo que excluyó), y sirve como punto de referencia principal para los auditores de certificación. Un SoA inadecuado es el camino más rápido a las no conformidades de auditoría, y un SoA bien elaborado demuestra que su ISMS es un sistema coherente e impulsado por riesgos, en lugar de una colección de controles elegidos al azar.
La Cláusula 6.1.3 d) de ISO 27001 requiere que las organizaciones produzcan una Declaración de Aplicabilidad que contenga los controles necesarios, la justificación de su inclusión, si están implementados o no, y la justificación para excluir cualquier control del Annex A. Cada uno de los 93 controles del Annex A debe ser abordado — no puede simplemente omitir controles sin explicación.
Esta guía recorre qué es el SoA, qué debe contener, cómo crear uno paso a paso desde su plan de tratamiento de riesgos, y los errores comunes que conducen a hallazgos de auditoría.
¿Qué es la Declaración de Aplicabilidad?
La Declaración de Aplicabilidad es un registro documentado de todos los controles considerados para el ISMS, junto con la justificación de su inclusión o exclusión. Conecta dos procesos críticos:
- Resultados de la evaluación de riesgos — los riesgos que ha identificado, analizado y evaluado
- Implementación de controles — las medidas específicas que ha desplegado para tratar esos riesgos
Sin el SoA, no existe una conexión formal entre “identificamos estos riesgos” e “implementamos estos controles”. La evaluación de riesgos le dice qué podría salir mal. El SoA le dice qué hizo al respecto — y, igualmente importante, qué decidió no hacer y por qué.
Dónde se Ubica el SoA en el ISMS
El SoA se produce después de la evaluación de riesgos y el plan de tratamiento de riesgos, y antes (o de forma concurrente) con la implementación de controles. La secuencia es:
- Evaluación de riesgos (Cláusula 6.1.2) — identificar y evaluar riesgos
- Plan de tratamiento de riesgos (Cláusula 6.1.3) — decidir cómo tratar cada riesgo
- Declaración de Aplicabilidad (Cláusula 6.1.3 d) — documentar qué controles abordan qué riesgos
- Implementación de controles — desplegar los controles documentados en el SoA
- Auditoría interna (Cláusula 9.2) — verificar que los controles están implementados y son eficaces
- Auditoría de certificación — el auditor externo revisa el SoA y verifica la implementación
En la práctica, los pasos 3 y 4 son a menudo iterativos — puede refinar el SoA a medida que implementa controles y descubre que algunos controles necesitan ajustarse o que se necesitan controles adicionales.
Lo que la Cláusula 6.1.3 Realmente Requiere
La Cláusula 6.1.3 d) establece que la organización debe producir una Declaración de Aplicabilidad que contenga:
- Los controles necesarios — considerando los resultados de la evaluación de riesgos y el proceso de tratamiento de riesgos, e independientemente de si provienen del Annex A u otra fuente
- Justificación de su inclusión — por qué cada control está dentro del alcance
- Si los controles necesarios están implementados o no — estado actual de implementación
- Justificación para excluir cualquier control del Annex A — por qué los controles excluidos no aplican
La frase “independientemente de si provienen del Annex A u otra fuente” es importante. Su SoA debe incluir los 93 controles del Annex A como línea base, pero también puede incluir controles de otras fuentes (NIST, CIS, marcos específicos de la industria o controles personalizados que su organización ha desarrollado). El Annex A es el conjunto mínimo a considerar, no el máximo.
Componentes Requeridos del SoA
Un SoA completo incluye la siguiente información para cada control:
Referencia y Título del Control
El número del control del Annex A y su nombre. Para la versión 2022, es desde A.5.1 hasta A.8.34. Si tiene controles adicionales de otras fuentes, inclúyalos con un esquema de referencia consistente (por ejemplo, CUSTOM-001, NIST-AC-2).
Decisión de Inclusión o Exclusión
Una declaración clara de si el control está incluido (aplicable) o excluido (no aplicable) para su ISMS. Esta es una decisión binaria — no existe “parcialmente aplicable”. Si algún aspecto de un control aplica, está incluido.
Justificación de la Inclusión
Para cada control incluido, indique por qué es necesario. La justificación debe rastrearse a uno o más de los siguientes:
- Tratamiento de riesgos — el control mitiga un riesgo específico identificado en la evaluación de riesgos (referencie el ID del riesgo)
- Requisito legal o regulatorio — el control es requerido por la ley o regulación aplicable (por ejemplo, GDPR, regulación de la industria)
- Obligación contractual — el control es requerido por contratos con clientes o acuerdos comerciales
- Mejor práctica — el control se implementa como mejor práctica aunque ningún riesgo específico, requisito legal o contractual lo exija (esto es aceptable pero debería ser la excepción, no la regla)
Ejemplo de justificación para inclusión: “Incluido. A.8.5 (Autenticación segura) aborda RISK-2026-003 (Acceso no autorizado a datos de clientes a través de compromiso de credenciales) y RISK-2026-015 (Toma de control de cuentas mediante phishing). MFA es también un requisito contractual en nuestros acuerdos con clientes empresariales.”
Justificación de la Exclusión
Para cada control excluido, indique por qué no es aplicable a su ISMS. La justificación debe demostrar que excluir el control no compromete la seguridad de la información. Declaraciones genéricas como “no aplicable” son insuficientes.
Ejemplo de justificación para exclusión: “Excluido. A.7.12 (Seguridad del cableado) no es aplicable porque la organización no tiene centro de datos ni sala de servidores en sus instalaciones. Toda la infraestructura de producción está alojada en AWS, donde la seguridad del cableado físico es gestionada por AWS bajo su modelo de responsabilidad compartida. La red de oficina utiliza equipos comerciales estándar sin datos sensibles procesados localmente. Excluir este control no crea un riesgo de seguridad sin abordar.”
Estado de Implementación
Para cada control incluido, indique si está:
- Implementado — el control está completamente desplegado y operando
- Parcialmente implementado — algunos aspectos están en su lugar pero otros están pendientes (describa qué está hecho y qué falta)
- Planificado — el control aún no está implementado pero está programado para implementación (incluya fecha objetivo)
- No iniciado — el control está incluido pero la implementación no ha comenzado (incluya fecha objetivo)
El estado de implementación es particularmente importante durante la certificación inicial. Es aceptable tener controles que estén “planificados” o “parcialmente implementados” en el momento de producir el SoA — pero deben estar completamente implementados antes de la auditoría de certificación de Etapa 2. Los auditores verificarán la implementación contra lo que el SoA afirma.
Propietario del Control
Designe a un individuo responsable de la implementación y operación continua de cada control. Esto no siempre es requerido por los auditores, pero es altamente recomendado porque establece responsabilidad y asegura que los controles no queden huérfanos.
Paso a Paso: Creación del SoA desde su Plan de Tratamiento de Riesgos
Paso 1: Comience con la Lista Completa de Controles del Annex A
Cree un documento (hoja de cálculo, base de datos o herramienta de gestión de cumplimiento) que liste los 93 controles del Annex A. Cada fila representa un control con columnas para: referencia del control, título del control, inclusión/exclusión, justificación, estado de implementación, referencia(s) del riesgo y propietario.
No omita controles. Cada uno de los 93 debe tener una fila y una decisión. Los auditores verificarán la completitud.
Paso 2: Mapee su Plan de Tratamiento de Riesgos a los Controles del Annex A
Tome su plan de tratamiento de riesgos — que lista cada riesgo y las acciones de tratamiento que ha decidido — y mapee cada acción de tratamiento a uno o más controles del Annex A.
Ejemplo de mapeo:
| Riesgo | Acción de Tratamiento | Control del Annex A |
|---|---|---|
| RISK-001: Acceso no autorizado a la base de datos de producción | Implementar MFA para todo acceso a producción | A.8.5 (Autenticación segura) |
| RISK-001: Acceso no autorizado a la base de datos de producción | Aplicar control de acceso basado en roles con privilegios mínimos | A.5.15 (Control de acceso), A.8.3 (Restricción de acceso a la información) |
| RISK-001: Acceso no autorizado a la base de datos de producción | Realizar revisiones de acceso trimestrales | A.5.18 (Derechos de acceso) |
| RISK-002: Violación de datos por vulnerabilidad de software | Implementar escaneo de vulnerabilidades en CI/CD | A.8.8 (Gestión de vulnerabilidades técnicas), A.8.29 (Pruebas de seguridad) |
| RISK-002: Violación de datos por vulnerabilidad de software | Aplicar revisión de código para todos los cambios | A.8.25 (Ciclo de vida de desarrollo seguro) |
| RISK-003: Brecha de proveedor que expone datos de clientes | Realizar evaluaciones de seguridad de proveedores | A.5.19 (Relaciones con proveedores) |
| RISK-003: Brecha de proveedor que expone datos de clientes | Incluir requisitos de seguridad en contratos con proveedores | A.5.20 (Acuerdos con proveedores) |
Este mapeo identifica qué controles del Annex A son “necesarios” — están incluidos porque abordan directamente riesgos identificados.
Paso 3: Identifique Controles Requeridos por Ley, Regulación o Contrato
Algunos controles del Annex A son necesarios no por un riesgo específico en su registro sino por obligaciones legales, regulatorias o contractuales.
Ejemplos:
- A.5.34 (Privacidad y protección de datos personales) — requerido si procesa datos personales sujetos al GDPR u otras regulaciones de privacidad
- A.5.31 (Requisitos legales, estatutarios y regulatorios) — requerido para todas las organizaciones para identificar los requisitos legales aplicables
- A.5.28 (Recopilación de evidencia) — puede ser requerido por regulaciones de la industria que exijan preparación forense
- A.8.24 (Uso de criptografía) — los requisitos de cifrado pueden ser obligaciones contractuales en acuerdos con clientes empresariales
Marque estos controles como incluidos con la justificación apropiada (requisito legal, obligación contractual).
Paso 4: Revise los Controles Restantes para Aplicabilidad
Después de mapear las acciones de tratamiento de riesgos y los requisitos legales/contractuales, algunos controles del Annex A pueden no estar abordados aún. Para cada control restante, determine si es aplicable a su organización:
- ¿El control aborda un riesgo que existe en su entorno? Si es así, puede tener una brecha en su evaluación de riesgos — considere si el riesgo debería agregarse a su registro, o si los controles existentes ya lo abordan bajo una referencia diferente del Annex A.
- ¿El control es relevante para sus operaciones, tecnología o modelo de negocio? Las empresas SaaS nativas de la nube pueden encontrar algunos controles físicos genuinamente no aplicables. Pero sea cauteloso con las exclusiones — los auditores las escrutinan.
- ¿Excluir el control crearía una brecha de seguridad? Si excluir un control significa que ninguna medida aborda una amenaza relevante, la exclusión es inapropiada.
Paso 5: Documente las Justificaciones
Para cada control — incluido y excluido — escriba una justificación clara y específica. Este es el paso más laborioso pero también el más importante para la preparación de la auditoría.
Espectro de calidad de justificación:
Pobre (generará preguntas de auditoría):
- “Incluido — requerido para seguridad”
- “Excluido — no aplicable”
- “Incluido — mejor práctica”
Aceptable (cumple requisitos mínimos):
- “Incluido — aborda el riesgo de acceso no autorizado a sistemas de producción (RISK-2026-003)”
- “Excluido — la organización no tiene centro de datos físico; toda la infraestructura está alojada en la nube”
Sólido (demuestra un ISMS maduro e impulsado por riesgos):
- “Incluido — aborda RISK-2026-003 (acceso no autorizado a sistemas de producción mediante compromiso de credenciales, calificado como Alto). Implementado a través de la aplicación de MFA mediante Okta para todo acceso a producción, integración SSO con AWS IAM Identity Center y políticas de gestión de sesiones que requieren reautenticación después de 12 horas de inactividad. Última verificación durante la revisión de acceso del T3 2026.”
- “Excluido — la organización no opera ningún centro de datos ni sala de servidores física. Toda la infraestructura de producción está alojada en las regiones eu-west-1 y eu-central-1 de AWS, donde la seguridad del cableado físico es gestionada por AWS bajo la certificación SOC 2 Tipo II (informe revisado anualmente bajo A.5.22). La red de oficina consiste en equipos comerciales estándar que no procesan datos sensibles. Riesgo residual de esta exclusión: despreciable.”
Paso 6: Registre el Estado de Implementación
Para cada control incluido, evalúe y documente el estado actual de implementación. Sea honesto — tergiversar el estado de implementación y ser descubierto durante la auditoría es mucho peor que reconocer que un control aún está siendo implementado.
Ejemplos de estado de implementación:
-
A.8.5 (Autenticación segura) — Implementado. MFA aplicado a través de Okta para todos los sistemas internos. SSO configurado para AWS, GitHub, Datadog y Jira. Llaves de seguridad hardware emitidas a todos los ingenieros con acceso a producción. Última revisión de configuración: enero de 2026.
-
A.8.12 (Prevención de fuga de datos) — Parcialmente implementado. DLP de endpoint desplegado en todos los portátiles gestionados por la empresa (CrowdStrike Falcon). Reglas de DLP para correo electrónico activas en Google Workspace. Monitoreo de DLP a nivel de API planificado para el T2 2026 (fecha objetivo de finalización: mayo de 2026).
-
A.8.11 (Enmascaramiento de datos) — Planificado. Evaluación de herramienta de enmascaramiento de datos completada. Solución seleccionada: Tonic.ai. Implementación programada para el T2 2026, comenzando con el pipeline de actualización de datos del entorno de staging. Fecha objetivo de finalización: junio de 2026.
Paso 7: Asigne Propietarios
Asigne a un individuo con nombre (no un equipo o rol) como propietario de cada control. El propietario es responsable de:
- Asegurar que el control está implementado según lo documentado
- Mantener evidencia de la operación del control
- Informar sobre la eficacia del control durante las revisiones por la dirección
- Actualizar el control cuando cambien los riesgos, requisitos o el entorno
Para empresas SaaS, la propiedad de los controles a menudo sigue este patrón:
| Tema del Control | Propietario Típico |
|---|---|
| A.5 Organizacional (gobernanza, políticas) | CISO / Jefe de Seguridad |
| A.5 Organizacional (gestión de proveedores) | Líder de Gestión de Proveedores / Compras |
| A.6 Personas | Líder de RRHH / Operaciones de Personal |
| A.7 Físico | Gerente de Oficina / Instalaciones |
| A.8 Tecnológico (infraestructura) | Líder de Ingeniería de Plataforma / Infraestructura |
| A.8 Tecnológico (aplicación) | Líder de Ingeniería / CTO |
| A.8 Tecnológico (endpoints) | Líder de Operaciones de TI |
Paso 8: Revisión y Aprobación
El SoA completado debe ser revisado y aprobado por la dirección — típicamente el propietario del ISMS (CISO), el representante de la dirección o el comité de riesgos. La aprobación demuestra que la dirección ha revisado y aceptado la selección de controles, las decisiones de exclusión y el estado actual de implementación.
Documente la aprobación con:
- Nombre y rol del aprobador
- Fecha de aprobación
- Número de versión — el SoA es un documento versionado que cambia con el tiempo
- Fecha de próxima revisión — cuándo se revisará formalmente el SoA (como mínimo, anualmente)
El SoA como Documento Vivo
La Declaración de Aplicabilidad no es un entregable único que se crea para la certificación y se archiva. Es un documento vivo que debe actualizarse cada vez que su ISMS cambie.
Desencadenantes para Actualizaciones del SoA
Cambios en la evaluación de riesgos. Cuando se identifican nuevos riesgos, se reevalúan los riesgos existentes o cambian los planes de tratamiento de riesgos, el SoA debe actualizarse para reflejar cualquier cambio en la selección de controles o justificación. Si su evaluación de riesgos anual identifica nuevas amenazas que requieren controles adicionales, esos controles se agregan al SoA.
Progreso en la implementación de controles. A medida que los controles pasan de “planificado” a “parcialmente implementado” a “implementado”, actualice el SoA para reflejar el estado actual. Esto es particularmente importante en el período entre la creación inicial del SoA y la auditoría de certificación de Etapa 2.
Cambios organizacionales. Nuevos productos, servicios, mercados o modelos de negocio pueden introducir nuevos riesgos o hacer relevantes controles previamente excluidos. Si su empresa SaaS lanza un producto que procesa datos de salud, los controles relacionados con el cumplimiento regulatorio (A.5.31, A.5.34) pueden necesitar justificaciones actualizadas.
Cambios regulatorios. Nuevas leyes o regulaciones actualizadas pueden requerir controles adicionales o cambiar la justificación de los existentes.
Hallazgos de auditoría. Si su auditoría interna o una auditoría de vigilancia identifica brechas, el SoA puede necesitar actualizaciones para agregar controles, fortalecer justificaciones o corregir afirmaciones sobre el estado de implementación.
Cambios tecnológicos. Migrar de proveedores de nube, adoptar nuevas herramientas de desarrollo o cambiar su arquitectura puede afectar qué controles son aplicables y cómo se implementan.
Control de Versiones
Mantenga un historial de versiones para el SoA:
| Versión | Fecha | Autor | Cambios | Aprobado Por |
|---|---|---|---|---|
| 1.0 | 2026-01-15 | Jane Smith, CISO | SoA inicial para certificación | John Doe, CTO |
| 1.1 | 2026-04-20 | Jane Smith, CISO | Actualizado estado de A.8.12 a Implementado; agregado mapeo de RISK-2026-042 a A.5.23 | John Doe, CTO |
| 1.2 | 2026-07-10 | Jane Smith, CISO | Revisión anual; actualizadas justificaciones para A.7.1-A.7.6 tras reubicación de oficina | John Doe, CTO |
Cadencia de Revisión
- Mínima: Revisión anual alineada con el ciclo de revisión por la dirección
- Recomendada: Revisión trimestral alineada con las revisiones del registro de riesgos
- Desencadenada: Actualización dentro de los 30 días posteriores a cambios significativos (nuevos riesgos, hallazgos de auditoría, cambios organizacionales)
SoA vs. Plan de Tratamiento de Riesgos: Entendiendo la Diferencia
El SoA y el plan de tratamiento de riesgos están estrechamente relacionados pero sirven propósitos diferentes. Confundirlos — o tratarlos como intercambiables — es un error común.
Plan de Tratamiento de Riesgos
Propósito: Documenta cómo se tratará cada riesgo identificado (mitigar, transferir, evitar, aceptar) y las acciones específicas planificadas.
Contenido:
- Cada riesgo que requiere tratamiento
- Opción de tratamiento seleccionada
- Acciones de tratamiento específicas
- Propietario y fechas objetivo
- Riesgo residual esperado después del tratamiento
Enfoque: Centrado en riesgos. Organizado alrededor de riesgos, no de controles.
Audiencia: Propietarios de riesgos, dirección, auditores (para verificar decisiones de tratamiento).
Declaración de Aplicabilidad
Propósito: Documenta qué controles están dentro del alcance del ISMS, con justificación para la inclusión y exclusión.
Contenido:
- Cada control del Annex A (los 93)
- Decisión de inclusión/exclusión con justificación
- Estado de implementación
- Referencias de riesgos (rastreando controles a riesgos)
- Propietarios de controles
Enfoque: Centrado en controles. Organizado alrededor de la estructura de controles del Annex A.
Audiencia: Auditores (referencia principal durante la certificación), dirección, equipos de implementación.
Cómo se Conectan
El plan de tratamiento de riesgos es un insumo para el SoA. Cuando su plan de tratamiento de riesgos dice “mitigar RISK-001 implementando MFA”, el SoA registra que A.8.5 (Autenticación segura) está incluido porque aborda RISK-001, y nota su estado de implementación.
La relación es de muchos a muchos:
- Un riesgo puede requerir múltiples controles (RISK-001 se mapea a A.5.15, A.5.18, A.8.3, A.8.5)
- Un control puede abordar múltiples riesgos (A.8.15 Registro aborda riesgos relacionados con acceso no autorizado, detección de incidentes, preparación forense y cumplimiento)
Ambos documentos deben ser consistentes. Si el plan de tratamiento de riesgos dice que un riesgo se está mitigando a través de controles específicos, el SoA debe mostrar esos controles como incluidos. Si el SoA excluye un control, ningún riesgo en el plan de tratamiento debe depender de ese control para la mitigación.
No Conformidades Comunes del SoA en Auditoría
Comprender lo que buscan los auditores le ayuda a evitar los hallazgos más comunes.
No Conformidad 1: Justificaciones Faltantes o Incompletas
El hallazgo: Los controles están marcados como incluidos o excluidos sin justificación adecuada. El SoA dice “Incluido” o “Excluido” pero no explica por qué.
Por qué importa: Sin justificación, el auditor no puede verificar que su selección de controles está impulsada por riesgos. Parece que los controles se seleccionaron arbitrariamente o se copiaron de una plantilla.
Cómo evitarlo: Escriba justificaciones específicas que referencien IDs de riesgos, requisitos legales u obligaciones contractuales. Para las exclusiones, explique por qué el riesgo que el control aborda no es aplicable a su organización.
No Conformidad 2: Controles Excluidos sin Justificación Válida
El hallazgo: Los controles están excluidos con justificaciones que no resisten el escrutinio. Por ejemplo, excluir A.8.8 (Gestión de vulnerabilidades técnicas) con la justificación “gestionado por el proveedor de nube” cuando la organización ejecuta código de aplicación personalizado que claramente está dentro del alcance para la gestión de vulnerabilidades.
Por qué importa: Las exclusiones inválidas sugieren una falta de comprensión de los controles o un intento de reducir la carga de implementación excluyendo controles aplicables.
Cómo evitarlo: Antes de excluir cualquier control, pregunte: “¿Hay algún escenario dentro del alcance de nuestro ISMS donde el riesgo que este control aborda podría materializarse?” Si es así, el control probablemente debería incluirse. El modelo de responsabilidad compartida con proveedores de nube es una fuente común de confusión — su proveedor de nube gestiona la seguridad física, pero usted gestiona la seguridad de la aplicación, el control de acceso, la configuración y la mayoría de los otros controles.
No Conformidad 3: Estado de Implementación Tergiversado
El hallazgo: El SoA afirma que un control está “Implementado” pero el auditor no encuentra evidencia de implementación, o la implementación no cumple con la intención del control.
Por qué importa: Tergiversar el estado de implementación socava la credibilidad de todo el SoA y puede resultar en una no conformidad mayor.
Cómo evitarlo: Sea honesto sobre el estado de implementación. “Parcialmente implementado” o “Planificado con fecha objetivo” es mucho mejor que afirmar una implementación completa que no se puede demostrar. Los auditores respetan la transparencia y trabajan con las organizaciones para abordar brechas — no respetan la tergiversación.
No Conformidad 4: SoA No Actualizado Después de Cambios
El hallazgo: El SoA refleja el estado del ISMS en un momento que ya no coincide con la realidad. Se han identificado nuevos riesgos, se han implementado o eliminado controles, pero el SoA no se ha actualizado.
Por qué importa: Un SoA desactualizado indica que el documento se trata como un artefacto de certificación único en lugar de una parte viva del ISMS. También significa que el auditor no puede confiar en el SoA como una representación precisa del entorno de control.
Cómo evitarlo: Establezca una cadencia de revisión (recomendada trimestralmente) y desencadenantes para actualizaciones ad hoc. Incluya el mantenimiento del SoA como punto de la agenda en las revisiones por la dirección.
No Conformidad 5: Sin Trazabilidad entre la Evaluación de Riesgos y el SoA
El hallazgo: El registro de riesgos identifica ciertos riesgos, pero el SoA no incluye controles que aborden esos riesgos. O el SoA incluye controles sin referenciar los riesgos que abordan.
Por qué importa: La trazabilidad es el principio central de ISO 27001. El estándar requiere un enfoque impulsado por riesgos para la selección de controles. Sin trazabilidad, no hay evidencia de que el enfoque esté impulsado por riesgos.
Cómo evitarlo: Incluya IDs de referencia de riesgos en la columna de justificación del SoA. Al revisar el SoA, haga una referencia cruzada contra el registro de riesgos para verificar que cada riesgo por encima del umbral de aceptación tiene controles correspondientes, y que cada control incluido tiene una razón documentada para su inclusión.
No Conformidad 6: Controles del Annex A No Completamente Abordados
El hallazgo: El SoA no lista los 93 controles del Annex A. Algunos controles simplemente están ausentes del documento.
Por qué importa: La Cláusula 6.1.3 d) requiere que la organización determine “todos los controles que son necesarios” y los compare contra el Annex A para verificar que no se haya pasado por alto nada. Si faltan controles en el SoA, no hay evidencia de que fueron considerados.
Cómo evitarlo: Comience con una lista completa de los 93 controles y trabaje cada uno. Use una plantilla o herramienta de cumplimiento que garantice la completitud.
No Conformidad 7: El SoA y los Controles Reales No Coinciden
El hallazgo: El SoA documenta ciertos controles, pero la implementación real difiere. Por ejemplo, el SoA dice que MFA está implementado para todos los usuarios, pero el auditor encuentra que las cuentas de servicio evaden MFA.
Por qué importa: Se supone que el SoA representa con precisión el entorno de control. Las discrepancias indican que el SoA es aspiracional en lugar de factual, o que los controles han cambiado desde la última actualización del SoA.
Cómo evitarlo: Valide el SoA contra la implementación real antes de las auditorías. Realice una revisión interna donde alguien (que no sea el propietario del control) verifique que cada control “Implementado” está realmente operando como se describe.
Construyendo un SoA Práctico: Formato y Estructura
Formato de Hoja de Cálculo
El formato más común es una hoja de cálculo con las siguientes columnas:
| Columna | Contenido |
|---|---|
| Referencia del Control | A.5.1 hasta A.8.34 |
| Título del Control | Nombre completo del control del Annex A |
| ¿Aplicable? | Sí / No |
| Justificación | Razón para la inclusión o exclusión |
| Referencia(s) del Riesgo | IDs de riesgos del registro de riesgos |
| Estado de Implementación | Implementado / Parcial / Planificado / No Iniciado |
| Detalles de Implementación | Cómo se implementa el control (breve) |
| Referencia de Evidencia | Dónde encontrar evidencia de implementación |
| Propietario | Individuo con nombre responsable |
| Última Revisión | Fecha de la última revisión |
| Notas | Contexto adicional para auditores |
Organización por Tema
Organice el SoA siguiendo la estructura del Annex A: A.5 Organizacional, A.6 Personas, A.7 Físico, A.8 Tecnológico. Dentro de cada tema, liste los controles en orden numérico. Esto facilita la navegación y la referencia cruzada con el estándar para los auditores.
Nivel de Detalle
Encuentre un equilibrio entre exhaustividad y mantenibilidad. La justificación debe ser lo suficientemente específica para demostrar una toma de decisiones impulsada por riesgos, pero lo suficientemente concisa para que el documento siga siendo utilizable. Una justificación de una línea por control suele ser demasiado breve. Un párrafo completo por control suele ser suficiente. Una página por control es excesivo y hará que el documento sea imposible de mantener.
Ejemplos de Entradas del SoA
Control incluido con justificación de riesgos:
| Campo | Contenido |
|---|---|
| Referencia | A.8.5 |
| Título | Autenticación segura |
| Aplicable | Sí |
| Justificación | Aborda RISK-2026-003 (compromiso de credenciales que lleva a acceso no autorizado) y RISK-2026-015 (toma de control de cuentas basada en phishing). También es un requisito contractual en los acuerdos de procesamiento de datos de clientes empresariales. |
| Ref. Riesgo | RISK-2026-003, RISK-2026-015 |
| Estado | Implementado |
| Implementación | MFA a través de Okta para todos los sistemas internos. Integración SSO con AWS, GitHub, Datadog. Llaves de seguridad hardware para acceso a producción. Tiempo de espera de sesión: 12 horas. |
| Evidencia | Informe de inscripción MFA de Okta, capturas de configuración SSO, inventario de llaves hardware |
| Propietario | Sarah Chen, Jefa de TI |
| Revisado | 2026-02-15 |
Control excluido con justificación:
| Campo | Contenido |
|---|---|
| Referencia | A.7.12 |
| Título | Seguridad del cableado |
| Aplicable | No |
| Justificación | La organización no opera ningún centro de datos físico, sala de servidores o infraestructura de red más allá del equipamiento estándar de oficina. Toda la infraestructura de producción está alojada en AWS (eu-west-1, eu-central-1), donde la seguridad del cableado físico es gestionada por AWS bajo su certificación SOC 2 Tipo II. La red de oficina utiliza conectividad inalámbrica para los dispositivos de los empleados sin datos sensibles procesados en las instalaciones. |
| Ref. Riesgo | N/A |
| Estado | N/A |
| Implementación | N/A |
| Evidencia | N/A |
| Propietario | N/A |
| Revisado | 2026-02-15 |
SoA para Empresas SaaS: Consideraciones Prácticas
Modelo de Responsabilidad Compartida en la Nube
Muchas empresas SaaS tienen dificultades con cómo manejar los controles que caen bajo el modelo de responsabilidad compartida del proveedor de nube. El principio clave: no puede excluir un control simplemente porque su proveedor de nube maneja parte de él. Puede referenciar los controles del proveedor de nube como parte de su implementación, pero el control sigue siendo aplicable a su organización.
Ejemplo: A.7.5 (Protección contra amenazas físicas y ambientales) es gestionado principalmente por AWS para la infraestructura de producción. Pero el control no se excluye — se incluye con la justificación: “Para la infraestructura de producción, la protección física y ambiental es proporcionada por AWS, verificada a través de la revisión anual del informe SOC 2 Tipo II de AWS (A.5.22). Para las instalaciones de oficina, los sistemas de detección y supresión de incendios son mantenidos por el propietario del edificio, verificado a través de la revisión anual del contrato de arrendamiento.”
Alineación con Múltiples Marcos
Si su empresa SaaS también busca SOC 2, alinear su SoA con los Criterios de Servicios de Confianza de SOC 2 puede reducir la duplicación. Muchos controles del Annex A se mapean directamente a los Criterios Comunes de SOC 2. Su SoA puede señalar estos mapeos para demostrar un marco de control unificado.
Escalando el SoA con el Crecimiento
A medida que su empresa SaaS crece, su SoA evolucionará:
- Etapa temprana (< 50 empleados): Más controles pueden estar “Planificados” o “Parcialmente implementados”. Enfóquese en establecer la estructura correcta y avanzar hacia la implementación completa.
- Etapa de crecimiento (50-200 empleados): La mayoría de los controles deberían estar implementados. Comience a formalizar procesos que anteriormente se manejaban de manera informal. Agregue controles para la gestión de proveedores a medida que su ecosistema de proveedores crece.
- Etapa de escala (200+ empleados): Se espera la implementación completa. Enfóquese en la recopilación de evidencia, monitoreo continuo y medición de la eficacia de los controles. Considere agregar controles más allá del Annex A para amenazas avanzadas.
SoA y Auditoría Interna
Su programa de auditoría interna utiliza el SoA como base para la planificación de auditorías. El auditor interno verifica que:
- Cada control incluido está implementado según se describe
- Las justificaciones de exclusión siguen siendo válidas
- El estado de implementación es preciso
- La evidencia respalda las afirmaciones del SoA
- El SoA refleja los riesgos y controles actuales
Los hallazgos de la auditoría interna deben retroalimentar las actualizaciones del SoA, creando un ciclo de mejora continua.
Cómo Ayuda GRCTrail
GRCTrail proporciona a los equipos SaaS un enfoque estructurado y listo para auditoría para crear y mantener la Declaración de Aplicabilidad.
- Generación automatizada del SoA que mapea los resultados de su evaluación de riesgos a los 93 controles del Annex A, pre-completando justificaciones basadas en sus riesgos identificados y decisiones de tratamiento para que comience desde un documento impulsado por riesgos en lugar de una hoja de cálculo en blanco
- Seguimiento de implementación de controles con vinculación de evidencia, para que cada entrada del SoA se conecte con detalles de implementación, propietarios asignados y evidencia de soporte — dando a los auditores la trazabilidad que buscan sin referencias cruzadas manuales
- Gestión de documentos vivos con control de versiones, seguimiento de cambios y recordatorios de revisión automatizados que mantienen su SoA actualizado entre auditorías en lugar de dejarlo convertirse en un artefacto de certificación obsoleto
Guías Relacionadas
- ¿Qué es ISO 27001? Una Guía para Empresas SaaS
- Evaluación de Riesgos ISO 27001: Proceso, Metodología y Ejemplos
- Controles del Annex A de ISO 27001: Guía Completa de los 93 Controles
- Lista de Verificación de Certificación ISO 27001
- Guía de Auditoría Interna ISO 27001
- Requisitos de ISO 27001: Comprendiendo las Cláusulas 4-10
Artículos relacionados
Políticas de ISO 27001: Qué Políticas Necesita y Cómo Redactarlas
Aprenda qué políticas requiere su ISMS de ISO 27001, cómo escribir una política de seguridad de la información que supere la certificación, y consejos prácticos para equipos SaaS.
Control de Acceso en ISO 27001: Requisitos, Controles e Implementación para SaaS
Guía completa sobre los requisitos de control de acceso en ISO 27001, los controles del Annex A e implementación práctica para empresas SaaS, incluyendo IAM, MFA y revisiones de acceso.
Mejora Continua en ISO 27001: Auditorías de Vigilancia y Mantenimiento del ISMS
Aprende los requisitos de mejora continua de ISO 27001, incluyendo auditorías de vigilancia, recertificación, revisión por la dirección, métricas y KPIs del ISMS, y acciones correctivas.