Por qué el cumplimiento normativo no garantiza la seguridad real de un sistema

Es frecuente escuchar en los equipos de seguridad empresarial una conversación recurrente cuando se pregunta si un sistema es seguro. La respuesta que se obtiene habitualmente no aborda el estado real del sistema, sino que se centra en la auditoría: se menciona la certificación obtenida, el cumplimiento normativo alcanzado o la ausencia de hallazgos críticos en el reporte externo. Aunque estas afirmaciones son válidas desde una perspectiva administrativa, ninguna contesta la pregunta original sobre la seguridad operativa.

Cuando la seguridad se evalúa a partir de auditorías

Existe una confusión generalizada que asume que el cumplimiento normativo y la seguridad son sinónimos porque comparten vocabulario y, ocasionalmente, objetivos.

Cumplimiento

La demostración de que una organización satisface requisitos definidos externamente en un momento específico.

Seguridad

La capacidad real de un sistema para resistir, detectar y responder a amenazas activas.

Esta distinción deja de ser semántica cuando ocurre un incidente en una organización que mantiene todas sus certificaciones al día, revelando que la conformidad documental no equivale a inmunidad operativa.

Incidentes reales que muestran la brecha entre compliance y seguridad

La historia reciente ofrece ejemplos contundentes sobre esta dinámica:

SolarWinds (2020)

Distribuía software firmado digitalmente y operaba dentro de los estándares vigentes, pero el ataque a su cadena de suministro comprometió a agencias del gobierno federal de EE. UU. y a cientos de empresas privadas.

Change Healthcare (2021)

Procesaba pagos médicos con controles de cumplimiento activos antes de que un ransomware paralizara sus operaciones durante semanas.

Estos incidentes demuestran que el problema trasciende la negligencia individual o la mala fe para enraizarse en una cuestión estructural, donde las organizaciones confundieron el cumplimiento con la seguridad real.

El problema estructural de los estándares de seguridad

La razón de fondo radica en que los estándares de seguridad están diseñados con una lógica distinta a la de los atacantes. Un estándar se construye a partir de amenazas conocidas, prácticas consolidadas y consensos de industria que requieren tiempo para formalizarse, por lo que refleja inevitablemente el estado del problema en el pasado.

Por el contrario, un atacante no opera bajo esa restricción temporal, sino que trabaja con las vulnerabilidades que aparecen en el presente y los vectores que los marcos regulatorios todavía no han clasificado. Esta asimetría es estructural y consecuencia inevitable de cómo se producen los estándares, generando un riesgo cuando las organizaciones tratan el cumplimiento como si cerrara esa brecha cuando en realidad la asumen como aceptable.

Incentivos organizacionales que priorizan la auditoría sobre la seguridad

Esta dinámica se ve exacerbada por mecanismos internos que pocas organizaciones reconocen abiertamente, específicamente la tendencia de los equipos operativos a optimizar para la auditoría en lugar de para la seguridad.

Bajo presión, los equipos priorizan lo auditable porque una auditoría tiene fecha, criterios específicos y consecuencias directas si no se aprueba, mientras que la seguridad real no tiene fecha de entrega ni una métrica clara de éxito. En ese contexto, dedicar recursos a lo que tiene consecuencias visibles e inmediatas responde a una lógica organizacional racional, lo que resulta frecuentemente en documentación impecable sobre controles que en la práctica no funcionan como se describen.

Así, se crea evidencia de cumplimiento que refleja cómo debería operar el sistema, no cómo opera realmente.

Nuevos marcos regulatorios orientados a seguridad continua

Los marcos regulatorios más recientes están comenzando a abordar este problema de forma más directa al reconocer estas limitaciones:

NIST AI Risk Management Framework se aleja del modelo de certificación puntual para proponer una gestión del riesgo integrada al ciclo de desarrollo, funcionando como un proceso que acompaña al sistema durante toda su vida operativa.

Cyber Resilience Act europeo introduce obligaciones de seguridad que se extienden mientras el producto sigue en uso.

La diferencia con los marcos anteriores es relevante, ya que obligan a mantener capacidades de detección y respuesta activas, aunque ninguno de estos marcos resuelve el problema si la organización los trata meramente como un ejercicio de documentación, pues su valor depende completamente de cómo se implementan internamente.

Lo que separa a las organizaciones con seguridad real

Lo que diferencia a las organizaciones con seguridad real de las que tienen un cumplimiento bien gestionado es observable en la práctica operativa:

Capacidad de detección funcional. Las organizaciones maduras cuentan con detección que funciona en producción más allá de los escenarios que cubre el auditor.

Visibilidad sobre sistemas reales. Sus equipos tienen visibilidad sobre los sistemas reales en lugar de sobre la documentación de esos sistemas.

Transparencia interna. Registran hallazgos incómodos aunque no sea obligatorio reportarlos.

Respuestas técnicas. Cuando se les pregunta si el sistema es seguro, la respuesta habla del sistema técnico y no de los certificados.

El cumplimiento normativo es necesario pero no suficiente. Proporciona un marco de referencia y establece un mínimo común denominador, pero la seguridad real requiere ir más allá de la auditoría: implica construir capacidades técnicas que funcionen en producción, mantener visibilidad continua sobre el estado real de los sistemas y estar dispuesto a reconocer y abordar problemas antes de que se conviertan en incidentes.

Imagen generada con IA
© Copyright: Natalia Jaimes