¿Qué es una Declaración de Aplicabilidad (SoA)?
La Declaración de Aplicabilidad (SoA) es un documento obligatorio de ISO 27001 que enumera los 93 controles del Anexo A y explica si cada control está incluido en…
Visión general
La Declaración de Aplicabilidad (SoA) es un documento obligatorio de ISO 27001 que enumera los 93 controles del Anexo A y explica si cada control está incluido en su SGSI o excluido. Para los controles incluidos, describe cómo se implementan. Para los controles excluidos, proporciona una justificación para la exclusión.
Qué 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 elegido implementar. Los auditores la utilizan como hoja de ruta para verificar que su SGSI aborda los riesgos identificados de manera adecuada.
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 malware) como "Incluido" con detalles de implementación como "Software de detección y respuesta en endpoints desplegado en todos los dispositivos con gestión centralizada", mientras que el control A.7.4 (Monitoreo de seguridad física) podría ser "Excluido - la organización es solo en la nube sin centro de datos físico".
Por qué la SoA es importante para ISO 27001
Requisito obligatorio
La cláusula 6.1.3(d) de 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 puede lograr la certificación sin una SoA completa y precisa.
Demuestra un enfoque basado en riesgos
La SoA prueba que no está implementando controles al azar ni aplicando plantillas a ciegas. Muestra cómo cada decisión de control se remonta a su evaluación de riesgos.
Hoja de ruta para la auditoría
Los auditores utilizan su SoA para planificar qué verificarán durante las auditorías de certificación. Los controles incluidos necesitan evidencia 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 evolucionan los riesgos, su SoA debe actualizarse para reflejar nuevos requisitos de control o permitir que se eliminen controles previamente excluidos si los riesgos disminuyen.
Hallazgo común en auditorías: Justificaciones de 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) mientras su evaluación de riesgos identifica la pérdida de datos como un riesgo alto resultará en una no conformidad.
Qué debe incluir la SoA
Lista completa de controles
Los 93 controles del Anexo A de ISO 27001:2022 deben aparecer en su SoA, organizados por tema:
- Controles organizacionales: A.5.1 hasta A.5.37 (37 controles)
- Controles de personas: A.6.1 hasta A.6.8 (8 controles)
- Controles físicos: A.7.1 hasta A.7.14 (14 controles)
- Controles tecnológicos: A.8.1 hasta 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 están dentro o 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 responsable del control
- Dónde se puede encontrar evidencia de la implementación
- Cómo el control aborda los riesgos identificados
Justificación de exclusión (para controles excluidos)
Explique por qué los controles excluidos no forman parte de su SGSI. Justificaciones válidas:
- Basada en riesgos: "No hay riesgos en nuestra evaluación que requieran este control"
- Basada en el contexto: "No aplicable - somos solo en la nube sin infraestructura física"
- Legal/regulatoria: "Prohibido por las leyes de residencia de datos en nuestra jurisdicción"
Calidad de la justificación: Las justificaciones sólidas de exclusión hacen referencia a hallazgos específicos de la evaluación de riesgos o al contexto organizacional. Las justificaciones débiles como "no relevante" o "no implementado aún" serán cuestionadas por los auditores.
Estructura y formato de la SoA
Formato tabular (el más común)
Una tabla con columnas para:
- Número del 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 de riesgo (vinculación al 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 controles agrupados por tema. Menos común pero aceptable si aborda claramente los 93 controles.
Formato basado en herramientas
Las plataformas GRC y las herramientas de SGSI a menudo generan SoA automáticamente basándose en la selección de controles y la vinculación con las evaluaciones de riesgos. Estas aún necesitan validación manual para garantizar su precisión.
Preferencia del auditor: La mayoría de los auditores prefieren las SoA tabulares porque son fáciles de escanear y referenciar. Mantenga las descripciones de implementación concisas (2-3 oraciones por control): los procedimientos detallados pertenecen a documentos de procedimiento separados, no a la SoA.
Creación de su SoA
Paso 1: Completar 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 controles a riesgos
Para cada riesgo que requiera tratamiento, identifique qué controles del Anexo A lo reducirían a niveles aceptables. Un riesgo puede necesitar múltiples controles; un control puede abordar múltiples riesgos.
Paso 3: Determinar inclusión/exclusión
Los controles que abordan 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 completos.
Paso 5: Justificar exclusiones
Para los controles excluidos, explique por qué basándose en su evaluación de riesgos o contexto organizacional. Haga referencia a hallazgos específicos de su registro de riesgos cuando 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 agregan o modifican controles, o se reconsideran exclusiones. Mantenga un historial de versiones que muestre cuándo y por qué ocurrieron los cambios.
Errores comunes en la SoA
Excluir demasiados controles
Las organizaciones a veces 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 genéricas de implementación
Copiar descripciones de controles de ISO 27002 sin describir su implementación real. Los auditores necesitan entender qué hace usted, no lo que dice la norma.
Falta de vínculos con los riesgos
No conectar los controles con riesgos específicos en su evaluación de riesgos. Esto rompe la trazabilidad y sugiere que los controles fueron seleccionados arbitrariamente.
Cobertura incompleta
Olvidar abordar los 93 controles. Incluso si un control parece obviamente no aplicable, debe aparecer en la SoA con justificación de exclusión.
Sin ciclo de revisión
Crear la SoA una vez durante la implementación inicial y nunca actualizarla a pesar de los cambios organizacionales o nuevos riesgos.
Consejo de eficiencia: Use ISMS Copilot para generar una plantilla de SoA con descripciones comunes de implementación para su industria. Personalice el resultado en función de los resultados de su evaluación de riesgos y contexto específicos.
SoA vs. otros documentos de ISO 27001
SoA vs. Plan de Tratamiento de Riesgos
El Plan de Tratamiento de Riesgos detalla cómo implementará los controles seleccionados (plazos, responsabilidades, recursos). La SoA declara qué controles se implementan y por qué. Los dos documentos son complementarios.
SoA vs. Evidencia de Control
La SoA describe qué controles implementa. La evidencia prueba que los controles están operando efectivamente. Durante las auditorías, los auditores muestrean controles de su SoA y solicitan la evidencia correspondiente.
SoA vs. Políticas y Procedimientos
Las políticas y procedimientos proporcionan instrucciones detalladas para implementar controles. La SoA resume a alto nivel qué controles existen y cómo funcionan.
Cómo utilizan los auditores la SoA
Auditoría de etapa 1 (revisión de documentación)
Los auditores verifican que su SoA esté completa (los 93 controles abordados), 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 implementación)
Los auditores muestrean controles de su SoA y solicitan evidencia de que están implementados como se describe. Probarán controles en los cuatro temas y áreas organizacionales dentro del alcance.
Motivos de no conformidad
Razones comunes por las que los auditores emiten no conformidades relacionadas con la SoA:
- Controles marcados como "incluidos" pero no implementados realmente
- Exclusiones sin justificación válida
- SoA que no refleja los resultados reales de la evaluación de riesgos
- Controles faltantes (menos de 93 listados)
- Descripciones de implementación demasiado vagas para verificar
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 puede encontrar evidencia para 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 reevaluaciones de riesgos programadas, revise la SoA para determinar si las selecciones de controles siguen siendo apropiadas. Nuevos riesgos pueden requerir controles previamente excluidos.
Cambios organizacionales
Actualice la SoA cuando:
- Se despliegue nueva tecnología (puede requerir nuevos controles técnicos)
- Cambie el modelo de negocio (ej., mudarse a la nube cambia los controles físicos)
- La expansión geográfica introduzca nuevos requisitos regulatorios
- Fusiones o adquisiciones cambien el perfil de riesgo
Revisiones desencadenadas por incidentes
Después de incidentes de seguridad significativos, revise si los controles existentes fueron efectivos o si deberían implementarse controles adicionales (previamente excluidos).
Auditorías de vigilancia
Los auditores verificarán durante las auditorías anuales de vigilancia si la SoA se ha mantenido actualizada. La evidencia de revisión regular demuestra que su SGSI está activo, no abandonado después de la certificación.
SoA y personalización de controles
La norma permite adaptaciones
ISO 27001 permite a las organizaciones implementar controles de manera diferente según el tamaño, la complejidad y el 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 no abordados adecuadamente por los 93 controles estándar, puede implementar controles adicionales. Enumere estos en su SoA o en un documento complementario.
La proporcionalidad importa
La implementación de "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 empleados. Ambas pueden ser conformes si son apropiadas para el contexto y efectivas en la reducción de riesgos.
Ejemplo de implementación proporcional: Una pequeña empresa SaaS solo en la nube podría excluir A.7.1-A.7.14 (controles físicos) justificando "Sin 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 cloud-first.
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 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 frente a los resultados de la evaluación de riesgos y asegúrese de que los 93 controles estén debidamente abordados.