Declaración de Aplicabilidad (SoA) de ISO 27001 explicada simple

De todos los documentos que pide ISO 27001, la Declaración de Aplicabilidad es el que más miedo genera y el que menos se entiende. El nombre no ayuda, la sigla en inglés (SoA, Statement of Applicability) tampoco, y la primera vez que alguien abre una plantilla con 93 filas cierra la pestaña. La buena noticia: es una tabla, y su lógica cabe en un párrafo.

Qué es la Declaración de Aplicabilidad

Es el documento donde la organización recorre los 93 controles del Anexo A de ISO 27001:2022 y, para cada uno, declara tres cosas: si aplica o no, por qué, y en qué estado está su implementación. Nada más que eso. Es el puente entre la evaluación de riesgos (que dice qué te puede pasar) y los controles (que dicen qué hacés al respecto).

Es un documento obligatorio: la cláusula 6.1.3 de la norma lo exige explícitamente, y es prácticamente lo primero que va a pedir un auditor. También suele ser lo primero que pide un cliente corporativo cuando evalúa a un proveedor, incluso sin certificación de por medio.

Qué columnas tiene una SoA

Una SoA usable se arma con estas columnas y no mucho más:

• Identificador del control. El número del Anexo A (5.1, 5.19, 8.12, etc.).
• Nombre del control. Tal como figura en la norma, sin reescribirlo.
• ¿Aplica? Sí / No. La decisión, en una sola celda.
• Justificación. Por qué aplica o por qué no. Es la columna que un auditor lee con lupa.
• Estado de implementación. Implementado, parcial, planificado o no implementado.
• Evidencia o referencia. El documento, procedimiento o registro que demuestra que el control existe en la práctica.
• Responsable. Quién responde por ese control cuando lo pregunten.

Las cuatro primeras son obligatorias para cumplir con la cláusula 6.1.3. Las tres últimas son las que convierten el documento en algo que sirve para trabajar y no solo para mostrar.

Cómo se decide si un control aplica

Acá está el punto que casi todos pasan por alto: la SoA no se completa a criterio. Se completa a partir de la evaluación de riesgos. Si tu matriz identificó un riesgo de acceso indebido a datos de clientes, los controles de gestión de accesos aplican, y punto. Si un control no se conecta con ningún riesgo identificado ni con una obligación legal o contractual, ahí sí puede declararse como no aplicable.

Las razones de exclusión que un auditor acepta sin discutir son básicamente tres:

• La organización no tiene ese activo o esa actividad. Ejemplo clásico: el control 7.4 de monitoreo de seguridad física en una empresa 100% remota, sin oficina propia.
• La actividad está tercerizada y el requisito se traslada al proveedor por contrato. El control sigue existiendo, pero la evidencia la aporta el tercero.
• Ningún riesgo evaluado ni requisito legal lo motiva. Y esto queda escrito con esas palabras, no sobreentendido.

Lo que no funciona como justificación: "no tenemos recursos", "lo vamos a hacer el año que viene", "es muy caro". Eso no es un control no aplicable, es un control no implementado — y se declara así, con un plan y una fecha. Un auditor prefiere mil veces una SoA honesta con controles pendientes que una inflada donde todo figura implementado.

Un ejemplo de tres filas

5.15 — Control de accesos. Aplica: sí. Justificación: la evaluación de riesgos identificó acceso indebido a información de clientes como riesgo alto. Estado: implementado. Evidencia: política de control de accesos v2 y matriz de perfiles por sistema. Responsable: jefe de IT.

8.13 — Respaldo de la información. Aplica: sí. Justificación: riesgo de pérdida de datos por falla o ransomware, evaluado como crítico. Estado: parcial — hay backups diarios pero todavía no se realizan pruebas de restauración documentadas. Evidencia: procedimiento de backup y registro de ejecución. Responsable: infraestructura.

7.4 — Monitoreo de seguridad física. Aplica: no. Justificación: la organización opera de forma íntegramente remota y no administra instalaciones propias; la infraestructura está alojada en un proveedor cloud cuya seguridad física se verifica mediante su certificación ISO 27001. Estado: no corresponde. Evidencia: certificado del proveedor con su alcance.

Los errores más comunes

• Marcar los 93 controles como aplicables por las dudas. Genera 93 controles que hay que evidenciar. Excluir con justificación es más rápido, más barato y perfectamente válido.
• Copiar la SoA de otra empresa. Se nota en la primera pregunta del auditor, porque las justificaciones no coinciden con la matriz de riesgos propia.
• Declarar todo "implementado" sin evidencia. Es la forma más rápida de convertir una no conformidad menor en una mayor.
• Escribirla una vez y no volver a tocarla. Si cambian los riesgos, los sistemas o los proveedores, la SoA cambia. Una SoA con fecha del año pasado y una matriz actualizada la semana pasada es una contradicción evidente.
• Redactarla antes de evaluar riesgos. Es hacerlo al revés: sin matriz, las justificaciones no tienen de dónde salir.

Cómo mantenerla viva

La SoA no es un entregable de una vez: es una foto del sistema de gestión que se saca varias veces al año. La cadencia razonable es revisarla cada vez que se actualiza la evaluación de riesgos — trimestral o semestralmente en la mayoría de las PyMEs — y siempre antes de una auditoría interna o de responder un cuestionario de cliente.

Ahí es donde el Excel empieza a doler: la matriz de riesgos vive en un archivo, la SoA en otro, y nadie garantiza que las justificaciones de uno sigan reflejando lo que dice el otro. En Ryskos los controles del Anexo A se vinculan a los riesgos que los motivan, así que cuando un riesgo cambia de nivel o se cierra un plan de tratamiento, la trazabilidad hacia el control queda registrada sin tener que sincronizar dos planillas a mano.

En resumen

La Declaración de Aplicabilidad es una tabla que responde, control por control, tres preguntas: aplica o no, por qué, y en qué estado está. Sale de la evaluación de riesgos, no del criterio de quien la escribe, y su valor está en la honestidad de las justificaciones más que en la cantidad de controles marcados como implementados.

Si estás armando tu SGSI y querés partir de una matriz de riesgos que después sostenga la SoA, Ryskos tiene 30 días gratis y sin tarjeta para probarlo con los riesgos reales de tu empresa.