Las brechas se avisan cada vez más tarde

Durante años, muchas empresas trataron las brechas de datos como un problema de volumen: cuántos incidentes hubo, cuántos registros se expusieron, cuántos usuarios quedaron afectados. Ese enfoque sigue siendo útil, pero ya no alcanza. El dato que cambia la conversación es otro: las empresas no solo están sufriendo más brechas, también están tardando más en avisar.

Y eso no es un detalle administrativo. Cuando la notificación llega tarde, tu gestión de riesgo se desordena, el cumplimiento se vuelve más difícil y la respuesta a incidentes pierde valor. Si el reloj empieza a correr cuando la organización detecta el incidente, pero el aviso público sale semanas o meses después, tú ya trabajas con información vieja. Eso afecta a clientes, reguladores, equipos legales, soporte y seguridad al mismo tiempo.

Qué está empeorando realmente

El análisis de Troy Hunt sobre 1.000 brechas va al centro del problema: el retraso entre la fecha del incidente y la fecha de divulgación no está mejorando, está empeorando. No se trata solo de que haya más casos para mirar. Se trata de que, en promedio, el momento en que el mundo se entera llega cada vez más tarde. Esa diferencia cambia por completo cómo entiendes el riesgo.

Cuando una empresa tarda en avisar, tú no puedes asumir que el incidente sigue activo, pero tampoco puedes asumir que ya quedó resuelto. Quedas en una zona gris. Y esa zona gris puede durar días, semanas o meses. Para un equipo de seguridad, eso significa menos capacidad de reaccionar con contexto. Para cumplimiento, significa ventanas de notificación más tensas. Para negocio, significa más fricción con clientes y socios.

De “hubo una brecha” a “¿cuándo nos enteramos?”

La pregunta correcta ya no es solo si hubo una brecha. La pregunta útil es cuándo ocurrió, cuándo se detectó y cuándo se informó. Esas tres fechas no siempre coinciden, y cuando el gap crece, la historia cambia. Un incidente detectado en enero y divulgado en abril no tiene el mismo impacto operativo que uno divulgado al día siguiente.

Ese retraso puede deberse a varias causas: investigación interna, negociación con terceros, análisis forense, dudas sobre el alcance o estrategias legales. A veces hay razones legítimas. Pero desde el punto de vista del usuario afectado, el resultado es el mismo: llega tarde la oportunidad de cambiar contraseñas, vigilar movimientos sospechosos, activar alertas o congelar tarjetas si hubo datos financieros involucrados.

El problema no es solo técnico

Si tú trabajas en seguridad, sabes que una brecha no termina cuando cierras el ticket. Termina cuando entiendes el alcance, contienes el acceso, documentas lo ocurrido y decides cómo comunicarlo. El retraso en la divulgación muestra que muchas organizaciones todavía operan con una visión fragmentada: seguridad por un lado, legal por otro, comunicación corporativa por otro.

Eso genera decisiones lentas. Y las decisiones lentas son costosas en incident response. Un SOC puede aislar sistemas en horas, pero si el área legal pide revisar cada frase del comunicado durante semanas, el valor de la respuesta técnica se diluye. Por eso este tema no es solo de ciberseguridad. También es de gobernanza.

Por qué tardar en avisar cambia tu riesgo real

La divulgación tardía no solo molesta. Distorsiona métricas, complica el cumplimiento y empeora el daño potencial. Si una empresa sufrió una exposición de credenciales hace 90 días y recién avisa hoy, el atacante pudo haber usado esas credenciales durante todo ese tiempo. En otras palabras, el retraso amplifica la exposición inicial.

Además, cuando el aviso llega tarde, tú pierdes capacidad de correlación. Si en ese período hubo fraude, phishing, accesos no autorizados o movimientos anómalos, conectar los puntos se vuelve más difícil. La organización y el usuario quedan trabajando con una ventana de tiempo borrosa.

Riesgo operativo: el reloj importa

En seguridad, el tiempo es una variable de control. Cuanto antes detectas y comunicas, más opciones tienes para contener. Si una base de datos fue expuesta y los clientes se enteran tres meses después, ya no basta con pedir cambio de contraseña. Tal vez debas forzar MFA, revocar tokens, rotar llaves, revisar logs y abrir un canal de soporte específico.

Piensa en este ejemplo simple: una filtración de correos y contraseñas divulgada en 48 horas permite que el usuario actúe antes de que se reutilicen credenciales en otros servicios. La misma filtración divulgada después de 60 días puede llegar demasiado tarde, porque el atacante ya probó esas credenciales en banca, e-commerce o correo corporativo.

Riesgo de cumplimiento: no es solo legal, también operativo

Las leyes de privacidad y protección de datos suelen exigir notificación en plazos concretos o “sin demora indebida”. En la práctica, eso obliga a tener procesos maduros para clasificar incidentes rápido. Si no sabes con precisión qué pasó, el reloj de cumplimiento se convierte en una amenaza en sí misma.

Para equipos en LatAm, esto pega distinto según el país, pero el patrón es similar: más presión regulatoria, más expectativa de transparencia y más consecuencias reputacionales cuando el aviso llega tarde. En Ecuador, por ejemplo, el tratamiento de datos personales ya obliga a pensar en incidentes con más orden documental. No basta con reaccionar, hay que poder demostrar qué hiciste y cuándo lo hiciste.

Riesgo reputacional: el silencio cuesta más que el incidente

A veces la empresa cree que esperar reduce el impacto. En realidad, suele pasar lo contrario. Cuando el usuario descubre por terceros que sus datos estuvieron expuestos, la conversación cambia de “hubo un incidente” a “además me lo ocultaron”. Ese segundo golpe es el que más erosiona confianza.

Y la confianza, en productos digitales, es una capa de seguridad más. Si tú gestionas una fintech, un SaaS o una plataforma de salud, el usuario no solo evalúa la funcionalidad. Evalúa si puede confiar en que le avisarás a tiempo cuando algo salga mal.

Lo que deberías mirar en tu organización

Si quieres evaluar si tu empresa está lista para una brecha, no empieces por el comunicado. Empieza por el proceso. La mayoría de los retrasos no nacen en el texto final, sino en la cadena previa: detección, triage, validación, decisión y aprobación. Ahí es donde se pierden días.

Hay una diferencia grande entre tener un plan en papel y poder ejecutarlo con presión real. Muchos equipos dicen tener playbooks de incidentes, pero cuando llega el caso, nadie sabe quién aprueba, quién habla con clientes, quién notifica al regulador o quién confirma el alcance técnico. Ese vacío es el que alarga la divulgación.

Señales de que tu organización va tarde

Revisa si te suenan estas señales:

1. El equipo de seguridad detecta algo, pero legal se entera mucho después.
2. No hay una matriz clara de severidad que conecte incidente con obligación de notificación.
3. Los logs necesarios para forense no están centralizados o se retienen poco tiempo.
4. Cada comunicado se redacta desde cero, sin plantillas aprobadas.
5. El área de atención al cliente se entera por redes sociales antes que por canal interno.

Si varias de esas situaciones te resultan familiares, el problema no es solo de velocidad. Es de diseño organizacional. Un proceso lento casi siempre refleja una estructura que no fue pensada para incidentes reales.

Tabla: dónde se pierde más tiempo

Cómo reducir el disclosure lag sin improvisar

No necesitas prometer avisos instantáneos en todos los casos. Eso sería poco realista. Lo que sí necesitas es reducir el tiempo entre detección y decisión. Si esa parte se acorta, la divulgación mejora casi por arrastre. La clave está en preparar el camino antes del incidente.

Aquí hay un enfoque práctico que funciona mejor que depender de reuniones de emergencia improvisadas.

1. Define umbrales de notificación antes de la crisis

No esperes a discutir si un incidente “merece” aviso cuando ya estás bajo presión. Define umbrales por tipo de dato, alcance y probabilidad de explotación. Por ejemplo, credenciales expuestas, datos financieros, documentos de identidad o información de salud deberían activar rutas distintas.

Eso no elimina el juicio humano, pero reduce la discusión infinita. Si el equipo ya sabe qué casos disparan revisión legal urgente, qué casos requieren comunicación a clientes y qué casos se documentan internamente, ganas horas valiosas.

2. Une seguridad, legal y comunicación en un solo playbook

Un playbook útil no es un PDF bonito. Es una secuencia operativa con responsables, tiempos y criterios. Debe decir quién confirma el incidente, quién calcula el impacto, quién redacta, quién aprueba y quién publica. Si cada área tiene su propia versión del proceso, el retraso está casi garantizado.

Incluye también plantillas. No para copiar y pegar sin pensar, sino para no arrancar desde cero. Un borrador de notificación con campos variables acelera muchísimo la respuesta. Si además tienes mensajes preaprobados para distintos escenarios, el tiempo se reduce todavía más.

3. Mide el tiempo con números reales

Si no mides el disclosure lag, no puedes mejorarlo. Empieza con tres métricas simples:

• Tiempo desde detección hasta confirmación del incidente.
• Tiempo desde confirmación hasta decisión de notificar.
• Tiempo desde decisión hasta publicación o envío.

Con esas tres piezas puedes ver dónde se atasca el proceso. Muchas empresas descubren que no pierden tiempo en la redacción, sino en la espera de aprobaciones o en la búsqueda de evidencia técnica.

4. Practica simulacros con casos incómodos

No hagas solo ejercicios de ransomware genérico. Prueba escenarios donde el problema es ambigüedad: una base de datos expuesta por error, un proveedor comprometido, un bucket público con datos parciales, una cuenta privilegiada usada de forma sospechosa. Esos son los casos que realmente retrasan la notificación.

En cada simulacro, cronometra todo. Si el equipo tarda 6 horas en identificar la severidad, 2 días en decidir y 1 día más en redactar, ya sabes dónde intervenir. El objetivo no es tener una respuesta perfecta, sino una respuesta repetible.

Qué cambia para empresas en LatAm y Ecuador

En Latinoamérica, el reto suele ser doble: menos madurez operativa en algunas organizaciones y más presión por demostrar cumplimiento cuando el incidente ya explotó. Eso hace que la notificación tardía sea todavía más costosa, porque el margen para improvisar es pequeño.

Además, muchas empresas regionales operan con proveedores globales, nubes públicas y equipos distribuidos. Eso complica la atribución del incidente y alarga la investigación. Si dependes de terceros para confirmar qué pasó, tu proceso de aviso tiene que contemplar esa dependencia desde el inicio.

En Ecuador, como en otros mercados de la región, el punto crítico es tener trazabilidad. No solo importa que avises, importa que puedas demostrar por qué avisaste cuando avisaste, qué datos estaban en juego y qué medidas tomaste después. Si no tienes evidencia interna ordenada, el retraso en la notificación se vuelve un problema mucho más grande que el incidente original.

Qué deberían hacer los equipos de seguridad y compliance

• Revisar políticas de incident response con foco en tiempos, no solo en responsabilidades.
• Mapear qué datos tienen obligación de notificación más sensible.
• Alinear contratos con proveedores para exigir tiempos de respuesta y de información.
• Definir un canal único para incidentes que no dependa de chats dispersos.
• Guardar evidencia técnica desde el primer minuto, no al final.

Ese trabajo previo no evita todas las brechas. Pero sí evita que una brecha se convierta además en un problema de gestión tardía y desordenada.

Tabla resumen

La lectura de fondo es simple: una brecha no solo se mide por lo que expone, sino por cuánto tarda la organización en asumirla públicamente. Si tú gestionas seguridad o cumplimiento, no te conviene mirar solo el incidente. Te conviene mirar el retraso, porque ahí se está acumulando buena parte del riesgo real.

Para profundizar, puedes revisar la entrada original de Troy Hunt sobre el retraso en la divulgación y la documentación oficial de marcos de respuesta a incidentes de NIST, que sigue siendo una referencia útil para ordenar procesos: NIST Computer Security Incident Handling Guide. Si trabajas con obligaciones de privacidad y notificación, también vale la pena revisar la guía del regulador o autoridad de protección de datos de tu país.