Qué es la declaración de aplicabilidad en ISO 27001

La ISO 27001 exige poca información documentada con nombre propio, y la declaración de aplicabilidad —el SoA, por sus siglas en inglés— es una de las pocas. No es casualidad que sea el primer documento que pide un auditor de certificación: en una sola tabla se ve si entendiste el sistema o si copiaste el anexo A y le pusiste "aplica" a todo.

Qué tiene que contener

• —La lista completa de los controles del anexo A, sin omitir ninguno. El anexo se revisa entero aunque descartes la mitad.
• —Para cada control, si es aplicable o no. Es una decisión binaria y explícita, no un espacio en blanco.
• —La justificación de la inclusión: por qué ese control está ahí — riesgo tratado, requisito legal, contractual o del negocio.
• —La justificación de la exclusión, que es la parte que más se descuida. "No aplica" no es una justificación; "no desarrollamos software internamente, todo el desarrollo es de terceros y se cubre con los controles de proveedores" sí lo es.
• —El estado de implementación de cada control aplicable: implementado, parcial, planificado con fecha.
• —La referencia a dónde está implementado: política, procedimiento, configuración técnica o registro que lo evidencia.

De dónde sale: primero el riesgo, luego el SoA

El orden importa y se invierte con frecuencia. La secuencia correcta es: identificar los riesgos de seguridad de la información, evaluarlos, decidir el tratamiento, y solo entonces determinar qué controles hacen falta. El anexo A se usa después, como lista de verificación para comprobar que ningún control necesario se quedó fuera. Cuando se hace al revés —tomar los controles del anexo y buscarles un riesgo que justifique cada uno— el resultado es un sistema que protege lo que la norma sugiere en lugar de lo que tu organización realmente tiene en juego.

Los controles no salen solo del anexo A

La norma permite —y en la práctica espera— que existan controles adicionales que no están en el anexo, si el tratamiento de riesgo los exige. Un requisito regulatorio del sector, una exigencia contractual de un cliente grande o una medida técnica específica de tu arquitectura pueden generar controles propios. Incluirlos en el SoA no es un error: es señal de que la evaluación de riesgo condujo el diseño en lugar de al revés.

Por qué las exclusiones son el punto de fricción

Excluir controles es legítimo, pero cada exclusión es una afirmación verificable sobre tu operación. Si excluyes los controles de teletrabajo, el auditor va a comprobar que efectivamente nadie trabaja fuera de sitio. Si excluyes los de desarrollo seguro, va a revisar que no exista código propio en producción. Las exclusiones que no resisten esa comprobación son de los hallazgos mayores más frecuentes en certificación inicial, porque no son un detalle formal: significan que el alcance declarado no coincide con lo que realmente ocurre.

Un documento que cambia

El SoA no es un entregable del proyecto de certificación: es un documento vivo que debe actualizarse cuando cambia el alcance, cuando entra un servicio o una tecnología nueva, cuando se firma un contrato con requisitos adicionales o cuando la reevaluación de riesgos modifica el tratamiento. Un SoA con la misma versión de hace tres años, en una organización que migró a la nube en ese periodo, dice más sobre el estado real del sistema que cualquier informe.

Control de versiones y aprobación del SoA

Como documento obligatorio, el SoA está sujeto al mismo control que el resto de la información documentada: versión vigente única, aprobación registrada, historial de cambios y disponibilidad para quien lo necesita. Y como cada control aplicable apunta a una política o procedimiento, la coherencia entre el SoA y esos documentos tiene que sostenerse en el tiempo. Ahí es donde entra un Software de gestión documental para sistemas de gestión: la versión vigente del SoA sin copias en circulación, el registro de quién aprobó cada cambio y por qué, y la trazabilidad entre cada control declarado y el documento que lo respalda.