Mil brechas después, la divulgación va peor

Si solo miras cuántas brechas de datos hubo, te pierdes el problema que más duele: cuánto tarda una organización en decir que algo pasó. La cifra de incidentes puede subir o bajar, pero si la divulgación llega tarde, la ventana para responder se vuelve más corta, el daño regulatorio crece y la coordinación interna se rompe.

Ese es el punto de fondo detrás de este análisis: no basta con contar brechas, hay que medir el retraso en la divulgación. Cuando una empresa detecta un incidente hoy y lo comunica semanas o meses después, ya no estás ante un simple fallo de comunicación. Estás ante un riesgo operativo que afecta forense, legal, cumplimiento, atención al cliente y reputación, todo al mismo tiempo.

Qué significa realmente el retraso en la divulgación

La disclosure lag es el tiempo que pasa entre el momento en que una organización sabe, o debería saber, que sufrió una brecha y el momento en que la hace pública o notifica a las partes que corresponde. Ese retraso no siempre es malicia; a veces es caos interno, falta de evidencia clara, dependencia de terceros o una revisión legal que se alarga más de la cuenta.

El problema es que, para el negocio, el tiempo no se congela mientras el equipo debate. Los atacantes siguen usando credenciales robadas, los datos pueden circular en foros o mercados, y los clientes siguen tomando decisiones con información incompleta. Cuanto más tardas en divulgar, más difícil es contener el impacto real y más costoso resulta ordenar la respuesta.

Hay una diferencia clave entre detectar tarde y divulgar tarde. Puedes descubrir un incidente con retraso por limitaciones técnicas, pero si además tardas en comunicarlo después de confirmarlo, el riesgo se multiplica. Ahí ya no hablamos solo de seguridad; hablamos de gobernanza.

Por qué esto importa más que la cifra total de brechas

La cantidad total de incidentes sirve para medir tendencia, pero no te dice si las organizaciones están reaccionando mejor. Un mundo con mil brechas y divulgación rápida puede ser menos dañino que otro con menos eventos, pero con semanas de silencio por cada caso.

Troy Hunt viene observando este patrón en su trabajo con datos de brechas públicas, y su tesis es clara: la divulgación está empeorando. No necesitas coincidir con cada detalle para ver el punto central. Si el retraso aumenta, la utilidad de la notificación baja, porque el usuario, el regulador y el equipo interno reciben la noticia cuando ya perdieron parte de la capacidad de actuar.

En términos prácticos, una divulgación tardía afecta tres cosas a la vez: la respuesta técnica, el cumplimiento y la gestión de riesgo. Y eso pega distinto según el tamaño de la empresa, pero pega en todas.

Qué se rompe cuando divulgas tarde

El primer daño es operativo. Si el equipo de seguridad no tiene una línea de tiempo clara, no puede saber qué sistemas aislar, qué credenciales rotar ni qué logs preservar. El retraso también hace más difícil reconstruir la secuencia de eventos, porque los registros se sobrescriben, los proveedores cambian y la memoria humana se degrada.

El segundo daño es legal y regulatorio. En muchas jurisdicciones, la notificación tiene plazos concretos. El GDPR, por ejemplo, exige notificar ciertas brechas a la autoridad competente en hasta 72 horas, según la guía oficial del European Data Protection Board: https://edpb.europa.eu/our-work-tools/our-documents/guidelines_en. En Estados Unidos, varios estados tienen reglas propias y sectores regulados como salud o finanzas tienen obligaciones adicionales.

El tercer daño es de confianza. Cuando el usuario se entera por filtraciones, prensa o un tercero, ya no ve a la empresa como fuente confiable. Y eso no se arregla con un comunicado elegante. Se arregla con procesos que permitan informar rápido, con precisión suficiente y sin esconder el problema.

La cadena de impacto en una empresa digital

Piensa en una secuencia simple:

1. Se detecta actividad sospechosa en una cuenta administrativa.
2. El equipo no confirma el alcance durante varios días.
3. Legal pide más evidencia antes de notificar.
4. El proveedor afectado responde tarde.
5. La brecha se publica cuando ya hay exposición en canales externos.

Cada paso añade horas o días. En conjunto, el retraso convierte un incidente manejable en una crisis de coordinación. No porque la brecha sea más grande, sino porque la organización tarda demasiado en aceptar que debe actuar con información incompleta.

Aquí hay una regla útil: si tu proceso exige certeza absoluta antes de comunicar, probablemente estás diseñando para el tribunal, no para la respuesta. Y en seguridad, esperar certeza total suele ser una mala apuesta.

Lo que muestran los datos públicos de brechas

La discusión sobre disclosure lag gana fuerza cuando ves cómo se comportan los datos públicos. Troy Hunt analiza brechas agregadas en Have I Been Pwned y, más allá de la cifra acumulada, insiste en que el tiempo entre incidente y divulgación no mejora al ritmo que debería. El resultado es un entorno donde los usuarios se enteran tarde y los equipos defensivos pierden margen.

No hace falta convertir esto en una guerra de métricas. Basta con observar que muchas brechas siguen apareciendo meses o años después del compromiso original. Eso pasa porque algunas organizaciones detectan tarde, otras negocian internamente antes de publicar, y otras dependen de terceros que no entregan evidencia rápida.

La lectura correcta no es “hay muchas brechas”. La lectura útil es “la visibilidad del riesgo llega tarde”. Y cuando la visibilidad llega tarde, la gestión de riesgo se vuelve reactiva en lugar de preventiva.

En Latinoamérica, este problema se siente todavía más porque muchas empresas operan con equipos pequeños, proveedores múltiples y procesos de crisis poco practicados. A eso súmale marcos regulatorios que cambian por país y tendrás una mezcla difícil de manejar si no hay preparación previa.

El caso de Ecuador y la región

En Ecuador, como en otros países de la región, el reto no es solo jurídico. También es operativo. Muchas organizaciones tienen inventarios incompletos, poca telemetría centralizada y dependencias con proveedores que alojan datos fuera del país. Cuando pasa una brecha, el primer obstáculo no es redactar el aviso, sino entender qué datos se vieron afectados y a quién impacta.

Si tu empresa trabaja con clientes en varios países de LatAm, el retraso se vuelve más complejo. Puedes tener obligaciones distintas para usuarios en Colombia, México, Chile o la Unión Europea. Sin una matriz de incidentes y privacidad por jurisdicción, la divulgación termina dependiendo de improvisación y no de un criterio consistente.

Por eso, medir solo brechas no alcanza. Necesitas medir tiempos de detección, tiempos de contención y tiempos de notificación. Si no los mides, no los mejoras.

Cómo reducir el disclosure lag sin improvisar

No necesitas un programa perfecto para mejorar. Necesitas un flujo que aguante presión. La clave está en decidir de antemano quién evalúa, quién aprueba, quién notifica y con qué información mínima. Si eso se define durante la crisis, ya vas tarde.

Empieza por separar tres decisiones: si hubo incidente, si hubo exposición de datos y si ya toca notificar. Esas decisiones no siempre ocurren al mismo tiempo. A veces sabes que hubo acceso no autorizado pero todavía no sabes si hubo extracción. Aun así, el reloj regulatorio puede estar corriendo.

También conviene trabajar con plantillas. No para mentir, sino para evitar empezar desde cero. Un aviso inicial puede reconocer el incidente, explicar el alcance provisional y prometer actualizaciones. Eso es más útil que esperar dos semanas para publicar un comunicado “completo” que llega cuando el daño ya creció.

Un flujo mínimo que sí puedes operar

1. Detecta y registra: guarda hora, sistema afectado, usuario o cuenta comprometida y fuente de alerta.
2. Clasifica en 30 a 60 minutos: decide si es un evento de seguridad, incidente o brecha probable.
3. Preserva evidencia: congela logs críticos y accesos relevantes antes de que roten.
4. Activa legal y privacidad: revisa jurisdicciones, contratos y obligaciones de notificación.
5. Redacta un aviso inicial: usa hechos confirmados, no hipótesis.
6. Define cadencia de actualización: por ejemplo, cada 24 o 48 horas mientras haya novedades.

Ese flujo no elimina la incertidumbre, pero evita que la incertidumbre paralice todo. Y eso ya mejora mucho frente al escenario típico de correos cruzados y reuniones infinitas.

Qué debe tener tu tablero de crisis

Un tablero útil no necesita adornos. Necesita cinco campos que cualquiera pueda leer rápido:

• hora de detección
• hora estimada de inicio
• sistemas afectados
• datos potencialmente expuestos
• estado de notificación

Si tu tablero no responde esas preguntas, tienes un mural bonito, no una herramienta de decisión. Y si dependes de una sola persona para mantenerlo, también tienes un punto único de fallo.

La práctica más sana es hacer simulacros. No uno al año para cumplir, sino varios ejercicios cortos con escenarios distintos: robo de credenciales, ransomware con exfiltración, fuga por proveedor SaaS y publicación de datos en un repositorio público. Cada escenario te muestra un cuello de botella distinto.

Cumplimiento, riesgo y reputación no se pueden separar

El retraso en la divulgación no es solo una falla de comunicación. Es un síntoma de que la empresa no integró seguridad, legal, privacidad y negocio en un mismo proceso de decisión. Cuando cada área trabaja por su lado, la notificación se vuelve un trámite al final, no una parte central de la respuesta.

En cumplimiento, el costo es obvio: multas, auditorías, requerimientos y conflictos con reguladores. En riesgo, el costo es más silencioso: más tiempo de exposición, más cuentas comprometidas y más probabilidad de fraude posterior. En reputación, el costo puede durar años, porque la gente recuerda más el silencio que el incidente técnico.

Si quieres medir madurez real, no preguntes solo cuántas brechas tuvo la empresa. Pregunta cuánto tardó en saberlo, cuánto tardó en contenerlo y cuánto tardó en decirlo. Esas tres respuestas te dicen mucho más sobre el estado de la organización.

Métricas que sí conviene seguir

Puedes empezar con estas métricas internas:

• MTTD: tiempo medio de detección.
• MTTC: tiempo medio de contención.
• Tiempo a notificación: desde confirmación razonable hasta aviso.
• Tiempo a primera actualización: cuánto tardas en informar cambios relevantes.
• Porcentaje de incidentes con línea de tiempo completa: calidad de tu evidencia.

No necesitas un dashboard sofisticado para arrancar. Una hoja controlada por el equipo de respuesta ya sirve, siempre que tenga dueño, fecha y criterio común. Lo que no sirve es depender de memoria o de hilos de correo dispersos.

Tabla resumen

La lección de fondo es simple: una brecha no termina cuando la detectas, termina cuando la entiendes, la contienes y la comunicas con suficiente rapidez. Si una organización tarda demasiado en divulgar, no solo llega tarde al aviso; llega tarde a todo lo demás.

Y eso, en seguridad digital, suele salir caro dos veces: primero por el incidente, después por la forma en que se contó.