Mirar hacia atrás con perspectiva permite ver cómo la ciberseguridad ha condicionado, condiciona y condicionará el desarrollo de la sociedad, de la economía y de las personas. Desde arrancar un PC pulsando un botón a introducir un segundo factor con un token en ese arranque. Hoy todos hablamos con naturalidad de passphrases, de biometría o de passkeys. Y menos mal: nuestra información personal, la secreta, la financiera, o la de nuestras empresas, está detrás de un simple dato que se sabe, de algo que se tiene, o simplemente algo intrínseco a nuestra condición de individuo.
Si nuestro propio interés personal -o nuestra mera supervivencia- garantizan que habilitemos las medidas de seguridad a nuestro alcance, las organizaciones garantizan o intentan garantizar su ciberseguridad mediante normas y estándares. Esto no es nuevo: desde los 90 del siglo pasado vienen surgiendo iniciativas cuya finalidad es certificar la gestión de la ciberseguridad de las organizaciones. Instituciones internacionales gubernamentales y privadas han ido desarrollando y actualizando familias de normas, regulaciones y estándares, adaptándolas a los diferentes sectores empresariales y gubernamentales, al estado del arte de la tecnología, y por supuesto, al contexto de las amenazas. Sin embargo, en todo este tiempo, algo no ha cambiado: la certificación sigue siendo, para muchas organizaciones, un fin en sí mismo. Confundimos el certificado no con la garantía de nuestra ciberseguridad, sino con la garantía de que hemos aprobado un examen al que nos hemos presentado un día y a una hora concreta.
Tres posturas ante la certificación
Hay tantas lógicas de negocio como negocios, pero casi sin excepción, las organizaciones, sean públicas o privadas, tienden a situarse en uno de estos tres perfiles según el motivo real que las lleva a certificarse, y que más que la norma en sí es la que determina cómo evolucionará su seguridad:
- El sello como peaje. Es la postura más frecuente en el proveedor que necesita el ENS, ISO 27001 o NIS 2 como requisito contractual para entrar o renovar un concurso o no perder un contrato. Igual ocurre en el organismo que certifica sus sistemas en el ENS por mero cumplimiento normativo, o porque la Intervención General o un órgano superior lo reclama como condición para seguir operando un servicio o no bloquear la tramitación de un expediente. En ambos casos el patrón es el mismo: se invierte lo necesario para superar la auditoría, aunque la seguridad pasa a un segundo plano en el mismo minuto en que se emite la declaración de conformidad.
- El sello como llave de mercado. Un escalón por encima está la organización que entiende la certificación como condición de acceso a un ecosistema, no como un trámite puntual. Aquí ya hay más madurez: sin ENS o RGPD no hay forma de operar como proveedor de servicios para el sector público; sin ISO 27001 ciertos clientes ni siquiera abren el proceso de homologación de proveedores. Las administraciones, por su parte, empiezan a entender NIS2 no como una obligación aislada, sino como el marco que condiciona su capacidad de interoperar con otros organismos, administrar fondos europeos sujetos a controles de ciberseguridad, o mantener la confianza de la ciudadanía en sus servicios digitales. La diferencia con el perfil anterior es sutil pero importante: la certificación se vive como una inversión estratégica recurrente, no como un mal trago que hay que superar una vez.
- La mejora continua como cultura. Por último, están los que han interiorizado que el sistema de gestión de la seguridad de la información (SGSI) es una herramienta de gobierno, no un certificado más enmarcado en la recepción. Aquí el ciclo PDCA no es un requisito documental que se prepara antes de la auditoría; es, de verdad, cómo se toman las decisiones. Son las organizaciones donde el CISO tiene voz en el comité de dirección, donde los indicadores de seguridad se revisan con la misma disciplina que los financieros, y donde la certificación es una consecuencia del sistema, no su objetivo.
La conclusión que puede extraerse de estos tres patrones es sencilla: el nivel de madurez de una organización se mide, casi siempre, en la distancia entre lo que dice su Declaración de Aplicabilidad y lo que realmente ocurre el día después de la auditoría de certificación.
Los riesgos que la certificación no ve
Una certificación de conformidad de un SGSI es una fotografía. Certifica que, en el momento de la auditoría, existía un conjunto de controles razonablemente implementados frente a un catálogo de riesgos conocidos. Pero el panorama de amenazas no se detiene mientras el certificado cuelga de la pared.
Hay al menos cuatro frentes que la certificación, por su propia naturaleza, no cubre de forma dinámica:
- La cadena de suministro. Una cláusula contractual o un certificado del proveedor son buenos puntos de partida, pero no siempre se verifica en continuo la postura de seguridad real de cada proveedor crítico. El incidente de un subcontratado de tercer nivel puede tumbar toda la cadena sin que ningún control certificado se haya incumplido formalmente.
- La IA generativa y los nuevos vectores de fuga de información. Ningún SGSI certificado hace tres años contemplaba el uso masivo de asistentes de IA por parte de los empleados, con el riesgo de fuga de datos sensibles que eso implica. La norma evoluciona; la amenaza evoluciona más rápido.
- El ransomware como servicio y la doble extorsión. Disponer de copias de seguridad y de un plan de continuidad no demuestra que la recuperación sea viable bajo presión. Es necesario probar restauraciones, proteger las copias frente a credenciales comprometidas, validar tiempos de recuperación y ensayar la toma de decisiones ante el cifrado involuntario, la exfiltración y la extorsión simultáneos.
- La deuda técnica silenciosa. Sistemas heredados del que pueden llegar a depender muchos otros sistemas, quedan fuera de alcance en la declaración de aplicabilidad “porque se van a sustituir el año que viene” y que, cinco auditorías después siguen ahí, sin parchear y sin medidas compensatorias efectivas.
Ninguno de estos riesgos invalida la certificación. Simplemente demuestra que el compliance es una condición necesaria, pero no suficiente, para una gestión de la seguridad que de verdad proteja a la organización.
Haciendo trampas en el Solitario
Obtener una certificación siempre requiere esfuerzo, aunque siempre hay ciertos atajos que está en la decisión de la organización tomarlos. Estos atajos tienen una ventaja apreciable, ya que requieren mucho menos esfuerzo, pero relajan medidas de seguridad y obvian riesgos, dejando ciega a la gobernanza de la seguridad. Algunos de estos atajos son:
- Forzar artificialmente la bajada de categoría del sistema, dejando fuera del perímetro certificable aquellos activos, sistemas o procesos cuyas medidas de seguridad exigidas resultan incómodas o caras. Es un ejercicio de ingeniería documental: se redefine qué es “esencial” no en función de la realidad del negocio, sino en función del presupuesto disponible. El resultado es un certificado válido sobre el papel que protege una fracción de lo que la organización realmente necesita proteger.
- Gestionar la relación con el auditor en lugar de gestionar el riesgo: ocultar deliberadamente deficiencias, preparar evidencias de ejemplo que no reflejan la operativa habitual, o presentar como implantado un control que en realidad se activó la semana antes de la auditoría y se desactivará la semana después.
Esta práctica, más allá de su cuestionable ética, tiene una consecuencia que muchos subestiman: el riesgo no desaparece por no estar identificado y gestionado; simplemente deja de estar visible, hasta que se materializa en forma de incidente.
La postura que recomendamos
Nuestra recomendación, después de acompañar decenas de procesos de certificación en organismos públicos y empresas privadas, es tan simple de enunciar como exigente de ejecutar: usar la certificación como excusa, no como meta: aprovechar la disciplina que impone un marco normativo —ISO 27001, ENS, RGPD o NIS 2, o todos combinados, para instalar procesos de gestión de riesgos que sigan funcionando el día después de la auditoría.
El compliance es necesario: ordena responsabilidades, establece un lenguaje común, facilita la rendición de cuentas y aporta confianza a clientes, administraciones y otras partes interesadas. Pero pierde valor cuando se limita a superar una auditoría.
La madurez no debe medirse por el número de controles implantados ni por la cantidad de certificados, sino por la capacidad de la organización para conocer su exposición, priorizar recursos, verificar la eficacia de sus medidas y aceptar conscientemente el riesgo residual.
Cómo acompañamos este proceso desde Babel
En Babel llevamos más de una década ayudando a organizaciones públicas y privadas a transitar desde el compliance documental hacia la gestión real del riesgo. Nuestro papel no termina con la entrega de un plan de adecuación bien redactado: acompañamos a la organización durante su implantación, la asesoramos en la toma de decisiones y verificamos que las medidas definidas se aplican, se mantienen y continúan siendo eficaces. Asimismo, la apoyamos durante las auditorías y seguimos trabajando con ella para impulsar la mejora continua de su sistema de gestión. Todo ello para transformar aquella incómoda tarea de la gestión de la ciberseguridad en el primer socio estratégico del negocio y en el principal pilar de la confianza del ciudadano. Al final, la pregunta que debería hacerse cualquier organización no es ¿tenemos el certificado?, sino ¿seguiríamos mejorando la seguridad si nadie viniera a auditarnos? La respuesta a esa pregunta es la verdadera medida de la madurez en seguridad.