Cuando una empresa pierde el control de datos personales, el reloj empieza a correr rápidamente. Según el RGPD del Reino Unido y de la UE, las normas de las 72 horas para brechas de datos del RGPD establecen un plazo firme para informar a los reguladores sobre lo ocurrido. Para las personas cuyos datos quedaron expuestos, esas normas también importan, porque determinan qué oyes, cuándo lo oyes y qué debes hacer a continuación.

Esta guía explica el proceso en lenguaje sencillo, tanto desde el lado de la empresa como desde el tuyo.

Cuándo empieza el reloj de las 72 horas

La ventana de 72 horas gira en torno a una sola idea: la toma de conocimiento. Según el artículo 33 del RGPD, un responsable del tratamiento debe notificar una brecha de datos personales a la autoridad de control competente en un plazo de 72 horas desde que tenga conocimiento de ella. En el Reino Unido, esa autoridad es la Oficina del Comisionado de Información (ICO). En la UE, es la autoridad de protección de datos del Estado miembro correspondiente.

Dos puntos suelen generar confusión:

  • El reloj empieza con la toma de conocimiento, no con el ataque. Puede que la brecha haya ocurrido días o semanas antes. El plazo corre desde que la organización tiene un grado razonable de certeza de que los datos personales se vieron comprometidos.
  • El plazo no es una pausa para investigar. Se espera que las organizaciones actúen con rapidez. Cuando aún no se dispone de todos los detalles, el enfoque habitual es notificar lo que se sabe y proporcionar información adicional por etapas.

Incumplir el plazo sin una justificación razonable puede ser en sí mismo una infracción del artículo 33, lo que expone al responsable del tratamiento a medidas de ejecución, según los comentarios jurídicos sobre la norma.

Una nota práctica: las 72 horas incluyen fines de semana y días festivos. Las brechas no esperan al horario de oficina, así que un plan de respuesta a incidentes probado importa más que una buena intención.

Qué deben comunicar las empresas al ICO y a las personas afectadas

Notificar al regulador y notificar a las personas son dos obligaciones distintas con detonantes diferentes.

Informar al ICO. Por lo general, se exige una notificación a menos que sea improbable que la brecha suponga un riesgo para los derechos y libertades de las personas. La notificación debe describir la naturaleza de la brecha, las categorías y el número aproximado de personas y registros afectados, las consecuencias probables y las medidas adoptadas o propuestas para afrontarla. También debe incluir los datos de contacto del contacto de protección de datos de la organización.

Informar a las personas. Cuando sea probable que una brecha suponga un riesgo alto para las personas, la organización también debe informar a las afectadas sin dilación indebida. Ese mensaje debe estar redactado en lenguaje claro y explicar qué ocurrió, cuáles son las consecuencias probables y qué medidas pueden tomar las personas para protegerse.

El umbral para contactar a las personas es más alto que el umbral para contactar al regulador. Los escaneos de pasaportes robados, los historiales médicos o los datos financieros suelen superarlo con holgura. Casos como la filtración de datos de pasaportes de LT Group por el ransomware Deadlock muestran cómo los documentos de identidad pueden acabar en manos de delincuentes, que es exactamente el tipo de exposición que apunta a un riesgo alto.

También se espera que las organizaciones mantengan un registro interno de cada brecha, incluidas aquellas que deciden no notificar, junto con la justificación.

Qué debes hacer si tus datos quedan expuestos

Un aviso de brecha puede parecer abstracto. Aquí tienes una lista de comprobación concreta que puedes seguir el mismo día.

  1. Cambia la contraseña afectada y cualquier otra que hayas reutilizado. Si la misma contraseña protege otras cuentas, cámbialas también. Usa una contraseña única para cada servicio, preferiblemente guardada en un gestor de contraseñas.
  2. Activa la autenticación multifactor. Siempre que sea posible, prefiere una aplicación de autenticación o una llave física antes que los mensajes de texto.
  3. Lee el aviso con atención. Anota qué tipos de datos estuvieron implicados: datos de contacto, documentos de identidad, información sanitaria o financiera. Esto te indica qué riesgos priorizar.
  4. Vigila tus cuentas. Revisa los extractos bancarios y de tarjetas y considera un servicio de monitorización de crédito si estuvieron implicados datos financieros o documentos de identidad.
  5. Desconfía de los contactos inesperados. Los correos electrónicos, mensajes de texto o llamadas que hagan referencia a la brecha pueden ser genuinos, o pueden ser estafas que la usan como gancho.
  6. Presenta una solicitud de acceso. Según el RGPD del Reino Unido y de la UE, puedes preguntar a una organización qué datos personales tiene sobre ti y, en muchos casos, cómo se están usando. Esto te ayuda a entender tu exposición real y crea un rastro documental.
  7. Conoce tu vía de reclamación. Si crees que la empresa gestionó mal el incidente, puedes plantearlo ante el ICO en el Reino Unido o ante tu autoridad nacional de protección de datos en la UE.

Por qué los datos robados alimentan estafas posteriores

La brecha inicial suele ser solo la primera etapa. Los datos robados tienen valor de reventa y de extorsión, y los atacantes los usan cada vez más para presionar directamente a las personas.

La cobertura del ataque de ransomware a AnMed y la estafa de extorsión a pacientes muestra cómo funciona esto: los informes sugirieron que los atacantes podrían haber usado datos robados de pacientes para llevar a cabo intentos de extorsión personalizados contra las personas a las que pertenecían. Los datos personales hacen que una amenaza parezca creíble, y por eso estos mensajes pueden ser tan eficaces.

Las filtraciones también pueden ser públicas. En el caso de ShinyHunters filtrando 8,8 TB de datos robados de One Medical, los datos se publicaron tras la presión de extorsión, lo que significa que cualquiera podría acceder potencialmente a ellos. Una vez que la información sale, puede usarse para phishing, suplantación de identidad y fraude dirigido mucho después de que el incidente original se haya olvidado.

Por eso importa la notificación rápida. Cuanto antes lo sepan las personas, antes podrán asegurar sus cuentas y reconocer una estafa por lo que es. Las organizaciones pequeñas tampoco están exentas, como ilustra el caso de ransomware de Jaipur: el ransomware no discrimina por el tamaño de la empresa, y un equipo sin personal de seguridad dedicado sigue necesitando un plan de respuesta.

Qué significa esto para ti

La ley te da una expectativa razonable de que una empresa informará al regulador en un plazo de 72 horas desde que tenga conocimiento de una brecha, y de que te informará directamente si el riesgo para ti es alto. No garantiza que tus datos estén seguros, y no puede deshacer una filtración. Tu propia respuesta es lo que limita el daño.

Sidiriges un negocio, trata las 72 horas como una restricción de planificación: sabe quién decide si una brecha es notificable, quién contacta al ICO y cómo llegarías rápidamente a los clientes afectados.

Puntos clave

  • El período de 72 horas empieza cuando una organización tiene conocimiento de una brecha, no cuando comenzó.
  • Debe informarse al ICO o a la autoridad de la UE a menos que sea improbable el riesgo para las personas; debe informarse a las personas cuando el riesgo es alto.
  • Cambia contraseñas, activa la autenticación multifactor y vigila tus cuentas en cuanto recibas un aviso.
  • Trata con cautela cualquier mensaje que mencione una brecha, ya que los delincuentes reutilizan datos robados para extorsión y phishing.
  • Usa tu derecho a solicitar tus datos para ver qué tiene una organización.

Entender las normas de las 72 horas para brechas de datos del RGPD te ayuda a juzgar si una empresa está actuando correctamente, pero tu mejor protección es actuar rápidamente tú mismo. Asegura tus cuentas hoy, mantente alerta ante estafas posteriores y lee la cobertura de AnMed y ShinyHunters anterior para ver cómo se malutilizan los datos filtrados en la práctica.