¿Qué es una Declaración de Aplicabilidad (SoA)?
Resumen
La Declaración de Aplicabilidad (SoA) es un documento obligatorio de la norma ISO 27001 que enumera los 93 controles del Anexo A y explica si cada control está incluido o excluido de su SGSI. Para los controles incluidos, describe cómo se implementan. Para los controles excluidos, proporciona la justificación de su exclusión.
Lo que significa en la práctica
La SoA es el plano de selección de sus controles: conecta los resultados de su evaluación de riesgos con los controles de seguridad específicos que ha decidido implementar. Los auditores la utilizan como hoja de ruta para verificar que su SGSI aborda adecuadamente los riesgos identificados.
Ejemplo del mundo real: Su evaluación de riesgos identifica el ransomware como una amenaza crítica. Su SoA mostraría el control A.8.7 (Protección contra el malware) como "Incluido" con detalles de implementación como "Software de detección y respuesta en puntos finales desplegado en todos los dispositivos con gestión centralizada", mientras que el control A.7.4 (Monitoreo de la seguridad física) podría estar "Excluido: la organización solo opera en la nube y no tiene un centro de datos físico".
Por qué es importante la SoA para la ISO 27001
Requisito obligatorio
La cláusula 6.1.3(d) de la norma ISO 27001 exige explícitamente mantener "una Declaración de Aplicabilidad que contenga los controles necesarios y la justificación de las inclusiones y exclusiones". No se puede obtener la certificación sin una SoA completa y precisa.
Demuestra un enfoque basado en el riesgo
La SoA demuestra que usted no está implementando controles al azar ni aplicando plantillas a ciegas. Muestra cómo cada decisión sobre un control se remonta a su evaluación de riesgos.
Hoja de ruta de la auditoría
Los auditores utilizan su SoA para planificar lo que verificarán durante las auditorías de certificación. Los controles incluidos necesitan pruebas de implementación y eficacia. Las exclusiones deben estar justificadas en función de la evaluación de riesgos o el contexto empresarial.
Gestión del cambio
A medida que los riesgos evolucionan, su SoA debe actualizarse para reflejar los nuevos requisitos de control o permitir que se eliminen los controles excluidos anteriormente si los riesgos disminuyen.
Hallazgo común en las auditorías: Justificaciones en la SoA que no coinciden con los resultados de la evaluación de riesgos. Por ejemplo, excluir los controles de copia de seguridad (A.8.13) cuando su evaluación de riesgos identifica la pérdida de datos como un riesgo alto dará lugar a una no conformidad.
Qué debe incluir la SoA
Lista completa de controles
Los 93 controles del Anexo A de la norma ISO 27001:2022 deben aparecer en su SoA, organizados por temas:
Controles organizacionales: A.5.1 a A.5.37 (37 controles)
Controles de personas: A.6.1 a A.6.8 (8 controles)
Controles físicos: A.7.1 a A.7.14 (14 controles)
Controles tecnológicos: A.8.1 a A.8.34 (34 controles)
Estado de inclusión/exclusión
Para cada control, indique claramente si está incluido en su SGSI o excluido. Evite estados ambiguos como "parcialmente aplicable": los controles o están dentro o están fuera.
Descripción de la implementación (para controles incluidos)
Describa brevemente cómo implementa cada control incluido. Incluya:
Políticas, procedimientos o tecnologías específicas utilizadas
Quién es el responsable del control
Dónde se pueden encontrar las pruebas de implementación
Cómo aborda el control los riesgos identificados
Justificación de la exclusión (para controles excluidos)
Explique por qué los controles excluidos no forman parte de su SGSI. Justificaciones válidas:
Basadas en el riesgo: "Ningún riesgo en nuestra evaluación requiere este control"
Basadas en el contexto: "No aplicable: somos una organización basada únicamente en la nube sin infraestructura física"
Legales/regulatorias: "Prohibido por las leyes de residencia de datos en nuestra jurisdicción"
Calidad de la justificación: Las justificaciones de exclusión sólidas hacen referencia a hallazgos específicos de la evaluación de riesgos o al contexto organizativo. Los auditores cuestionarán las justificaciones débiles como "no es relevante" o "aún no se ha implementado".
Estructura y formato de la SoA
Formato tabular (el más común)
Una tabla con columnas para:
Número de control (ej. A.5.1)
Nombre del control (ej. "Políticas para la seguridad de la información")
Estado (Incluido / Excluido)
Descripción de la implementación o justificación de la exclusión
Referencia al riesgo (vinculación con el registro de riesgos)
Ubicación de la evidencia (opcional pero útil)
Formato narrativo
Algunas organizaciones prefieren un documento narrativo que describa la implementación de los controles agrupados por temas. Es menos común, pero aceptable si aborda claramente los 93 controles.
Formato basado en herramientas
Las plataformas GRC y las herramientas de SGSI suelen generar SoA automáticamente a partir de la selección de controles y su vinculación con las evaluaciones de riesgos. Estas siguen requiriendo una validación manual para garantizar su exactitud.
Preferencia del auditor: La mayoría de los auditores prefieren las SoA tabulares porque son fáciles de escanear y de cotejar. Mantenga las descripciones de la implementación de forma concisa (2 o 3 frases por control); los procedimientos detallados deben estar en documentos de procedimientos separados, no en la SoA.
Cómo crear su SoA
Paso 1: Realizar la evaluación de riesgos
Su SoA es un resultado directo de la evaluación de riesgos. Identifique todos los riesgos que requieren tratamiento antes de determinar qué controles implementar.
Paso 2: Mapear los controles con los riesgos
Para cada riesgo que requiera tratamiento, identifique qué controles del Anexo A lo reducirían a niveles aceptables. Un riesgo puede necesitar varios controles; un control puede abordar varios riesgos.
Paso 3: Determinar la inclusión/exclusión
Los controles que abordan los riesgos identificados se incluyen. Los controles que no abordan ninguno de sus riesgos pueden excluirse (con justificación).
Paso 4: Describir la implementación
Para los controles incluidos, documente cómo los está implementando. Sea lo suficientemente específico para que los auditores entiendan su enfoque sin duplicar procedimientos enteros.
Paso 5: Justificar las exclusiones
Para los controles excluidos, explique el motivo basándose en su evaluación de riesgos o en el contexto de la organización. Haga referencia a hallazgos específicos de su registro de riesgos siempre que sea posible.
Paso 6: Revisar y aprobar
La dirección debe revisar y aprobar formalmente la SoA, reconociendo las decisiones de selección de controles y cualquier riesgo residual.
Control de versiones: La SoA es un documento vivo que debe actualizarse cuando cambian los riesgos, se añaden o modifican controles o se reconsideran las exclusiones. Mantenga un historial de versiones que muestre cuándo y por qué se produjeron los cambios.
Errores comunes en la SoA
Excluir demasiados controles
A veces, las organizaciones excluyen controles para reducir el esfuerzo de implementación. Los auditores examinan cuidadosamente las exclusiones; si su evaluación de riesgos es exhaustiva, la mayoría de los controles deberían estar incluidos.
Descripciones de implementación genéricas
Copiar las descripciones de los controles de la norma ISO 27002 sin describir su implementación real. Los auditores necesitan entender qué hace usted, no lo que dice la norma.
Falta de vinculación con los riesgos
No conectar los controles con los riesgos específicos de su evaluación de riesgos. Esto rompe la trazabilidad y sugiere que los controles se seleccionaron de forma arbitraria.
Cobertura incompleta
Olvidar abordar los 93 controles. Incluso si un control parece obviamente no aplicable, debe aparecer en la SoA con la justificación de su exclusión.
Ausencia de un ciclo de revisión
Crear la SoA una sola vez durante la implementación inicial y no volver a actualizarla nunca a pesar de los cambios organizativos o los nuevos riesgos.
Consejo de eficiencia: Utilice ISMS Copilot para generar una plantilla de SoA con descripciones de implementación comunes para su sector. Personalice el resultado en función de los resultados de su evaluación de riesgos y su contexto específico.
La SoA frente a otros documentos de la ISO 27001
SoA frente al Plan de Tratamiento de Riesgos
El Plan de Tratamiento de Riesgos detalla cómo se implementarán los controles seleccionados (plazos, responsabilidades, recursos). La SoA declara qué controles se implementan y por qué. Ambos documentos son complementarios.
SoA frente a la Evidencia de Controles
La SoA describe qué controles implementa. La evidencia demuestra que los controles funcionan realmente de forma eficaz. Durante las auditorías, los auditores toman muestras de controles de su SoA y solicitan la evidencia correspondiente.
SoA frente a Políticas y Procedimientos
Las políticas y los procedimientos proporcionan instrucciones detalladas para implementar los controles. La SoA resume a un alto nivel qué controles existen y cómo funcionan.
Cómo utilizan los auditores la SoA
Auditoría de etapa 1 (revisión de la documentación)
Los auditores verifican que su SoA esté completa (que se aborden los 93 controles), que esté estructurada lógicamente y alineada con su evaluación de riesgos. Comprueban que las justificaciones de las exclusiones tengan sentido.
Auditoría de etapa 2 (verificación de la implementación)
Los auditores toman muestras de controles de su SoA y solicitan pruebas de que se han implementado tal como se describe. Probarán controles de los cuatro temas y de las áreas organizativas dentro del alcance.
Detonantes de no conformidad
Razones comunes por las que los auditores emiten no conformidades relacionadas con la SoA:
Controles marcados como "incluidos" pero no implementados en realidad
Exclusiones sin una justificación válida
La SoA no refleja los resultados reales de la evaluación de riesgos
Faltan controles (se enumeran menos de 93)
Descripciones de implementación demasiado vagas para ser verificadas
Preparación para la auditoría: Antes de la auditoría de certificación, revise cada control "incluido" en su SoA y reúna la evidencia correspondiente. Si no encuentra evidencia de un control, impleméntelo correctamente o actualice la SoA para excluirlo con justificación.
Mantenimiento de la SoA a lo largo del tiempo
Actualizaciones anuales de la evaluación de riesgos
Cuando realice las reevaluaciones de riesgo programadas, revise la SoA para determinar si las selecciones de controles siguen siendo adecuadas. Los nuevos riesgos pueden requerir controles previamente excluidos.
Cambios organizativos
Actualice la SoA cuando:
Se despliegue nueva tecnología (puede requerir nuevos controles técnicos)
Cambie el modelo de negocio (por ejemplo, el traslado a la nube cambia los controles físicos)
La expansión geográfica introduzca nuevos requisitos reglamentarios
Las fusiones o adquisiciones cambien el perfil de riesgo
Revisiones provocadas por incidentes
Tras incidentes de seguridad significativos, revise si los controles existentes fueron eficaces o si deberían implementarse controles adicionales (previamente excluidos).
Auditorías de vigilancia
En las auditorías de vigilancia anuales, los auditores comprobarán si la SoA se ha mantenido al día. La evidencia de una revisión periódica demuestra que su SGSI está activo y no abandonado tras la certificación.
SoA y personalización de controles
La norma permite la adaptación
La ISO 27001 permite a las organizaciones implementar los controles de forma diferente en función de su tamaño, complejidad y riesgo. Su SoA debe reflejar su implementación específica, no una plantilla genérica.
Controles adicionales más allá del Anexo A
Si su evaluación de riesgos identifica riesgos que no se abordan adecuadamente con los 93 controles estándar, puede implementar controles adicionales. Enumere estos en su SoA o en un documento complementario.
La proporcionalidad es importante
La implementación de un "A.6.3 Formación en concienciación sobre seguridad de la información" de una startup de 10 personas diferirá de la de una empresa de 10.000 personas. Ambas pueden cumplir la norma si son apropiadas al contexto y eficaces para reducir el riesgo.
Ejemplo de implementación proporcional: Una pequeña empresa de SaaS que solo utiliza la nube podría excluir los controles A.7.1-A.7.14 (controles físicos) justificando que "No hay infraestructura física: todos los sistemas operan en AWS con seguridad gestionada por los controles SOC 2 del proveedor de la nube". Esto es aceptable si su evaluación de riesgos refleja la arquitectura centrada en la nube.
Conceptos relacionados
Controles del Anexo A: los 93 controles de seguridad que su SoA debe abordar
Evaluación de riesgos: proceso que impulsa la selección de controles en su SoA
Tratamiento de riesgos: implementación de los controles identificados en su SoA
Control: las medidas de seguridad que selecciona en su SoA
Cómo empezar con la implementación de ISO 27001 utilizando IA
Obtener ayuda
Acelere la creación de la SoA con ISMS Copilot. Genere descripciones de implementación personalizadas, valide sus justificaciones con los resultados de la evaluación de riesgos y asegúrese de que los 93 controles se aborden correctamente.