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

La trampa de las 72 horas no está en el reloj. Está en la prueba.

Casi cualquier CISO o DPO europeo sabe recitar de memoria el art. 33.1 del GDPR: la violación de datos personales debe notificarse a la autoridad de control sin dilación indebida y, de ser posible, a más tardar 72 horas después de que el responsable tenga constancia de ella, salvo que sea improbable que entrañe un riesgo para los derechos y libertades de las personas físicas. El problema empieza justo después de esa frase. ¿Qué significa tener “constancia”? ¿Qué evidencia demuestra que el cronómetro arrancó el martes a las 09:17 y no el lunes a las 22:43? ¿Y qué haces cuando en las primeras 18 horas solo tienes logs confusos, un proveedor que no contesta y media organización preguntando si hay que activar crisis?

El Comité Europeo de Protección de Datos lleva años afinando ese punto, y con razón. Muchas organizaciones siguen tratando la notificación como un acto puntual: enviar el formulario a la autoridad y cruzar los dedos. Ese enfoque falla. La obligación real es bastante más incómoda: reconstruir una cadena de decisiones verificable desde el primer indicio hasta la notificación, y hacerlo de forma coherente con el art. 33 GDPR, la posible comunicación a interesados del art. 34, el principio de responsabilidad proactiva del art. 5.2 y la obligación general de aplicar medidas técnicas y organizativas apropiadas del art. 32.

Traducido al lenguaje que entienden auditoría, legal y reguladores: no basta con haber hecho algo razonable; tienes que poder demostrar qué sabías en cada momento, quién lo evaluó, qué hipótesis se descartaron y por qué la organización concluyó que había —o no— riesgo para los afectados. Si esa historia documental no existe, la discusión deja de ser sobre la brecha y pasa a ser sobre tu gobernanza. Y eso suele salir más caro.

La palabra que decide todo: “constancia”

El núcleo del art. 33.1 GDPR no es el plazo de 72 horas, sino el momento a partir del cual empieza a correr. El regulador no exige notificar a ciegas ante cualquier alerta técnica. Exige actuar cuando el responsable del tratamiento tiene un grado suficiente de conocimiento para concluir razonablemente que ha ocurrido una violación de seguridad que ocasiona la destrucción, pérdida, alteración, comunicación no autorizada o acceso no autorizado a datos personales, definición que aparece en el art. 4.12 GDPR.

Aquí está el matiz que muchas empresas gestionan mal: una anomalía no es todavía una violación de datos personales. Un SIEM que dispara una alerta, una cuenta comprometida o un bucket mal configurado pueden ser la antesala de una brecha… o no. El reloj no arranca porque exista ruido técnico. Arranca cuando, con la información disponible, la entidad sabe o debería saber que se ha producido una violación de datos personales.

Ese “debería saber” importa mucho. Si una entidad retrasa artificialmente la escalada interna, si trata una señal evidente como si fuera una simple incidencia IT, o si espera a tener certeza forense absoluta antes de mover ficha, se mete en arena movediza. El estándar europeo nunca ha sido “notifique cuando haya cerrado la investigación”. Es justo el contrario: notifique con la información disponible dentro del plazo y complete después. El art. 33.4 GDPR lo prevé de forma expresa: cuando no sea posible facilitar toda la información al mismo tiempo, podrá facilitarse de manera gradual sin más dilación indebida.

La consecuencia práctica es brutalmente simple. Tu organización necesita una definición operativa de “constancia” que no dependa del humor del día ni del departamento que levante primero la mano. Si no la tienes escrita, el reloj lo definirá la autoridad por ti cuando revise el expediente. Y nadie ha pedido nunca a un regulador que interprete a su favor una cronología desordenada.

Las 72 horas no se gestionan con heroicidades; se gestionan con hitos probatorios

Una notificación defendible se apoya en una línea temporal. No en una narrativa genérica del tipo “detectamos el incidente y activamos el protocolo”, sino en hitos con hora, responsable, evidencia y decisión. Si meses después te pide explicaciones una autoridad, un tribunal o incluso un cliente institucional, esa cronología es lo único que separa una gestión seria de una improvisación decorada con PowerPoint.

Los hitos mínimos suelen ser estos:

1. Detección inicial

Hora exacta de la alerta o del primer reporte. Fuente: SIEM, EDR, ticket de soporte, aviso de un empleado, notificación de un proveedor, correo del CERT, hallazgo de un investigador externo. Aquí no hace falta concluir nada todavía. Hace falta preservar el rastro: número de ticket, captura del evento, hash del log exportado, identidad del analista que lo recibió y sistema afectado.

2. Triage y calificación inicial

Momento en que el incidente deja de ser una mera anomalía técnica y entra en circuito de evaluación de brecha de datos. Debe constar quién tomó esa decisión y por qué. Ejemplo: “EDR confirma exfiltración desde repositorio con datos de clientes”; “proveedor SaaS confirma acceso no autorizado a tenant corporativo”; “se verifica envío erróneo de extractos a destinatarios incorrectos”. Este punto suele ser el verdadero candidato a “constancia” a efectos del art. 33.1.

3. Evaluación preliminar de riesgo

Aquí la organización analiza, aunque sea de forma imperfecta, cuatro variables: naturaleza de los datos, volumen aproximado, facilidad de identificación de los interesados y posibles consecuencias. Si el conjunto incluye datos financieros, credenciales, categorías especiales del art. 9 GDPR, datos de menores o combinaciones que faciliten fraude o suplantación, la probabilidad de riesgo sube de forma muy poco poética.

4. Decisión de notificar o no notificar

No basta con la conclusión. Hay que documentar la motivación. Si decides notificar, deja constancia de la hora de aprobación, de quién valida y del contenido mínimo disponible. Si decides no notificar porque consideras improbable el riesgo, el expediente debe explicar esa improbabilidad con hechos, no con deseos.

5. Envío a la autoridad

Conservar acuse de recibo, copia exacta del formulario remitido, anexos, versión enviada y si hubo comunicaciones posteriores. Parece obvio, pero demasiadas entidades no preservan el contenido exacto de la primera notificación y luego no pueden explicar divergencias entre versiones.

6. Actualizaciones y cierre

Si la información inicial era incompleta —casi siempre lo es— documenta cada ampliación. El art. 33.4 existe para eso. Lo que no admite es una primera notificación vacía seguida de días de silencio.

Este enfoque tiene una virtud: evita la discusión estéril sobre si la organización “llegó” o “no llegó” al plazo. La pregunta correcta es otra: ¿puede reconstruir de manera consistente cuándo adquirió conocimiento suficiente y qué hizo con ese conocimiento?

Qué debe contener la prueba documental, de verdad

El art. 33.5 GDPR obliga al responsable a documentar cualquier violación de la seguridad de los datos personales, incluidos los hechos relacionados, sus efectos y las medidas correctivas adoptadas. Ese registro debe permitir a la autoridad verificar el cumplimiento del artículo. Aquí no hay escapatoria semántica: la documentación no es opcional, y no se limita a las brechas notificadas. También alcanza a las que concluyes que no requieren notificación.

En la práctica, un expediente sólido debería incluir al menos ocho bloques de evidencia.

Registro de detección

Logs de sistemas, alertas SIEM/EDR, tickets, correos de escalado, actas de war room y cualquier artefacto que fije la primera señal y las acciones iniciales. Si usas herramientas que sobreescriben eventos o rotan registros rápidamente, exporta y sella copias en las primeras horas. Parece una obviedad; luego llega auditoría seis meses después y resulta que el log original ya no existe.

Clasificación del incidente

Debe verse el salto desde “incidente de seguridad” a “posible violación de datos personales”. Incluye la persona o función que lo decide: SOC lead, CISO, DPO, legal interno o comité de crisis. Lo sensato es que el procedimiento asigne esa responsabilidad por adelantado. Si no, la organización improvisa autoridad a mitad del incendio.

Mapa de datos afectados

No sirve decir “podrían estar implicados datos de clientes”. Hay que aterrizarlo: categorías de interesados, sistemas afectados, bases jurídicas asociadas, categorías de datos y, cuando sea posible, volumen aproximado. Si el repositorio contenía IBAN, DNI, direcciones, historiales de siniestros o documentación KYC, eso cambia por completo el análisis de riesgo. Lo mismo si los datos estaban cifrados de forma robusta y las claves no se vieron comprometidas.

Análisis de riesgo para los derechos y libertades

Este es el corazón del expediente. Debe conectar hechos con consecuencias plausibles: fraude, suplantación, pérdida de confidencialidad profesional, discriminación, daño reputacional, denegación de servicio, exposición de datos de salud, riesgo físico o social. El considerando 75 GDPR sigue siendo útil aquí porque enumera riesgos relevantes, y el considerando 85 recuerda que una violación puede ocasionar daños físicos, materiales o inmateriales. Si tu análisis solo dice “no se aprecia alto riesgo” sin más, no estás analizando nada.

Decisión sobre art. 33 y art. 34

Conviene separar dos preguntas. La primera: ¿hay que notificar a la autoridad por existir riesgo? Art. 33.1. La segunda: ¿hay que comunicar a los interesados por existir alto riesgo? Art. 34.1. Muchas empresas mezclan ambas y acaban con decisiones incoherentes. Es perfectamente posible notificar a la autoridad y no comunicar a interesados si el riesgo no llega a “alto”. También puede ocurrir lo contrario en un escenario muy excepcional que se detecte tarde y exija información urgente a afectados, aunque operativamente lo habitual es que la autoridad entre antes en escena.

Medidas técnicas y organizativas existentes

El art. 34.3.a GDPR prevé una excepción a la comunicación a interesados si el responsable había aplicado medidas técnicas y organizativas apropiadas y esas medidas, en particular el cifrado, hacen ininteligibles los datos para cualquier persona no autorizada. Ese “en particular” importa. Si vas a apoyarte en esa excepción, guarda evidencia de la arquitectura de cifrado, gestión de claves, alcance del cifrado y confirmación de que las claves no estuvieron expuestas. Decir “estaba cifrado” sin poder probar cómo y con qué control, en 2026, ya suena a broma interna.

Comunicaciones internas y externas

Borradores, aprobaciones, mensajes al proveedor, instrucciones a atención al cliente, FAQs, comunicaciones a aseguradora cibernética, notificaciones contractuales a clientes B2B. No por gusto documental, sino porque esas piezas muestran la coherencia de la respuesta. Si el call center informa de una brecha el lunes pero la empresa dice a la autoridad el miércoles que aún no tenía constancia, el problema deja de ser técnico.

Medidas correctivas y lecciones aprendidas

Contención, erradicación, restauración, reseteo de credenciales, revocación de tokens, segmentación, hardening, parcheo, monitorización reforzada, revisión de permisos, control de proveedores o cambios de proceso. La autoridad no solo mira el daño; mira si la organización fue capaz de reaccionar de forma proporcionada.

El error más común: confundir investigación forense con umbral legal

Hay un reflejo muy extendido en equipos de seguridad maduros: no afirmar nada hasta tener evidencia forense casi definitiva. Desde el punto de vista técnico, el instinto es comprensible. Desde el punto de vista del art. 33 GDPR, puede ser desastroso.

La norma no exige certeza absoluta. Exige una evaluación razonable dentro de un plazo breve. Esperar a tener número exacto de registros afectados, TTPs completas del atacante o trazabilidad perfecta de la exfiltración puede empujar a la organización fuera de plazo sin necesidad. El remedio está en separar dos capas de trabajo.

La primera capa es la decisión regulatoria temprana: con la información disponible, ¿es probable que se haya producido una violación de datos personales y que exista riesgo? Si la respuesta es sí, notifica. La segunda capa es la investigación técnica en profundidad, que seguirá durante días o semanas y alimentará ampliaciones posteriores bajo el art. 33.4.

Lo que la autoridad suele castigar no es la imperfección inicial, sino la parálisis. Una notificación temprana y honesta, que explique qué se sabe, qué no se sabe y cuándo habrá actualización, es jurídicamente mucho más defendible que un silencio elegante de 96 horas.

Tu entidad ya tiene esto resuelto? Hazte tres preguntas incómodas. Primera: ¿quién puede declarar formalmente que existe “constancia” de una violación de datos? Segunda: ¿ese criterio está escrito y entrenado? Tercera: ¿puedes activar esa decisión un sábado a las 02:00 sin depender de una persona concreta? Si dudas en alguna, el reloj te va a parecer bastante más rápido de lo que dice el reglamento.

Art. 33 y art. 34 no son lo mismo, y tratarlos como si lo fueran crea caos

Una brecha puede activar dos deberes distintos. El primero, frente a la autoridad de control, nace cuando la violación entraña un riesgo para los derechos y libertades de las personas físicas: art. 33.1 GDPR. El segundo, frente a los propios interesados, surge cuando es probable que entrañe un alto riesgo: art. 34.1 GDPR.

La diferencia parece académica hasta que tienes que decidir qué decir, a quién y cuándo. Notificar a la autoridad sin comunicar aún a los afectados puede ser correcto si el riesgo existe pero sigue siendo limitado o mitigable. Piensa en un acceso indebido rápidamente contenido sobre un subconjunto pequeño de datos de contacto, sin credenciales, sin datos financieros y con confirmación de que no hubo descarga masiva. En cambio, si la brecha afecta a credenciales reutilizables, documentación de identidad, historiales médicos o combinaciones con alto potencial de fraude, el salto a “alto riesgo” puede ser inmediato.

El art. 34.2 exige que la comunicación al interesado describa en lenguaje claro y sencillo la naturaleza de la violación y contenga, al menos, la información y medidas a que se refiere el art. 33.3.b, c y d: datos de contacto del DPO o punto de contacto, consecuencias probables y medidas adoptadas o propuestas, incluidas recomendaciones para mitigar efectos adversos. Esto tiene una implicación operativa poco glamurosa: el texto a interesados no se improvisa el día de la crisis. Si comunicaciones, legal y seguridad no han preparado plantillas y criterios antes, lo harán bajo presión, y saldrá lo que suele salir: demasiado vago para ayudar, demasiado específico para gustar a legal y demasiado lento para cumplir.

Las excepciones del art. 34.3 merecen una lectura fría. No comunicar a interesados puede ser legítimo si los datos eran ininteligibles, si medidas posteriores garantizan que el alto riesgo ya no es probable, o si la comunicación individual exige esfuerzos desproporcionados, en cuyo caso debe recurrirse a una comunicación pública similarmente eficaz. La tercera excepción es la favorita de quien quiere ahorrar costes; también es la que más fácilmente se discute si la base de clientes estaba perfectamente localizada en CRM y bastaba un email.

La evaluación de riesgo que convence a una autoridad no es una plantilla de colores

El riesgo en brechas de datos no se evalúa con un semáforo bonito ni con una escala de “bajo/medio/alto” sin justificación. Una autoridad espera razonamiento. Para CISOs y responsables de cumplimiento, eso significa construir un modelo que aterrice la teoría del GDPR en variables observables.

Un análisis útil suele partir de cinco preguntas.

Qué datos están implicados, exactamente

No todos los datos personales pesan igual. Nombre y email de trabajo no equivalen a pasaporte, IBAN, nómina o historial clínico. Las categorías especiales del art. 9 GDPR elevan el riesgo por definición práctica, aunque el artículo no establezca un automatismo formal. Los datos relativos a condenas e infracciones penales del art. 10 también exigen especial cautela. Si el incidente mezcla identificadores sólidos con datos financieros o de autenticación, la combinación multiplica el potencial de daño.

A cuántas personas afecta y cuán identificables son

El volumen no lo decide todo, pero importa. Un acceso indebido a 200 expedientes muy sensibles puede ser peor que la exposición de 20.000 direcciones de correo corporativo. Lo decisivo es si los datos permiten identificar con facilidad a personas concretas y si esa identificación habilita perjuicios plausibles.

Qué actor obtuvo acceso o pudo obtenerlo

No es lo mismo un envío erróneo a un proveedor sujeto a confidencialidad, que una exfiltración por un actor criminal, que una publicación accidental indexable en internet. En la práctica, el análisis de probabilidad cambia radicalmente según el receptor o atacante. Si puedes demostrar que los datos llegaron a una entidad regulada que confirmó borrado inmediato y no hubo difusión ulterior, el riesgo baja. Si el repositorio quedó abierto en la web pública durante días, no hace falta mucha poesía para entender que sube.

Qué controles mitigaban el daño

Cifrado, tokenización, hashing adecuado, segmentación, control de acceso fuerte, expiración de credenciales, registro de accesos, DLP y capacidad de revocación. Ojo: no basta con mencionar controles en abstracto. Hay que demostrar que protegían ese conjunto concreto de datos y que seguían eficaces en el incidente. Un cifrado de base de datos no sirve de mucho como argumento exculpatorio si el atacante comprometió una cuenta privilegiada que accedía en claro a la aplicación.

Qué consecuencias plausibles pueden sufrir los afectados

El estándar no es imaginar el apocalipsis ni minimizarlo por sistema. Es conectar el tipo de datos y el contexto con efectos realistas: phishing dirigido, fraude de pagos, denegación de crédito, exposición laboral, discriminación, chantaje, violencia doméstica en contextos sensibles, robo de identidad o simple pérdida de control sobre la información. Cuanto más concreto sea el razonamiento, más defendible resultará.

La buena noticia es que este modelo también sirve para decidir medidas posteriores: monitorización reforzada, reseteo de claves, aviso a bancos emisores, activación de protección antifraude o recomendaciones prácticas a interesados. La mala noticia es que obliga a seguridad y privacidad a hablar entre sí con precisión. Y eso todavía sorprende en más organizaciones de las que admitirán en público.

Cuando el incidente viene de un proveedor, el reloj sigue siendo tuyo

La dependencia de terceros complica la cronología. Mucho. SaaS, BPO, procesadores de nómina, plataformas CRM, servicios cloud, herramientas de soporte remoto. La cadena digital es larga y el dato viaja. Pero el art. 33.2 GDPR es bastante nítido: el encargado del tratamiento notificará al responsable sin dilación indebida después de tener constancia de una violación de datos personales.

Eso significa dos cosas. La primera, que tu proveedor no tiene sus propias 72 horas frente a ti; tiene un deber de avisarte sin demora. La segunda, que tu plazo frente a la autoridad no queda suspendido porque el proveedor aún esté “investigando”. Si tu contrato no fija tiempos concretos de escalado, contenido mínimo de la notificación inicial, obligación de cooperación forense, acceso a logs relevantes y puntos de contacto 24/7, has externalizado la operación, no la responsabilidad.

Para entidades financieras y fintechs europeas, aquí aparece además una fricción interesante con DORA. El reglamento exige capacidades de gestión de incidentes TIC, clasificación y reporte en su propio perímetro, y presta mucha atención a terceros TIC en DORA capítulo V y art. 28 y siguientes. Aunque una violación de datos personales se valore bajo GDPR y un incidente TIC bajo DORA respondan a lógicas distintas, en la práctica suelen compartir hechos, cronología y proveedores. Si cada régimen se gestiona en un silo, la organización acabará presentando versiones incompatibles del mismo incidente a privacidad, supervisión financiera y clientes críticos. Es una forma bastante sofisticada de autolesionarse.

La salida razonable es un expediente maestro de incidente con vistas separadas por obligación regulatoria. Un único registro factual —fechas, sistemas, evidencias, decisiones, contactos del proveedor— y derivaciones específicas para GDPR, DORA, NIS2 u obligaciones contractuales. Así reduces contradicciones y, de paso, dejas de pedir tres veces la misma información al mismo ingeniero a las tres de la mañana.

Cómo demostrar que no notificaste y aun así cumpliste

No todas las brechas se notifican. El propio art. 33.1 prevé la excepción cuando sea improbable que la violación entrañe un riesgo para los derechos y libertades de las personas físicas. El problema es que muchas organizaciones documentan esta conclusión con una ligereza casi artística: “No se aprecian riesgos significativos”. Fin del expediente. Mala idea.

Si decides no notificar, necesitas un estándar probatorio interno al menos tan serio como si hubieras notificado. Porque el art. 33.5 obliga igualmente a documentar la violación y a permitir a la autoridad verificar el cumplimiento. En una revisión posterior, la pregunta será obvia: ¿por qué consideró la entidad improbable el riesgo?

Las respuestas defendibles suelen apoyarse en hechos verificables como estos: datos cifrados de forma robusta y claves no comprometidas; envío erróneo a un destinatario fiable que acreditó supresión inmediata; repositorio accesible solo internamente sin evidencia de acceso no autorizado; exposición de identificadores de bajo impacto sin combinaciones que permitan perjuicio relevante; recuperación rápida de un dispositivo con cifrado completo, MDM activo y logs que descartan acceso posterior. Incluso en esos casos, el expediente debe incluir evidencia, no solo la conclusión.

El regulador no espera infalibilidad. Espera método. La diferencia entre una buena no-notificación y una mala suele ser que la primera puede leerse meses después y seguir teniendo sentido.

Checklist de evidencias para auditoría

En brechas de datos, la auditoría interna o externa no debería preguntar “¿tenemos un procedimiento?”. Debería preguntar “¿qué prueba tenemos de que el procedimiento funcionó en un caso real?”. Para eso, esta checklist sí merece existir, porque habla de evidencias auditables y no de slogans.

Si esta tabla no puede llenarse con documentos reales, el problema no es de forma. Es de control interno.

Implicaciones para entidades financieras españolas

Para bancos, aseguradoras, gestoras, entidades de pago y fintech con operaciones en España, la gestión de brechas bajo GDPR ya no puede tratarse como una isla. En 2026 convive con obligaciones de resiliencia operativa, supervisión de proveedores, reporte de incidentes TIC y escrutinio reforzado sobre outsourcing crítico.

Primero, porque la información comprometida en servicios financieros rara vez es inocua. Datos KYC, documentación de identidad, IBAN, operaciones, beneficiarios, pólizas, historiales de siniestros, grabaciones de voz, scoring o credenciales de banca digital elevan con rapidez el análisis de riesgo bajo art. 33 y 34 GDPR.

Segundo, porque la coexistencia con DORA obliga a alinear taxonomías internas. Un incidente puede no ser “grave” a efectos de un régimen supervisor financiero y, al mismo tiempo, exigir notificación como brecha de datos personales. O al revés. Lo peligroso no es que los umbrales sean distintos; eso es normal. Lo peligroso es que la organización no tenga una capa común de hechos y acabe defendiendo versiones contradictorias ante distintas autoridades.

Tercero, porque España añade una práctica supervisora donde la trazabilidad documental pesa. La Agencia Española de Protección de Datos no valora solo el resultado. Mira el proceso: evaluación de riesgo, proporcionalidad, diligencia y capacidad de justificar decisiones. Quien llegue con una línea temporal sólida suele discutir sobre derecho. Quien llegue con un expediente inconsistente discute sobre credibilidad.

La consecuencia operativa para el sector financiero español es clara: el playbook de crisis debe unificar privacy, ciberseguridad, continuidad, terceros y comunicación. Si esos equipos siguen trabajando en paralelo y cruzándose correos, la entidad llegará a la hora 50 con demasiadas opiniones y demasiadas pocas pruebas.

Lo que conviene cambiar mañana por la mañana

No hace falta rehacer toda la función de privacidad para mejorar de verdad. Sí hace falta tocar algunas piezas que suelen estar rotas.

La primera es el criterio formal de activación. Define por escrito quién puede declarar que existe una posible violación de datos personales y qué umbral factual se exige. No lo dejes en “cuando lo veamos claro”. Esa frase sirve para perder tiempo y para poco más.

La segunda es la cronología unificada. Un solo sistema —aunque sea una herramienta sencilla bien gobernada— donde queden registrados eventos, decisiones, cambios de hipótesis, contactos con proveedores y aprobaciones. Sin eso, cada equipo guarda su propia verdad en Teams, correo, SIEM y cuadernos personales. Luego nadie reconstruye nada con solvencia.

La tercera es un modelo de evaluación de riesgo con campos obligatorios vinculados al GDPR: categorías de datos, categorías de interesados, volumen estimado, facilidad de identificación, actor receptor, controles mitigantes, consecuencias plausibles, conclusión sobre art. 33 y conclusión separada sobre art. 34. Si no está estructurado, cada incidente se evaluará con una lógica distinta.

La cuarta es endurecer los contratos con encargados. El art. 28.3 GDPR ya exige que el tratamiento por cuenta del responsable se rija por contrato o acto jurídico con contenido determinado. Aprovecha esa base para concretar tiempos de notificación, canales 24/7, retención de logs, cooperación en borradores regulatorios, preservación de pruebas y asistencia en comunicaciones a interesados. “Nos avisarán si pasa algo” no es una cláusula; es una esperanza.

La quinta es entrenar con casos incómodos, no con escenarios de cartón piedra. Haz simulaciones donde no haya certeza plena, donde el proveedor tarde ocho horas en contestar, donde haya dudas sobre si los datos estaban cifrados efectivamente y donde el negocio presione para no comunicar. Ahí se descubre si el procedimiento sirve o si era literatura corporativa.

La prueba vale más que la épica

Las 72 horas del art. 33 GDPR no premian a la organización que dramatiza mejor la crisis. Premian —o al menos protegen— a la que puede demostrar disciplina documental, criterio jurídico razonable y coordinación operativa. El reloj empieza cuando hay constancia suficiente de una violación de datos personales, no cuando termina la forense ni cuando el comité ejecutivo encuentra hueco en la agenda. Y una vez empieza, la defensa no consiste en sonar convencido, sino en enseñar evidencia.

Ese es el punto que muchos equipos aún subestiman. La autoridad puede discrepar de tu juicio. Lo que tolera mucho peor es no poder seguir tu razonamiento. Si el expediente muestra hechos, horas, responsables, evaluación de riesgo y medidas coherentes, tienes algo que defender. Si solo tienes recuerdos, ya has perdido media discusión.

En privacidad, como en tantas otras áreas del compliance tecnológico, el problema rara vez es desconocer la regla. El problema es llegar al día malo con un reloj corriendo y descubrir que nadie preparó la prueba de que se estaba mirando la hora.