En breve: La ISO 27001:2022 exige por norma diez documentos obligatorios -alcance, política de seguridad, metodología y resultados del análisis de riesgos, Declaración de Aplicabilidad, objetivos, evidencia de competencias, resultados del seguimiento, informes de auditoría interna, revisión por la dirección y no conformidades- además de los registros que genere cada control del Anexo A que marques como aplicable.
¿Qué diferencia hay entre los documentos obligatorios y toda la documentación de un SGSI?
Cuando un cliente me pregunta cuánta documentación necesita para certificarse en ISO 27001:2022, la respuesta corta es: bastante menos de lo que teme, pero con un núcleo que no es negociable. La norma habla de "información documentada" para referirse a todo lo que hay que redactar, mantener y controlar dentro del sistema de gestión de seguridad de la información (SGSI). Dentro de ese universo hay un grupo reducido -diez puntos concretos del cuerpo de la norma- que se exige de forma explícita, cláusula por cláusula, y que cualquier auditor revisa antes que ningún otro papel.
Si todavía no tienes claro qué implica el estándar en su conjunto, te recomiendo empezar por esta guía completa de la ISO 27001:2022 antes de entrar en el detalle documental. Aquí me centro solo en la parte que suele generar más dudas en pymes: qué hay que tener escrito sí o sí, y qué se puede resolver con un registro sencillo.
¿Cuáles son los documentos obligatorios de la ISO 27001:2022? Checklist cláusula por cláusula
La política de seguridad de la información (cláusula 5.2) suele ser el primer documento que se redacta y el que marca el tono de todo lo demás; si quieres ver cómo enfocarla, tengo un artículo dedicado a la política de seguridad para ISO 27001 y ENS. A partir de ahí, esta es la lista completa que exige el cuerpo de la norma:
| Cláusula | Documento o registro obligatorio | Qué debe demostrar |
|---|---|---|
| 4.3 | Alcance del SGSI | Qué procesos, sedes, sistemas y activos entran dentro del sistema (y qué queda fuera, justificado) |
| 5.2 | Política de seguridad de la información | Compromiso de la dirección y marco de objetivos, aprobada y comunicada a la organización |
| 6.1.2 | Metodología de evaluación de riesgos y resultado del análisis | Cómo se identifican, analizan y valoran los riesgos, y el listado de riesgos resultante |
| 6.1.3 | Resultados del tratamiento de riesgos y Declaración de Aplicabilidad (SoA) | Qué controles del Anexo A aplican, cuáles se excluyen y por qué |
| 6.2 | Objetivos de seguridad de la información | Metas medibles, con responsable y plazo, coherentes con la política |
| 7.2 | Evidencia de la competencia del personal | Formación, titulación o experiencia de quienes gestionan el SGSI |
| 9.1 | Resultados del seguimiento, medición, análisis y evaluación | Que los indicadores del SGSI se miden de verdad, no solo se definen sobre el papel |
| 9.2 | Programa de auditoría interna e informes de resultados | Que el SGSI se audita por dentro antes de que llegue el auditor de certificación |
| 9.3 | Resultados de la revisión por la dirección | Que la alta dirección revisa el sistema y toma decisiones documentadas sobre él |
| 10.2 | No conformidades y acciones correctivas | Que los fallos detectados se registran, se corrigen y no se repiten |
Diez filas, diez documentos. Si tu SGSI puede enseñar esta tabla completa y actualizada, ya tienes cubierto el núcleo duro de la certificación. Lo que suele fallar no es la ausencia total de estos documentos, sino que estén desactualizados, que no coincidan entre sí (por ejemplo, un alcance que no cuadra con la política) o que existan "de nombre" pero nadie los use en el día a día.
¿Qué registros adicionales suele pedir el auditor aunque no aparezcan como "obligatorios"?
La lista anterior es la que exige el cuerpo de la norma de forma literal. Pero cada control del Anexo A que marques como aplicable en la Declaración de Aplicabilidad arrastra su propia evidencia. En la práctica, casi ningún auditor certifica un SGSI sin ver, como mínimo:
- Inventario de activos de información: qué datos, sistemas y equipos hay que proteger y quién es su responsable.
- Registro de incidentes de seguridad: qué ha pasado, cómo se ha gestionado y qué se ha aprendido.
- Registro de altas, bajas y cambios de accesos de usuarios a sistemas críticos.
- Evidencia de copias de seguridad y de las pruebas de restauración realizadas.
- Actas de formación y concienciación en seguridad del personal.
- Registro de proveedores críticos y de los acuerdos de confidencialidad firmados con ellos.
- Registro de cambios relevantes en sistemas o infraestructura.
Sobre las copias de seguridad, un criterio que uso con mis clientes y que cualquier auditor entiende a la primera es la regla 3-2-1: tres copias de los datos, en dos soportes distintos, con al menos una copia fuera de las instalaciones. Documentar que se aplica -y que se ha probado la restauración- vale más que cualquier párrafo teórico sobre "políticas de backup".
¿Cómo se relacionan estos documentos con el Anexo A y la Declaración de Aplicabilidad?
La Declaración de Aplicabilidad es el puente entre los diez documentos obligatorios del cuerpo de la norma y los 93 controles del Anexo A, agrupados en los cuatro temas de la edición 2022 -organizativos, personas, físicos y tecnológicos- frente a los 114 controles que tenía la versión de 2013. La SoA no es una lista libre ni un documento que se pueda copiar de una plantilla genérica: para cada control hay que justificar si aplica o no a tu organización y, si no aplica, explicar por qué. Es probablemente el documento donde más pymes tropiezan en la auditoría, porque las exclusiones aparecen sin argumento real detrás.
¿Cómo organizar y mantener bajo control esta documentación sin perder el hilo?
Con diez documentos obligatorios más los registros de control, la parte difícil no es escribir, es mantener. Algunas prácticas que funcionan bien en pymes con pocos recursos dedicados a esto:
- Un repositorio único (no cinco carpetas distintas ni versiones sueltas por correo) donde cualquier auditor pueda encontrar todo en minutos.
- Código y número de versión en cada documento, con un histórico breve de qué cambió y cuándo.
- Un responsable asignado por documento, aunque sea la misma persona para varios.
- Revisión planificada -al menos anual- y revisión adicional cuando cambie algo relevante: nuevo proveedor cloud, nueva sede, un incidente significativo o un cambio de organigrama.
- Diferenciar documentos (estables, se aprueban y cambian poco) de registros (evidencias que se acumulan con el tiempo, como logs o actas).
La revisión por la dirección (9.3) es el momento natural para repasar en bloque si esta documentación sigue reflejando la realidad de la organización, no solo la que existía cuando se hizo la implantación inicial.
¿Qué ocurre si falta alguno de estos documentos en la auditoría de certificación?
El auditor lo registra como no conformidad. Si el documento existe pero está incompleto, desactualizado o no coincide con otros documentos del sistema, suele ser una no conformidad menor: hay que presentar un plan de acción con plazo, y normalmente la certificación sigue adelante. Si el documento no existe directamente, o existe pero el sistema no funciona como dice el papel, la no conformidad puede ser mayor -y una mayor sin resolver bloquea la certificación hasta que se cierre-.
La forma más barata de evitar este escenario es hacer una revisión interna de esta checklist antes de la auditoría, no durante ella. Casi siempre sale más a cuenta dedicar una tarde a comparar la tabla de arriba con lo que realmente tienes escrito que descubrir el hueco delante del auditor.
Si prefieres que alguien con experiencia real en implantaciones y auditorías se encargue de dejar esta documentación lista, coherente y defendible, en mi servicio de consultoría ISO 27001 trabajo precisamente eso: que el SGSI de tu empresa no dependa de una plantilla descargada de internet, sino de documentos que reflejan cómo trabajáis de verdad.