SoA Declaración de Aplicabilidad.

Por qué ISO 27001 hace obligatorio el SoA

La declaración de aplicabilidad es el puente entre su trabajo sobre los riesgos y los controles que un auditor inspeccionará realmente. ISO/IEC 27001 deja deliberadamente abierto el cuerpo de la norma sobre qué controles debe ejecutar, porque la respuesta correcta depende de su contexto y de sus riesgos. El SoA es donde usted cierra esa brecha: para cada control de referencia del Anexo A, registra si aplica, la justificación para incluirlo o excluirlo, si ya está implementado y dónde reside la evidencia que lo respalda. Es uno de los pocos documentos que la norma nombra explícitamente como salida requerida, razón por la cual ninguna auditoría de certificación se desarrolla sin él.

Una forma útil de entenderlo es que el SoA convierte un catálogo de controles genérico en una declaración sobre su organización específicamente. El conjunto de referencia del Anexo A es el mismo para todos. Su SoA no lo es. Dos empresas certificadas de tamaño similar pueden excluir legítimamente controles diferentes, porque sus apreciaciones de riesgos y su contexto operativo difieren. El documento existe para hacer esas elecciones visibles y defendibles en lugar de implícitas.

Cómo se relaciona el SoA con la apreciación de riesgos y el tratamiento de riesgos

El SoA no existe por sí solo. Es el producto posterior de la apreciación de riesgos y del plan de tratamiento de riesgos, y los tres deben concordar. La apreciación de riesgos identifica qué podría salir mal. El plan de tratamiento de riesgos decide qué hacer con cada riesgo, incluido qué controles aplicar. El SoA declara entonces, control por control, qué significa esa decisión frente al conjunto de referencia del Anexo A. Cuando un auditor lee el SoA, en realidad está comprobando que la línea que va de un riesgo documentado a una decisión de tratamiento, luego a un control aplicado, y luego a evidencia real, se sostiene de principio a fin.

Las exclusiones merecen un cuidado especial. Marcar un control como no aplicable es legítimo, pero solo con un motivo declarado y vinculado a su contexto. «No desarrollamos software internamente» es una base defendible para acotar ciertos controles de desarrollo. «No llegamos a hacerlo» no es una exclusión, es una carencia. Los auditores indagan las exclusiones precisamente porque es ahí donde las organizaciones a veces esconden trabajo sin terminar.

Lo que los profesionales mantienen realmente

Tratar el SoA como un registro vivo en lugar de una hoja de cálculo puntual es lo que separa una auditoría de seguimiento tranquila de una carrera contrarreloj. En la práctica, mantenerlo bien se ve así:

1. Mantenga una fila por cada control del Anexo A, con aplicabilidad, justificación, estado de implementación y un puntero a la evidencia que un auditor pueda seguir sin usted en la sala.
2. Vuelva a generar el SoA siempre que cambie la apreciación de riesgos o el plan de tratamiento, para que los tres documentos nunca diverjan en silencio.
3. Vincule cada puntero de evidencia a algo real y actual: una política, una configuración, un ticket, un registro, no una promesa de producirlo más adelante.
4. Revise el documento con una cadencia fija y en la revisión por la dirección, no solo en las semanas previas a una auditoría.
5. Al transicionar entre versiones de la norma, reasigne el SoA frente al conjunto de controles revisado y confirme que nada se perdió entre los controles fusionados o recién introducidos.

Hecho así, el SoA deja de ser papeleo de auditoría y se convierte en el índice de todo su sistema de gestión de la seguridad de la información. Es el primer documento que un auditor experimentado pide, porque le indica dónde reside todo lo demás.