La Declaración de Aplicabilidad es el documento que el auditor lee primero
Casi todos los proyectos de ISO 27001 escriben la Declaración de Aplicabilidad al final, como una hoja de 93 filas marcadas "aplicable". Bien hecha se deriva del análisis de riesgos, y es lo que hace que el resto de la auditoría vaya rápido.
Hay una forma de escribir una Declaración de Aplicabilidad que lleva una tarde: listar los 93 controles del Anexo A, marcar casi todos como "aplicable", escribir "implantado" al lado de cada uno y adjuntarla al sistema de gestión. Las entidades certificadoras ven esta versión constantemente y saben exactamente qué significa: que el análisis de riesgos no se usó.
La Declaración de Aplicabilidad es la bisagra de todo el sistema de gestión. Es el documento que conecta los riesgos que identificaste con los controles que elegiste, y es lo primero que lee un auditor porque le dice dónde buscar todo lo demás.
Qué tiene que contener
La cláusula 6.1.3 d) exige cuatro cosas por control, y la cuarta es la que se salta todo el mundo:
- Si el control es aplicable.
- La justificación de incluirlo.
- Si está implantado.
- La justificación de excluir cualquier control que hayas excluido.
Una Declaración donde no se excluye nada es una señal de alarma, no una virtud. Normalmente significa que nadie evaluó nada; simplemente se aceptó el catálogo entero. Una empresa SaaS de veinte personas que no desarrolla su propio sistema operativo, no tiene centro de datos físico ni sistemas de control industrial excluye legítimamente varios controles, y decirlo con un motivo es más sólido que afirmar que todo aplica.
Tiene que derivarse del análisis de riesgos, no precederlo
La secuencia correcta es: identificar riesgos, evaluarlos contra tus criterios, decidir el tratamiento y seleccionar controles que implementen ese tratamiento. La Declaración registra entonces qué controles del Anexo A usó el tratamiento, y el Anexo A cumple su función prevista: ser una lista de verificación para comprobar que no olvidaste una categoría de control, no la fuente de los controles.
Escrito al revés, el registro de riesgos se convierte en un documento fabricado para justificar una lista de controles, y un auditor lo detecta en una pregunta: "enséñame el riesgo que trata este control". Si la respuesta es "está en el Anexo A", el sistema de gestión es decorativo y la auditoría se alarga.
Ten en cuenta además que la norma no te limita al Anexo A. Si tu tratamiento del riesgo necesita un control que el Anexo A no contiene —y en una empresa cloud-native pasa a menudo, en aislamiento entre inquilinos, gestión de claves o cadena de suministro—, inclúyelo. El Anexo A es un conjunto de referencia, no un límite.
Que la columna de implantación apunte a la evidencia
El cambio más útil que puedes hacerle a una plantilla estándar de Declaración es añadir una columna con dónde vive la evidencia, y que sea un enlace y no una descripción.
En vez de "8.13 Copias de seguridad — implantado — se hacen copias diarias", escribe "8.13 — implantado — terraform/backup.tf, registro de prueba de restauración 2026-06-14, política de retención en docs/backup.md". El auditor sigue el enlace. Sin él, pregunta, tú buscas, y un punto de quince minutos se convierte en una hora.
Esto además tiene un efecto interno: un control cuya evidencia enlaza a una página de wiki escrita una vez se ve claramente más débil que uno cuya evidencia es la salida de un pipeline o un fichero de Terraform, y ponerlos uno al lado del otro en una misma tabla lo hace obvio para quien decide dónde gastar el próximo trimestre.
La implantación parcial se permite, y es mejor que una mentira
Los controles en curso deben decirlo, con fecha y responsable. "Parcialmente implantado — MFA obligatorio para administradores desde 2026-03; despliegue a toda la plantilla previsto 2026-10, responsable: Dirección de TI" es una entrada aceptable. Muestra un sistema gestionado.
Marcarlo como "implantado" cuando no lo está es lo único que daña de verdad una auditoría, porque en cuanto un auditor encuentra una entrada que exagera, vuelve a probar todas las demás. El coste de la honestidad es una no conformidad menor; el coste de que te pillen es el calendario entero.
Mantenla viva
La Declaración es un documento vivo, y la auditoría de seguimiento del segundo año la comparará con la del primero. Si es idéntica byte a byte, eso ya es un hallazgo: ¿nada cambió en tu panorama de riesgos en doce meses, en una empresa que sacó funcionalidades, contrató gente y adoptó servicios nuevos?
Revísala cuando cambie el análisis de riesgos, cuando entre un servicio o proveedor significativo, y en la revisión por la dirección. Guarda el histórico de versiones: el rastro de cambios es en sí mismo evidencia de que el sistema de gestión funciona.
La disciplina de alcance se paga aquí más que en ningún sitio
Todo control de la Declaración aplica a lo que diga tu declaración de alcance. Un alcance de "la plataforma de producción y los equipos que la construyen" da una Declaración manejable. Un alcance de "la empresa" arrastra los portátiles de ventas, el parque de SaaS de marketing y la oficina, cada uno con sus propios controles y su propia evidencia.
Un alcance estrecho no es hacer trampa, siempre que sea coherente y la frontera defendible: tus clientes van a leer el alcance del certificado, así que tiene que cubrir lo que están comprando. Pero la diferencia entre esas dos declaraciones de alcance son meses de trabajo, y se decide en la primera semana del proyecto, antes de que nadie abra la plantilla. Acierta con el alcance y el resto del Anexo A se vuelve tratable.