Redactar una Declaración de Aplicabilidad que supere la auditoría

La cláusula 6.1.3(d) de ISO/IEC 27001 exige una Declaración de Aplicabilidad: un documento que enumera los controles necesarios, explica por qué los incluyó, si están implementados y por qué excluyó alguno de los 93 controles del anexo A. Parece un trámite administrativo. En la práctica es el vínculo entre su evaluación de riesgos y sus controles, y los auditores de certificación la leen con detalle, porque una Declaración débil suele indicar un proceso de riesgos débil detrás.

Qué debe contener

Para cada control del anexo A, y para cualquier control propio:

1. Aplicable o no.
2. La justificación de inclusión: normalmente los riesgos que trata, un requisito legal o contractual, o una decisión de negocio.
3. Estado de implementación: implementado, parcialmente implementado o planificado.
4. La justificación de exclusión, si se excluye.

La mayoría de las Declaraciones añaden una breve descripción de cómo se implementa cada control y una referencia a la política o procedimiento. No es estrictamente obligatorio, pero agiliza mucho las auditorías.

Justificar la inclusión

Vincule cada control con algo concreto: un riesgo de su registro, un requisito legal (RGPD (GDPR), artículo 32, NIS2, normativa sectorial), un contrato o un requisito de cliente. «Buenas prácticas» es una justificación débil; «trata los riesgos R-12 y R-17 y lo exigen nuestras obligaciones NIS2» es sólida. Vincular los controles con requisitos legales también ayuda cuando debe responder ante varios marcos: nuestras páginas de requisitos muestran a qué otros marcos corresponde cada control del anexo A, por ejemplo A.8.24 uso de criptografía.

Justificar la exclusión

Se permiten las exclusiones, pero cada una necesita un motivo que los auditores puedan verificar. Motivos válidos:

• La actividad no se realiza en el alcance. Sin desarrollo externalizado: A.8.30 excluido.
• El riesgo no existe en el alcance. Una organización totalmente remota, sin oficinas, puede excluir algunos controles físicos de A.7, aunque no los que cubren equipos y soportes, estén donde estén.

Motivos débiles: «no es relevante», «lo gestiona TI», «lo hace el proveedor de la nube». Si un proveedor realiza el control, sigue siendo aplicable; se gestiona mediante controles de proveedores.

Hallazgos de auditoría habituales

• La Declaración no coincide con el plan de tratamiento de riesgos. Los controles elegidos en el tratamiento de riesgos deben figurar en la Declaración, y viceversa.
• Controles implementados sin evidencia. Marcar un control como implementado invita a pedir pruebas.
• Lenguaje de plantilla. Descripciones copiadas de una plantilla que no coinciden con lo que realmente se hace.
• Versiones obsoletas. Una Declaración que aún usa la numeración del anexo A de 2013, o que no se actualizó tras un cambio significativo.

Una estructura práctica

Una fila por control: ID y título, aplicable (sí/no), motivo (riesgos, requisitos legales y contractuales), estado, una descripción de una línea sobre cómo se realiza, el responsable y la referencia a la evidencia. Manténgala en una hoja de cálculo o en su herramienta GRC, bajo control documental, y revísela con cada evaluación de riesgos.

Mantener viva la Declaración

Una Declaración redactada para la primera certificación y no revisada después se convierte en un hallazgo en la siguiente auditoría. Manténgala actualizada, revisándola siempre que:

• la evaluación de riesgos modifique los controles seleccionados;
• cambie el alcance (un nuevo producto, oficina o proveedor de nube);
• cambie el estado de implementación de un control;
• se aplique un nuevo requisito legal o contractual (por ejemplo, NIS2 o el contrato de un cliente).

Registre la versión, la fecha y el aprobador en cada revisión.

Puntos clave

• Cada control del anexo A necesita una decisión y un motivo, incluidas las exclusiones.
• Vincule las inclusiones a riesgos concretos y a requisitos legales o contractuales.
• Mantenga la Declaración coherente con el plan de tratamiento de riesgos, y actualizada.

Varios marcos a la vez

Si también responde ante SOC 2, NIS2 o PCI DSS, añada una columna para los requisitos correspondientes de cada uno. La Declaración pasa entonces a ser la base de un conjunto común de controles. Nuestro artículo sobre un conjunto de controles común para SOC 2 e ISO 27001 muestra el enfoque, y el análisis de brechas enumera cada control del anexo A frente a cualquier otro marco. La guía de ISO 27001 cubre el resto de la certificación.

Preguntas

¿Se pueden excluir controles del anexo A en ISO 27001?

Sí, si la exclusión está justificada, normalmente porque el riesgo no existe en su alcance (por ejemplo, desarrollo externalizado cuando no externaliza el desarrollo). Las exclusiones deben justificarse en la Declaración de Aplicabilidad.

¿Qué debe contener una Declaración de Aplicabilidad?

La cláusula 6.1.3(d) de ISO 27001 exige los controles necesarios, la justificación de incluirlos, si están implementados y la justificación de excluir cualquier control del anexo A.

¿La Declaración de Aplicabilidad se comparte con los clientes?

Normalmente no en su totalidad: es un documento interno que revisa el organismo de certificación. Algunas organizaciones comparten un resumen con los clientes bajo acuerdo de confidencialidad (NDA) para mostrar qué controles aplican.