El 40% de los proyectos de certificación que hemos visto desde fuera —proyectos que empezaron otras consultoras o que las propias empresas intentaron en solitario— no llegaron a la auditoría de certificación. No fracasaron por falta de recursos ni porque la empresa tuviera una seguridad especialmente precaria. Fracasaron por errores de enfoque que son totalmente evitables si sabes reconocerlos.
Estos son los cinco patrones que vemos repetirse.
Es el error más común y el que más caro sale. La empresa escribe políticas y procedimientos describiendo procesos ideales que nadie sigue. El resultado es un SGSI impecable sobre el papel que no tiene nada que ver con la realidad operativa de la organización.
El auditor no tarda en detectarlo. Pregunta al técnico de IT cómo gestiona los accesos: la respuesta no coincide con el procedimiento documentado. Pregunta al responsable de RRHH qué pasa cuando entra un empleado nuevo: mismo problema. Las no conformidades se acumulan.
El error viene de copiar plantillas genéricas sin adaptarlas. Las plantillas son un punto de partida, no el destino.
ISO 27001 exige el liderazgo y compromiso de la alta dirección. No es retórica: la norma dedica toda la cláusula 5 a esto. Cuando la dirección no está implicada de verdad —más allá de firmar un papel— el proyecto se convierte en un proyecto del responsable de IT que nadie más apoya.
Consecuencias prácticas: los otros departamentos no cooperan, los recursos prometidos nunca llegan, y cuando hay que tomar decisiones incómodas (restringir accesos, cambiar un proceso que lleva años igual) no hay nadie con autoridad para hacerlo.
Hemos visto proyectos paralizados durante meses porque el responsable del SGSI no podía conseguir que el equipo financiero actualizara sus controles sin la orden expresa del director general.
El análisis de riesgos es el núcleo del SGSI. Todo lo demás —los controles que se implementan, la inversión en seguridad, las prioridades— debería derivar de él. Cuando se hace deprisa para "completar el requisito", el resultado es una lista de riesgos genérica que podría ser de cualquier empresa y que no sirve de guía para nada.
El problema se detecta inmediatamente: si los controles seleccionados no están claramente vinculados a los riesgos identificados, el auditor lo ve. Y si el análisis no refleja los activos y procesos reales de la organización, tampoco tiene valor operativo.
Un buen análisis de riesgos lleva tiempo. Para una pyme de 20-50 personas, entre 2 y 4 semanas de trabajo real con los responsables de cada área. No hay atajos que funcionen.
Hay una diferencia enorme entre tener los documentos listos y tener los controles realmente implantados. Muchos proyectos llegan a la auditoría con políticas aprobadas pero sin evidencias de que se aplican: sin registros de acceso, sin logs de incidencias, sin actas de revisión por dirección.
ISO 27001 es una norma basada en evidencias. El auditor no valora lo que dices que haces; valora lo que puedes demostrar que haces. Si llevas tres meses con el SGSI activo y no tienes ni un registro de incidente, algo falla.
El periodo entre la aprobación de documentos y la auditoría de certificación —normalmente entre 3 y 6 meses— tiene que usarse para acumular evidencias: logs, actas, registros, resultados de auditorías internas.
ISO 27001 no es un proyecto de IT. Es un sistema de gestión que afecta a toda la organización: RRHH, legal, operaciones, finanzas. Asignarlo en exclusiva al técnico de IT —que además tiene que seguir gestionando la infraestructura— es una receta para el agotamiento y el abandono.
El resultado típico: el proyecto avanza bien los primeros dos meses, luego se ralentiza, luego se paraliza. La persona responsable está desbordada, el resto de la organización no entiende qué tiene que hacer, y los plazos se van corriendo indefinidamente.
ISO 27001 necesita un responsable con autoridad y tiempo dedicado, más la colaboración de los responsables de cada área. No funciona como proyecto paralelo de alguien que ya tiene el trabajo lleno.
¿Hay un patrón común?
Sí. En todos estos errores hay un denominador común: tratar ISO 27001 como un proyecto documental en vez de como un cambio organizativo. La certificación es el resultado de tener un sistema de gestión que funciona. No al revés.
Las empresas que se certifican con menos fricción son las que entienden esto desde el principio: el objetivo no es el certificado, es tener la seguridad de la información realmente bajo control. El certificado es la consecuencia.
"El SGSI tiene que describir la realidad de la empresa, no la que le gustaría tener. Los auditores llevan 20 años leyendo documentos ideales y reconocen al instante cuándo algo no se aplica."
Cuándo sí tiene sentido empezar
Un proyecto de certificación tiene condiciones mínimas para funcionar cuando:
- La dirección entiende el esfuerzo real y está comprometida con él
- Hay alguien con tiempo y autoridad para liderar el proyecto internamente
- La empresa tiene procesos mínimamente definidos sobre los que construir
- Hay una razón clara para certificarse: cliente que lo exige, licitación pública, estrategia de expansión
Si estas condiciones no se dan, lo más honesto —y lo que hacemos nosotros— es decirlo antes de empezar.
Los 5 errores
- Documentar lo que "debería ser" en vez de la realidad
- Empezar sin el respaldo explícito de dirección
- Tratar el análisis de riesgos como un trámite
- Subestimar el esfuerzo de implantación real
- Asignar el proyecto a una sola persona sin dedicación