Notificación de brechas en 72 horas: cómo demostrar que el reloj se cumplió

Las 72 horas del artículo 33 del RGPD no son una cuenta atrás que empiece cuando el comité de crisis consigue reunirse. Tampoco esperan a que el equipo forense sepa exactamente qué datos han salido, cuántas personas están afectadas o quién ha dejado abierta la puerta. El plazo empieza cuando el responsable del tratamiento tiene conocimiento de una violación de datos personales y, desde ese momento, cada decisión debe poder reconstruirse.

Ahí está la diferencia entre notificar a tiempo y demostrar que se actuó a tiempo. Una autoridad de control no solo preguntará cuándo se envió el formulario. Querrá saber cuándo llegó el primer indicio, quién lo recibió, qué información estaba disponible entonces, qué evaluación se hizo, por qué se notificó o no se notificó y qué cambió después. La notificación es el resultado visible. La verdadera prueba está en el expediente que la sostiene.

El Comité Europeo de Protección de Datos (EDPB) ha convertido la gestión de las brechas en una cuestión de criterio documentado, no de adivinación retrospectiva. Para un CISO y un responsable de cumplimiento, eso cambia la prioridad: la organización necesita un mecanismo que capture señales tempranas, clasifique el incidente y preserve la trazabilidad incluso cuando los hechos todavía sean incompletos.

El reloj no empieza cuando la investigación termina

El artículo 33.1 del RGPD obliga al responsable del tratamiento a notificar una violación de datos personales a la autoridad de control competente “sin dilación indebida” y, cuando sea factible, dentro de las 72 horas siguientes a que haya tenido constancia de ella. Si la notificación se presenta después, debe explicar los motivos de la demora.

La expresión decisiva es “haber tenido constancia”. No equivale a conocer todos los detalles técnicos. Una organización puede tener conocimiento suficiente cuando recibe una alerta creíble de acceso no autorizado a una base de datos, cuando un proveedor confirma una intrusión que afecta a información de clientes o cuando sus propios registros revelan que un tercero ha consultado datos personales sin autorización. Esperar a cerrar el análisis forense para iniciar el cómputo es una estrategia cómoda, pero jurídicamente débil.

La definición de violación de datos personales del artículo 4.12 incluye la destrucción, pérdida o alteración accidental o ilícita, así como la comunicación o el acceso no autorizados a datos personales. Por tanto, no hace falta que exista una exfiltración demostrada. La indisponibilidad de datos también puede quedar dentro del perímetro si afecta a información personal y produce un riesgo para los derechos y libertades de las personas.

El primer problema operativo suele ser semántico. Los equipos de seguridad hablan de “incidentes”, “alertas”, “compromiso”, “evento de disponibilidad” o “falso positivo”. El RGPD pregunta otra cosa: ¿se ha producido una violación de datos personales? Un SIEM puede registrar miles de eventos sin relevancia normativa; un único correo enviado al destinatario equivocado puede activar los artículos 33 y 34.

La organización debería registrar dos momentos distintos:

• Primer indicio: cuándo apareció la señal y quién la recibió.
• Constancia de la violación: cuándo existían razones suficientes para concluir que se había producido una violación de datos personales.

Ambos momentos pueden coincidir, pero no siempre. Si no coinciden, el expediente debe explicar la diferencia. Una alerta automática a las 02:14 no demuestra por sí sola que la entidad tuviera constancia a esa hora si nadie la recibió, no estaba configurada para detectar datos personales o era materialmente ininteligible. Del mismo modo, que el responsable de seguridad leyera el aviso a las 09:00 no borra que el proveedor hubiera confirmado el acceso indebido a las 06:30.

La evaluación de riesgo no es una casilla de sí o no

El artículo 33.1 establece una excepción: no hay obligación de notificar a la autoridad cuando sea improbable que la violación constituya un riesgo para los derechos y libertades de las personas físicas. El artículo 34 introduce un umbral más exigente: la comunicación a los interesados procede cuando la violación entrañe un riesgo alto.

La estructura tiene tres niveles que conviene no mezclar:

1. Sin riesgo probable: puede no ser necesaria la notificación a la autoridad, pero el artículo 33.5 exige documentar la violación, sus efectos y las medidas correctivas.
2. Riesgo probable: debe notificarse a la autoridad conforme al artículo 33, aunque todavía no estén disponibles todos los detalles.
3. Riesgo alto: además de la autoridad, deben comunicarse los hechos a los interesados sin dilación indebida, salvo que concurra una excepción del artículo 34.3.

El error habitual consiste en traducir “no conocemos el impacto” por “no hay riesgo”. Es exactamente al revés: la incertidumbre sobre el contenido, la identidad de los afectados o la exposición puede elevar la necesidad de actuar, no eliminarla. La evaluación debe considerar, entre otros factores, el tipo de violación, la naturaleza, sensibilidad y volumen de los datos, la facilidad de identificación de las personas, la gravedad de las consecuencias y las características de los afectados.

Las directrices del EDPB sobre notificación de violaciones bajo el RGPD ofrecen una metodología basada en la probabilidad y la gravedad del perjuicio. No hace falta convertir cada incidente en una ecuación con falsa precisión. Sí hace falta justificar por qué el riesgo se consideró bajo, medio o alto y qué hechos sostienen esa valoración.

Un archivo con nombres y direcciones de correo no merece automáticamente la misma respuesta que una base de datos con información de salud, credenciales, datos financieros o identificadores que permiten cometer fraude. Pero tampoco existe una regla que permita despachar como “bajo riesgo” cualquier fichero que no contenga números de tarjeta. El contexto importa: una lista de pacientes, un registro de clientes de banca privada o las credenciales de acceso a una plataforma pueden causar daños muy distintos aunque todos sean, técnicamente, columnas en una tabla.

Qué debe contener una notificación que aún no lo sabe todo

El artículo 33.3 exige que la notificación describa, como mínimo, la naturaleza de la violación, incluyendo cuando sea posible las categorías y el número aproximado de interesados y registros afectados; el nombre y los datos de contacto del delegado de protección de datos u otro punto de contacto; las consecuencias probables; y las medidas adoptadas o propuestas para remediar la violación y mitigar sus efectos adversos.

“Cuando sea posible” es una válvula de continuidad operativa, no una invitación a esperar. El artículo 33.4 permite comunicar la información por fases cuando no sea posible facilitarla toda al mismo tiempo. La entidad puede presentar una primera notificación con datos provisionales y completarla después. Esa opción suele ser más sólida que enviar un informe perfecto cuando el plazo ya ha expirado.

Una primera comunicación razonable debería responder a cinco preguntas:

• ¿Qué ocurrió y cuándo se detectó?
• ¿Qué sistemas, procesos o proveedores están afectados?
• ¿Qué categorías de datos personales podrían estar implicadas?
• ¿Qué consecuencias son plausibles con la información disponible?
• ¿Qué contención se ha aplicado y qué información queda pendiente?

El lenguaje también importa. “Se ha producido un ataque sofisticado” describe la narrativa del atacante, no el impacto regulatorio. Es más útil indicar que una cuenta privilegiada fue utilizada para acceder a un repositorio que contenía identificadores de clientes, que el alcance sigue bajo investigación y que se revocaron las credenciales a las 10:35. La autoridad necesita hechos, no adjetivos.

La notificación debe tratarse como un documento vivo. Si la primera estimación hablaba de 2.000 registros y el análisis posterior identifica 25.000, el expediente debe conservar ambas cifras, explicar por qué cambió la estimación y registrar cuándo se comunicó la actualización. Borrar la versión inicial para “dejarlo limpio” destruye precisamente la trazabilidad que después se necesitará.

Artículo 34: comunicar a los afectados sin convertir la transparencia en un segundo incidente

La comunicación a los interesados prevista en el artículo 34 debe realizarse sin dilación indebida cuando la violación pueda entrañar un alto riesgo para sus derechos y libertades. Debe describir, en lenguaje claro y sencillo, la naturaleza de la violación y contener al menos la información y las medidas previstas en el artículo 33.3, letras b), c) y d): datos de contacto, consecuencias probables y medidas adoptadas o propuestas.

La comunicación no puede redactarse como una nota de relaciones públicas. “Hemos sufrido un incidente que podría afectar a algunos usuarios” oculta las decisiones que el interesado necesita tomar. Si existe riesgo de fraude, el mensaje debería explicar qué señales vigilar, cómo contactar con la entidad y qué credenciales deben cambiarse. Si se han visto expuestos datos de salud, el contenido debe permitir valorar las consecuencias concretas, con especial cuidado para no revelar más información sensible.

El artículo 34.3 contempla tres vías para no comunicar individualmente: cuando se hayan aplicado medidas técnicas y organizativas apropiadas, como el cifrado, que hagan ininteligibles los datos para personas no autorizadas; cuando se hayan tomado medidas posteriores que garanticen que ya no es probable que se materialice el alto riesgo; o cuando la comunicación individual exigiría un esfuerzo desproporcionado, en cuyo caso puede utilizarse una comunicación pública igualmente eficaz.

Ninguna de esas excepciones funciona como un comodín. El cifrado solo ayuda si las claves no han quedado comprometidas y el algoritmo y la gestión de claves ofrecen protección real. Revocar una sesión no elimina necesariamente el riesgo si los atacantes ya copiaron los datos. Y publicar un aviso en una página web no es “igualmente eficaz” si los interesados no tienen motivos razonables para visitar esa página.

La tensión es evidente: comunicar demasiado pronto puede generar confusión; comunicar demasiado tarde puede dejar a las personas sin capacidad de protegerse. La solución no es esperar a disponer de una narrativa definitiva, sino separar lo confirmado de lo que sigue en análisis y actualizar el mensaje si cambian los hechos.

El proveedor puede descubrir la brecha antes que el responsable

La cadena de notificación se complica cuando interviene un encargado del tratamiento. El artículo 28.3.f del RGPD exige que el contrato establezca que el encargado ayude al responsable, teniendo en cuenta la naturaleza del tratamiento, a garantizar el cumplimiento de las obligaciones relativas a la seguridad y a las notificaciones de violaciones. En la práctica, el proveedor debe informar al responsable sin dilación indebida cuando detecte una violación que afecte a datos tratados por cuenta de este.

El proveedor no decide por sí solo si el responsable notifica a la autoridad. La responsabilidad del artículo 33 recae en el responsable del tratamiento. Esa arquitectura explica por qué los contratos deberían fijar algo más preciso que “notificación inmediata”. Conviene definir un canal operativo permanente, un plazo de aviso inicial, la información mínima exigible, los responsables de escalado y el formato de las actualizaciones.

Un acuerdo que obliga al proveedor a avisar “en un plazo razonable” deja una zona gris precisamente donde el reloj corre. El contrato debería permitir una alerta preliminar aunque aún no se conozcan las categorías exactas de datos. También debería prohibir que el proveedor espere a terminar su investigación interna antes de alertar al responsable.

La entidad debe poder responder a preguntas incómodas: ¿cuándo recibió el primer aviso?, ¿qué versión del aviso recibió?, ¿quién valoró si contenía datos personales?, ¿qué nivel de servicio estaba activo fuera del horario laboral?, ¿qué ocurrió si el contacto principal no respondió? Si esas respuestas no aparecen en los registros, la dependencia del proveedor se convierte en un agujero de evidencia.

Para entidades financieras, este punto conecta directamente con DORA. El artículo 28 del Reglamento de Resiliencia Operativa Digital exige gestionar el riesgo de terceros proveedores de servicios TIC y mantener responsabilidades claras. DORA no sustituye al RGPD ni modifica el plazo del artículo 33, pero hace más difícil defender una arquitectura de proveedores que no permita saber qué ocurrió, cuándo y quién debía avisar. Una misma intrusión puede activar obligaciones de notificación de incidentes TIC bajo DORA y una evaluación de violación de datos bajo el RGPD; son análisis relacionados, pero no idénticos.

La evidencia que resiste una auditoría

El artículo 33.5 obliga al responsable a documentar cualquier violación de datos personales, incluidos los hechos relacionados, sus efectos y las medidas correctivas adoptadas. El registro no es un archivo para guardar la notificación enviada. Es la demostración de que la entidad aplicó el proceso de decisión exigible.

Un expediente defendible suele reunir, como mínimo, estas piezas:

• Línea temporal: alerta inicial, triage, confirmación, escalados, decisiones, notificación, actualizaciones y cierre.
• Descripción técnica: sistemas afectados, vectores conocidos o sospechados, cuentas implicadas, periodos de exposición y controles que funcionaron o fallaron.
• Análisis de datos: categorías de datos, número estimado de interesados y registros, ubicación, cifrado, seudonimización y accesibilidad real.
• Evaluación de riesgo: probabilidad, gravedad, escenarios de perjuicio y razones para notificar o no a la autoridad y a los interesados.
• Gobernanza: personas que participaron, autoridad para decidir, asesoramiento jurídico, intervención del delegado de protección de datos y comunicaciones con encargados.
• Medidas: contención, recuperación, rotación de credenciales, aislamiento, restauración, correcciones de configuración y acciones para evitar recurrencia.

La calidad de la evidencia depende de su contemporaneidad. Un acta redactada tres semanas después puede ser útil, pero no equivale a los registros generados durante la crisis. Los logs del SIEM, los tickets, los correos de escalado, los registros de acceso, las versiones de la notificación y las decisiones aprobadas deben preservarse con controles de integridad y una política de retención compatible con las obligaciones aplicables.

La organización también debe registrar los descartes. Si se concluye que un evento no fue una violación de datos personales, el expediente debe explicar por qué: por ejemplo, el acceso fue bloqueado antes de consultar el repositorio, los datos estaban correctamente cifrados y las claves no estuvieron expuestas, o la información no permitía identificar a personas. Un cierre con la frase “falso positivo” no es una evaluación; es una etiqueta.

Hay una distinción que suele perderse en los ejercicios de auditoría: demostrar que existía un procedimiento no demuestra que se ejecutó. El documento de política puede indicar que el CISO debe escalar cualquier posible brecha al DPO. La evidencia debe probar qué alerta llegó, a quién, en qué momento y qué hizo esa persona. Las políticas describen la intención. Los registros demuestran la conducta.

El diseño operativo: separar detección, decisión y comunicación

Una respuesta eficaz necesita tres circuitos coordinados. El primero es técnico: detectar, contener, preservar pruebas y estimar el alcance. El segundo es jurídico y de privacidad: determinar si existe una violación de datos personales, valorar el riesgo y aplicar los artículos 33 y 34. El tercero es ejecutivo: autorizar medidas que afecten a operaciones, clientes, proveedores y reputación.

Mezclarlos produce dos fallos opuestos. En uno, el equipo técnico decide que no hay brecha porque aún no ha confirmado la exfiltración. En otro, comunicación pública anuncia un alcance que la investigación todavía no puede sostener. La función de privacidad debe estar conectada desde el primer triage, no incorporarse cuando el informe forense ya está cerrado.

Una regla interna útil es activar un expediente de posible violación cuando se cumplen dos condiciones: existe un incidente de seguridad creíble y el activo afectado contiene o puede contener datos personales. A partir de ahí, se investiga mientras corre el plazo. Si el análisis concluye que no hubo violación o que el riesgo no exige notificación, esa conclusión queda documentada bajo el artículo 33.5.

El centro de operaciones de seguridad debería poder incluir en la alerta metadatos que ayuden a la evaluación: propietario del sistema, categorías de datos tratadas, clasificación de la información, proveedor implicado y criticidad del servicio. Sin ese contexto, la alerta técnica llega al DPO como una caja negra y consume horas en averiguar qué significa “objeto comprometido” para una persona real.

Los ejercicios de simulación deben probar algo más que la capacidad de aislar un servidor. Hay que medir cuánto tarda la entidad en identificar al responsable del tratamiento, localizar el contrato del encargado, estimar las categorías de datos, reunir al decisor y preparar una notificación incompleta pero utilizable. Un tabletop que termina con “el equipo legal revisará el formulario” no ha probado el artículo 33; ha probado que existe un formulario.

Cuando la notificación llega tarde

Una notificación fuera de las 72 horas no convierte automáticamente la respuesta en incumplimiento inevitable, pero obliga a explicar la demora. La calidad de esa explicación dependerá de la línea temporal y de la razonabilidad de las decisiones. Una investigación técnicamente compleja puede justificar parte del retraso si la entidad actuó con diligencia, preservó pruebas, escaló el asunto y notificó con la información disponible. La falta de un responsable de guardia o la espera de una aprobación corporativa indefinida son argumentos mucho más difíciles de defender.

La sanción potencial tampoco es una abstracción. El artículo 83.4.a incluye las obligaciones de los artículos 33 y 34 entre las infracciones que pueden alcanzar hasta 10 millones de euros o, tratándose de una empresa, hasta el 2 % del volumen de negocio total anual mundial del ejercicio financiero anterior, optándose por la cifra de mayor cuantía. La autoridad valorará los factores del artículo 83.2, como la naturaleza, gravedad y duración de la infracción, la intencionalidad o negligencia, las medidas adoptadas para paliar los daños, el grado de cooperación y la forma en que la autoridad tuvo conocimiento de la infracción.

El retraso no debe analizarse aislado del resto de la arquitectura. Si la entidad no aplicó medidas apropiadas de seguridad, puede entrar también en juego el artículo 32. Si no documentó la decisión, incumple el artículo 33.5 aunque finalmente no existiera obligación de notificar. Si ocultó información o no comunicó a los afectados cuando existía un alto riesgo, el problema deja de ser solo cronológico.

La transparencia tardía tampoco se arregla con una explicación retrospectiva demasiado perfecta. Las autoridades conocen la diferencia entre una decisión documentada en tiempo real y una reconstrucción elaborada después de recibir preguntas. El expediente debe conservar la incertidumbre existente en cada fase. La incertidumbre bien registrada es defendible; la certeza inventada, no.

La conexión con seguridad, gobernanza y privacidad desde el diseño

La notificación es el último eslabón de una cadena que empieza mucho antes del incidente. El artículo 32 exige medidas técnicas y organizativas apropiadas al riesgo, incluyendo, entre otras, cifrado y seudonimización, capacidad de garantizar la confidencialidad, integridad, disponibilidad y resiliencia permanentes, capacidad de restaurar la disponibilidad y el acceso de forma oportuna, y un proceso de verificación, evaluación y valoración regular de la eficacia de las medidas.

Una investigación de brecha debe desembocar en acciones verificables contra esas obligaciones. “Formar al personal” puede ser parte de la respuesta, pero no explica qué control falló. Es más útil indicar que una exportación de clientes podía descargarse sin doble aprobación, que los logs de acceso se retenían durante siete días cuando el tiempo de detección medio era superior, o que el proveedor no alertaba de accesos masivos fuera del horario habitual. Cada hallazgo debe asociarse a un propietario, una fecha objetivo y una prueba de cierre.

El artículo 25 sobre protección de datos desde el diseño y por defecto también tiene una dimensión práctica. Si una aplicación permite que todos los administradores consulten todos los expedientes, la brecha no se resuelve únicamente cambiando una contraseña. Puede exigir rediseñar los permisos, reducir la exposición por defecto, separar funciones y limitar la cantidad de datos accesibles en cada operación.

Para un CISO, el aprendizaje más incómodo es que la velocidad de notificación depende de la calidad del inventario de datos. Si nadie sabe qué aplicaciones procesan datos de salud, qué proveedor aloja los identificadores o cuánto tiempo se conservan los registros, la evaluación de riesgo empieza con una búsqueda manual. Y cada hora dedicada a descubrir el mapa es una hora menos para decidir.

Una prueba sencilla para saber si la organización está preparada

Pregunta a tres personas distintas —el responsable de SOC, el DPO y el responsable de continuidad— qué ocurrió en una brecha hipotética detectada un viernes a las 18:20. Si ofrecen tres versiones incompatibles del momento de conocimiento, del responsable de decidir y de los datos afectados, la entidad no tiene un problema de redacción. Tiene un problema de gobierno.

La preparación real se puede comprobar con evidencias concretas:

• Un canal de escalado operativo que funcione fuera del horario laboral.
• Un registro que distinga alertas, incidentes confirmados y violaciones de datos personales.
• Un inventario actualizado de tratamientos, sistemas y encargados.
• Plantillas de notificación preparadas para información provisional y actualizaciones por fases.
• Contratos que obliguen a los proveedores a alertar sin esperar a terminar su investigación.
• Un método documentado para valorar riesgo bajo el artículo 33 y riesgo alto bajo el artículo 34.
• Pruebas de ejercicios en los que se haya medido el tiempo hasta la decisión, no solo el tiempo hasta la contención técnica.

El objetivo no es notificar cada alerta para cubrirse las espaldas. Esa práctica saturaría a la autoridad y diluiría el significado de una notificación. El objetivo es tomar decisiones proporcionales con información incompleta, preservar la evidencia y demostrar que la organización no confundió la ausencia de certeza con la ausencia de riesgo.

La conclusión que importa

Las 72 horas no se ganan acelerando el envío de un formulario en el último minuto. Se ganan antes: con un inventario de tratamientos que sirva en una crisis, contratos que no escondan al proveedor detrás de una frase ambigua, alertas que incorporen contexto de privacidad y un expediente que registre cada decisión mientras los hechos todavía están cambiando.

El artículo 33 exige notificar cuando existe un riesgo probable; el artículo 34 eleva el umbral cuando el riesgo es alto; el artículo 33.5 exige documentar incluso cuando no se notifica. Esa combinación deja poco espacio para la estrategia de “esperemos a saberlo todo”. El RGPD no exige omnisciencia. Exige diligencia, criterio y pruebas.

Para el CISO y el responsable de cumplimiento, la pregunta decisiva no es “¿enviamos la notificación en 72 horas?”. Es otra: “¿podemos reconstruir, minuto a minuto y con hechos, por qué actuamos como actuamos?”. Si la respuesta es no, el reloj no fue el único problema.