Documentar los controles ISO 27001 es donde la mayoría de las implementaciones pierden tiempo o se equivocan de foco. El problema habitual no es falta de documentación, es documentación que no refleja lo que ocurre realmente en la organización, o que nació de plantillas genéricas que nadie en el equipo reconoce como suya.
Un auditor de certificación no valora el grosor de las carpetas: valora la coherencia entre lo que dicen las políticas, lo que muestran los registros y lo que responde el equipo cuando le preguntan. Esta guía explica cómo llegar a esa coherencia de forma eficiente, sin fabricar documentación que nadie va a mantener.
Qué entiende ISO 27001 por «información documentada»
La versión vigente de ISO/IEC 27001 usa el término información documentada en lugar del clásico «documentos y registros». La distinción importa porque la norma distingue dos funciones:
- Documentos: describen cómo se hacen las cosas (políticas, procedimientos, metodologías). Se redactan y se actualizan cuando cambia el proceso.
- Registros: demuestran que se hizo lo que el documento dice (actas, logs, evidencias de revisión). Se generan en la operación diaria.
El error más frecuente es crear muchos documentos y pocos registros. Un auditor puede vivir con una política escueta si los registros demuestran que el proceso funciona. No puede aprobar un sistema lleno de políticas perfectas sin evidencia de que alguien las aplica.
La norma exige explícitamente información documentada en cláusulas concretas (contexto, liderazgo, planificación, evaluación del desempeño y mejora). Para los controles del Anexo A, el catálogo de 93 controles de la ISO 27001:2022, la exigencia no es documentar cada control con un procedimiento propio, sino poder demostrar que el control existe y funciona.
La Declaración de Aplicabilidad (SoA): el documento central del SGSI
La Declaración de Aplicabilidad (Statement of Applicability, SoA) es el documento que conecta los controles del Anexo A con la realidad de tu organización. Es obligatoria y suele ser el primer punto de partida de cualquier auditoría de certificación.
Para cada uno de los 93 controles del Anexo A, la SoA debe recoger:
- Si el control aplica o no, y si no aplica, la justificación.
- Si el control está implantado, y en qué grado.
- La referencia a la política, procedimiento o evidencia que lo sustenta.
Una SoA bien construida no es una tabla de Excel con 93 filas de «sí aplica / sí implantado» sin más. Cada fila debe poder conectarse con algo real: un procedimiento, un sistema, un registro. Si no puedes hacer esa conexión para un control que marcas como implantado, tienes una no conformidad potencial antes de entrar al audit.
Algunas recomendaciones prácticas:
- No excluyas controles por comodidad. Excluir un control requiere justificación sólida (porque el riesgo no existe o porque otro control lo cubre de forma equivalente). Los auditores revisan las exclusiones con especial atención.
- Usa referencias cruzadas reales. Si el control C.8.1 (gestión de activos de información) está cubierto por vuestra herramienta de inventario, di exactamente cuál y dónde se pueden ver los registros.
- Mantén la SoA viva. Es un documento que debe actualizarse cuando cambia el alcance, cuando entra un nuevo sistema o cuando se modifica un proceso relevante.
Qué documentación es obligatoria por cláusula
Más allá de la SoA, la norma exige información documentada en puntos concretos de las cláusulas 4 a 10. El listado mínimo que ningún SGSI puede presentar sin:
Cláusula 4: Contexto
- Alcance del SGSI (documentado explícitamente).
Cláusula 5: Liderazgo
- Política de seguridad de la información (aprobada por dirección, disponible para las partes interesadas pertinentes).
Cláusula 6: Planificación
- Metodología de evaluación y tratamiento de riesgos.
- Resultados de la evaluación de riesgos (el análisis propiamente dicho).
- Plan de tratamiento de riesgos.
- Declaración de Aplicabilidad (SoA).
- Objetivos de seguridad de la información.
Cláusula 7: Apoyo
- Competencias del personal con roles de seguridad.
- Evidencia de formación y concienciación.
Cláusula 8: Operación
- Resultados actualizados de la evaluación de riesgos.
- Resultados actualizados del tratamiento de riesgos.
Cláusula 9: Evaluación del desempeño
- Resultados de monitorización y métricas.
- Resultados de auditoría interna y programa de auditorías.
- Resultados de la revisión por la dirección.
Cláusula 10: Mejora
- No conformidades y acciones correctivas tomadas.
Todo lo demás, procedimientos operativos, instrucciones técnicas, registros de incidentes, logs de acceso, es recomendado o necesario para demostrar controles, pero la norma no prescribe un formato específico. Eso es una buena noticia: puedes adaptar el nivel de detalle a tu organización.
Cómo documentar cada control del Anexo A sin ahogarte en papel
El catálogo de 93 controles del Anexo A puede parecer abrumador. La clave es entender que no todos los controles requieren el mismo nivel de documentación.
Controles de proceso (como gestión de accesos, gestión de incidentes, gestión de cambios) necesitan:
- Un procedimiento que describa quién hace qué, cuándo y con qué autorización.
- Registros que demuestren que el proceso se ejecuta (tickets, actas, logs).
Controles técnicos (cifrado, gestión de vulnerabilidades, copias de seguridad) necesitan:
- Una política o decisión técnica documentada (qué algoritmo, qué frecuencia, qué alcance).
- Evidencia técnica de que está en marcha (configuración, reportes automáticos, resultados de pruebas).
Controles organizativos (revisiones periódicas, gestión de proveedores, formación) necesitan:
- El procedimiento que establece la frecuencia y responsable.
- El registro de que se hizo: acta de revisión, contrato con cláusulas de seguridad, evidencia de formación completada.
Una forma eficiente de organizar esto es la matriz de controles: una tabla donde cada fila es un control del Anexo A y las columnas recogen la política/procedimiento que lo cubre, el tipo de evidencia generada y el responsable del control. Esta matriz, bien mantenida, puede servir simultáneamente como referencia para el SGSI y como guía de auditoría interna.
Si estás construyendo la evaluación de riesgos ISO 27001 en paralelo, la selección de controles y su documentación deben estar alineadas: cada control seleccionado en el plan de tratamiento de riesgos debe aparecer en la SoA y tener su evidencia.
Lo que el auditor busca realmente en la documentación de controles
Entender la perspectiva del auditor ahorra muchas horas de trabajo innecesario. Un auditor de certificación ISO 27001 no busca perfección documental: busca evidencia de un sistema que funciona.
Preguntas que el auditor se hace ante cada control:
- ¿Existe la política? ¿Hay un documento que establezca la intención de la organización respecto a este control?
- ¿Está aprobada y vigente? ¿Tiene fecha de aprobación, propietario y fecha de próxima revisión?
- ¿La gente la conoce? ¿Hay evidencia de que el personal relevante la ha recibido o formado sobre ella?
- ¿Se aplica en la práctica? ¿Existen registros que demuestren la aplicación del control en el período auditado?
- ¿Hay métricas o revisión periódica? ¿Alguien revisa si el control funciona correctamente?
Si puedes responder afirmativamente a estas cinco preguntas para cada control que declaras como implantado en tu SoA, estás en buena posición para la auditoría. La guía sobre cómo preparar una auditoría NIS2 comparte lógica similar, porque los auditores de marcos de seguridad aplican el mismo enfoque: coherencia entre papel y práctica.
El hallazgo más frecuente en primera certificación no es la ausencia de un control técnico, es la ausencia de evidencia de un control que sí existe pero que nadie registró. Eso es evitable con un sistema de registro mínimo bien diseñado desde el principio.
Formatos que funcionan (y los que no)
Formatos que funcionan:
- Política + procedimiento en un solo documento breve. Para controles operativos sencillos, una política de dos páginas que incluya el procedimiento básico es más mantenible que un documento de veinte con secciones que nadie lee.
- Registros en herramientas existentes. Si vuestra gestión de accesos está en el directorio corporativo, los logs de ese directorio son vuestros registros de control de accesos. No hace falta crear un registro adicional.
- Plantillas mínimas para procesos repetibles. Para la revisión de accesos trimestral o la revisión anual de proveedores, una plantilla de acta con los campos mínimos garantiza que siempre quede evidencia, sin depender de la memoria de quien lo hace.
Formatos que no funcionan:
- Documentos descargados de internet sin adaptar. Los auditores reconocen las plantillas genéricas. Y lo que es peor, el equipo no las reconoce como suyas, así que no las aplica.
- Políticas sin propietario ni fecha de revisión. Una política sin fecha de última revisión es una política desactualizada por defecto.
- Procedimientos que describen un proceso ideal que nadie sigue. Si el procedimiento dice «el responsable de seguridad revisa los accesos mensualmente» y los registros muestran una única revisión en dos años, eso es una no conformidad mayor.
Mantenimiento: el reto real de la documentación ISO 27001
Muchas organizaciones llegan a la certificación con documentación razonablemente buena y la pierden en la primera auditoría de seguimiento porque nadie la actualizó. El mantenimiento es la parte del SGSI que más frecuentemente se subestima.
Tres mecanismos que funcionan en la práctica:
Revisión anual formalizada. Una vez al año, antes de la auditoría de vigilancia, el responsable de cada política/procedimiento revisa si sigue siendo exacta. Basta con un campo de «revisado por / fecha» y una acta mínima. La autoevaluación ISO 27001 puede servir como guía para estructurar esa revisión.
Actualización ante cambios relevantes. Cada vez que cambia un sistema, un proveedor o un proceso con impacto en seguridad, el responsable del control afectado actualiza la documentación. Si esto no está automatizado como paso del proceso de gestión de cambios, suele olvidarse.
Registro de no conformidades y acciones correctivas. Cada hallazgo de auditoría interna, incidente o desviación detectada debe quedar registrada con la acción correctiva tomada y su seguimiento. Esto no solo es un requisito de la cláusula 10, es la principal evidencia de que el SGSI mejora con el tiempo, que es precisamente lo que justifica la recertificación.
Para entender cómo encaja el mantenimiento del SGSI con el ciclo de cumplimiento más amplio, la guía sobre cómo mantener el cumplimiento NIS2 cubre principios aplicables igualmente a ISO 27001.
ISO 27001 y otros marcos: reutilizar documentación
Si tu organización trabaja con más de un marco, RGPD, NIS2, ENS, SOC 2, DORA, la documentación de controles ISO 27001 puede reutilizarse eficientemente.
La gestión de accesos documentada para ISO 27001 cubre también el control equivalente en NIS2. El análisis de riesgos del SGSI puede servir de base para la EIPD bajo RGPD si los procesos afectados incluyen datos personales. La política de cifrado cubre requisitos de varios marcos simultáneamente.
El truco es diseñar desde el inicio con un mapa de controles multi-framework: una capa que conecta cada control del Anexo A de ISO 27001 con los requisitos equivalentes de los otros marcos que aplican. Evita duplicar trabajo y reduce la superficie de no conformidades cuando llegan varios auditores en el mismo período.
La comparación ISO 27001 vs SOC 2 ayuda a entender qué controles se comparten y dónde hay divergencias relevantes cuando se trabaja con ambos marcos.
Qué ofrece Privalex en implementación ISO 27001
PrivaLex acompaña a equipos de compliance, CISOs y dirección en la implementación de ISO/IEC 27001 con foco en que la documentación sea útil desde el primer día: no carpetas de políticas que nadie aplica, sino controles documentados que aguantan la conversación con el auditor y que el equipo reconoce como suyos.
Cubrimos la evaluación de brechas inicial, el diseño del alcance y la SoA, la implementación de controles con sus evidencias y la preparación para la auditoría de certificación. También acompañamos en marcos complementarios, ENS, NIS2, ISO 27701, DORA, cuando la organización necesita cubrir más de un estándar simultáneamente.
Si quieres empezar con una valoración de tu situación actual, accede a la evaluación de riesgo gratuita. Para alinear alcance y plan con tu equipo, reserva una sesión estratégica.
Conclusión
Documentar los controles ISO 27001 no es un ejercicio de redacción, es un ejercicio de coherencia entre lo que la organización decide, lo que el equipo hace y lo que queda registrado. Cuanto antes se diseña esa coherencia, menos retrabajo hay antes de la auditoría y más sostenible resulta el SGSI en los ciclos de vigilancia y recertificación.
Preguntas Frecuentes
La norma no fija un número de documentos. Exige información documentada en puntos concretos de las cláusulas 4 a 10: alcance, política, metodología de riesgos, SoA, resultados de auditoría interna y revisión por la dirección, entre otros. Para los controles del Anexo A, la exigencia es poder demostrar que existen y funcionan, no necesariamente con un procedimiento específico para cada uno.
No todos los controles tienen que aplicar. Los que se excluyen deben justificarse en la SoA. Los que sí aplican deben estar respaldados por alguna evidencia, no necesariamente un procedimiento propio, puede ser un registro técnico, una configuración documentada o una referencia a una herramienta existente.
La SoA es el documento que recoge para cada control del Anexo A si aplica, si está implantado y qué evidencia lo sustenta. Debe ser aprobada formalmente por la dirección o el responsable del SGSI con autoridad suficiente. Es uno de los documentos que el auditor solicita en las primeras horas de la auditoría de certificación.
Como mínimo, una revisión anual formalizada de todas las políticas y procedimientos. Adicionalmente, actualización inmediata cuando cambia el proceso, el sistema o el proveedor que el control cubre. Los registros (evidencias de que el control funciona) se generan de forma continua en la operación, no son documentos que se actualicen periódicamente, sino trazas que se acumulan.
En gran medida sí. Los controles del Anexo A de ISO 27001 se solapan con muchos requisitos de NIS2 y ENS. Con un mapa de controles multi-framework bien diseñado, la documentación y evidencias de ISO 27001 cubren también los requisitos equivalentes de otros marcos, evitando duplicar trabajo. Las diferencias principales suelen estar en los requisitos específicos de notificación y en controles sectoriales.
La más frecuente es la brecha entre el procedimiento y la práctica real: el documento dice que se hace algo con una frecuencia o un proceso concreto, pero los registros muestran que no ocurre así. Le sigue la ausencia de registros para controles que sí funcionan técnicamente pero que nadie documentó. Ambas son evitables si el sistema de registro se diseña desde el inicio como parte del proceso, no como un paso adicional.