El patrón se repite. Una consultora entregó un juego de documentos, la empresa consiguió el certificado, y todo el mundo pasó a lo siguiente. Luego la persona que llevaba el tema cambió de puesto o se fue, los sistemas evolucionaron, y las evidencias dejaron de describir lo que la empresa hace de verdad. Nadie decidió abandonar la ISO 27001; simplemente dejó de operarse. Y ahora la auditoría de seguimiento está a unas semanas. Si algo de esto te suena, este es el orden para salir del paso.
Cómo saber si tu proyecto ISO está parado (y no solo "en pausa")
Hay una diferencia entre un proyecto en pausa y uno parado. Está parado si se cumplen varias de estas señales:
- La persona que era responsable del SGSI ya no está, o ya no se ocupa.
- Las evidencias (revisiones de accesos, registros, formación) llevan meses sin generarse.
- No se ha hecho la auditoría interna de este ciclo, ni la revisión por la dirección.
- Los sistemas han cambiado —nuevas herramientas, nueva infraestructura— y la documentación no lo refleja.
- El análisis de riesgos y la declaración de aplicabilidad describen una empresa que ya no existe.
Con la auditoría de seguimiento cerca, esto no es una pausa: es un certificado en riesgo. Nombrarlo con precisión es el primer paso para arreglarlo.
Qué pasa si llegas así a la auditoría de seguimiento
El certificado ISO 27001 no es un sello permanente. Sigue un ciclo de tres años: auditorías de seguimiento anuales en los años uno y dos, y una recertificación completa en el tercero. La auditoría de seguimiento no vuelve a revisarlo todo, pero sí comprueba que el sistema de gestión se ha seguido operando: que hay auditoría interna, revisión por la dirección, tratamiento de riesgos y evidencias recientes. Esa distinción entre un control documentado y uno operado es justo lo que comprueba una auditoría de certificación.
Si el auditor encuentra que el SGSI ha dejado de funcionar, el resultado son no conformidades. Una no conformidad menor se resuelve con un plan de acciones correctivas y un plazo. Una no conformidad mayor —o varias— puede llevar a la suspensión del certificado hasta que se subsane. No es lo habitual llegar a la retirada, pero la suspensión ya es suficiente problema: un certificado suspendido no sirve para el cliente o el pliego que te lo exigía.
Qué se puede salvar y qué hay que reconstruir
La buena noticia es que rara vez hay que rehacerlo todo. Lo que suele conservarse:
- El alcance del SGSI, si el negocio no ha cambiado radicalmente.
- La declaración de aplicabilidad, como punto de partida a revisar, no a reescribir.
- Las políticas base, aunque necesiten actualizarse.
Lo que suele haber caducado:
- Las evidencias: son lo primero que decae, porque dependen de una actividad continua que se detuvo.
- El análisis de riesgos, si los sistemas han cambiado.
- Los registros obligatorios del ciclo: auditoría interna, revisión por la dirección, acciones correctivas del año anterior.
El orden de reconstrucción cuando la auditoría está cerca
Con la fecha encima, la prioridad la marca lo que el auditor va a comprobar, no lo que sería ideal:
- Cierra los registros obligatorios del ciclo: auditoría interna, revisión por la dirección y seguimiento de las no conformidades de la auditoría anterior.
- Actualiza el análisis de riesgos y la declaración de aplicabilidad para que describan los sistemas actuales.
- Regenera evidencias de los controles de mayor riesgo primero: accesos, copias de seguridad, gestión de vulnerabilidades.
- Documenta los cambios de sistemas que se produjeron durante el parón.
Y una nota de honestidad: no todo se puede reconstruir en unas semanas, y las evidencias no se fabrican hacia atrás. Una auditoría interna hecha ayer no demuestra que el sistema funcionara hace seis meses. Lo defendible es llegar con el sistema ya operando de nuevo, un plan de acciones correctivas creíble y la trazabilidad de lo que se ha recuperado. Si el hueco es demasiado grande para la fecha, es mejor hablar con la entidad de certificación antes que fingir.
Por qué se paran los proyectos (y cómo no volver a pararse)
La causa casi nunca es la calidad del trabajo inicial. El modelo de entrega es el problema: un proyecto de certificación tiene un principio y un final —documentos entregados, certificado conseguido—, pero un SGSI no termina el día del certificado. Las cláusulas 4 a 10 de la norma describen una actividad continua, y esa actividad necesita que alguien la opere cada mes. Cuando ese alguien depende de una única persona con otras diez prioridades, el sistema se para en cuanto esa persona cambia de foco.
Ni el consultor ni el auditor son el problema: cada uno hizo su parte. El hueco está entre el certificado y la operación diaria, y ese hueco es estructural en cualquier modelo que trate la ISO como un proyecto en lugar de como una función. Si aún no tienes claro qué separa un sistema vivo de una carpeta de documentos, ayuda entender qué es un SGSI y en qué se diferencia de tener políticas.
Reactivar sin empezar de cero
Reactivar un proyecto parado es, sobre todo, volver a operar el SGSI y hacerlo en el orden que la auditoría impone. Qalea entra precisamente en ese hueco: evalúa qué se salva y qué hay que reconstruir, prioriza por lo que el auditor comprobará y, a partir de ahí, opera el sistema de forma continua para que no vuelva a pararse cuando cambie la persona de turno. No prometemos plazos de rescate que dependan del estado real ni de la entidad de certificación; lo primero es un diagnóstico honesto de si llegas a la fecha y con qué. Cuéntanos cuándo es tu auditoría de seguimiento y en qué estado está el sistema, y te decimos qué es realista.
