|8 min de lectura|Yvann Lièvre

RGPD Art.33: notificar a la autoridad de protección de datos en 72h

Qué constituye una violación de datos, el proceso de notificación a la autoridad, el plazo de 72h y cómo automatizar la detección y el informe.

RGPDCNIL
RGPD Art.33: notificar a la autoridad de protección de datos en 72h

El Art.33 del RGPD es claro: en caso de una violación de datos personales, el responsable del tratamiento debe notificar a la autoridad de control dentro de las 72 horas siguientes a haber tenido conocimiento de ella. No 72 horas después de terminar la investigación. No 72 horas después de la reunión de crisis. 72 horas después de tomar conocimiento. Este plazo es un desafío técnico y organizacional que muchos subestiman.

¿Qué constituye una violación de datos según el RGPD?

El Art.4(12) define la violación de datos personales como "una violación de la seguridad que ocasione, de manera accidental o ilícita, la destrucción, pérdida, alteración, divulgación no autorizada de datos personales". En la práctica, tres tipos:

  • Violación de confidencialidad: acceso no autorizado a datos personales. Ejemplo: base de datos de clientes expuesta en Internet, correo electrónico enviado al destinatario equivocado, compromiso por un atacante.

  • Violación de integridad: alteración no autorizada de los datos. Ejemplo: ransomware que cifra una base de pacientes, modificación maliciosa de expedientes de RRHH.

  • Violación de disponibilidad: pérdida de acceso a los datos. Ejemplo: caída del servidor sin backup, ataque DDoS que hace inaccesibles los datos, destrucción accidental.

Punto importante: no toda violación de datos es necesariamente notificable. El Art.33 exige la notificación a menos que "sea improbable que la violación suponga un riesgo para los derechos y libertades de las personas físicas". Si los datos estaban cifrados con un algoritmo robusto y la clave no fue comprometida, el riesgo puede considerarse nulo. Pero esta evaluación debe documentarse.

El proceso de notificación a la autoridad

La notificación se realiza ante la autoridad de protección de datos de su país. El formulario solicita:

  • Naturaleza de la violación: tipo (confidencialidad/integridad/disponibilidad), causa, vector de ataque

  • Categorías de datos: qué datos están afectados (identidad, contacto, financiero, salud, etc.)

  • Número de personas afectadas: estimación si no se conoce la cifra exacta

  • Consecuencias probables: impacto potencial sobre las personas (usurpación de identidad, pérdida financiera, etc.)

  • Medidas adoptadas: acciones de contención, remediación y prevención

  • Contacto del DPO: datos del Delegado de Protección de Datos

La notificación puede hacerse en dos etapas: una notificación inicial dentro de las 72h con la información disponible, y luego una notificación complementaria cuando la investigación aporte nuevos elementos. Los reguladores aceptan explícitamente este enfoque por fases.

El desafío de las 72 horas

Analicemos la cronología realista:

  • T+0h: detección de la violación. El reloj de las 72h arranca aquí, no cuando ocurrió el ataque, sino cuando usted tomó conocimiento.

  • T+0 a T+6h: confirmación del incidente, evaluación inicial del perímetro, identificación de los datos afectados

  • T+6 a T+24h: investigación técnica (forense inicial), estimación del número de personas afectadas, evaluación del riesgo para las personas

  • T+24 a T+48h: redacción del informe de notificación, validación jurídica y del DPO

  • T+48 a T+72h: presentación ante la autoridad, notificación a las personas si es necesario (Art.34)

El cuello de botella es casi siempre el mismo: la detección. Con un dwell time promedio de 194 días (IBM 2025), la mayoría de las organizaciones no cumplen las 72h porque no detectan la violación a tiempo, no porque no puedan redactar el informe lo suficientemente rápido.

La notificación a las personas (Art.34)

Si la violación es "susceptible de generar un riesgo alto para los derechos y libertades" de las personas, también debe notificar a los afectados. En términos claros y comprensibles, explicando:

  • La naturaleza de la violación

  • Los datos afectados

  • Las consecuencias probables

  • Las medidas adoptadas y recomendaciones (cambiar contraseña, monitorear cuentas bancarias, etc.)

Excepción: la notificación a las personas no es requerida si los datos estaban cifrados, si se adoptaron medidas para eliminar el riesgo, o si requeriría un esfuerzo desproporcionado (en ese caso, comunicación pública).

Las sanciones por no notificar

El incumplimiento del Art.33 se sanciona conforme al Art.83(4): multa de hasta 10 M€ o 2 % de la facturación mundial. En la práctica, las autoridades sancionan regularmente las fallas en la notificación. Ejemplos recientes:

  • Grupo hospitalario: 800 000 € por notificación tardía y medidas de seguridad insuficientes

  • Operador de telecomunicaciones: 300 000 € por falta de notificación dentro de las 72h

  • Startup: 150 000 € por ausencia de notificación a pesar de una filtración de 500 000 cuentas

Los reguladores revisan dos cosas: ¿notificó a tiempo? ¿Y tenía las medidas de seguridad apropiadas para detectar la violación?

Cómo ThreatClaw automatiza la detección y el informe

ThreatClaw aborda el problema desde ambos lados:

Detección automática de datos personales

  • Identificación de los flujos de datos personales en su infraestructura

  • Clasificación automática de datos (identidad, financiero, salud) mediante análisis de bases de datos y flujos

  • Alertas en tiempo real si datos personales están expuestos (bucket S3 público, base de datos sin autenticación, API sin control de acceso)

Detección de violaciones

  • Monitoreo continuo de los accesos a bases de datos que contienen datos personales

  • Detección de exfiltración (volumen anormal de consultas, transferencias a destinos inusuales)

  • Correlación con indicadores de compromiso (¿el acceso proviene de una cuenta comprometida?)

Generación del informe Art.33

  • Informe prellenado en el formato requerido dentro de los 15 minutos siguientes a la detección

  • Estimación automática del perímetro (tablas afectadas, número de registros, categorías de datos)

  • Cronología técnica del incidente

  • El DPO recibe un expediente completo para validación, no una alerta sin procesar para investigar

Lo que antes tomaba 24-48h de investigación manual está disponible en 15 minutos. Las 72h se convierten en un plazo cómodo en lugar de una carrera contrarreloj.

La articulación con NIS2

Si su organización también está cubierta por NIS2, tiene una doble obligación de notificación. NIS2 Art.23 exige una alerta al CSIRT en 24h (más estricto que el RGPD). ThreatClaw genera ambos informes simultáneamente, el formato para la autoridad de protección de datos (Art.33 RGPD) y el formato CSIRT (Art.23 NIS2).

Preguntas frecuentes

¿Un correo electrónico enviado al destinatario equivocado es una violación notificable?

Depende. Si el correo contiene datos personales sensibles (salud, financieros) y el destinatario no es un tercero de confianza, sí, es una violación de confidencialidad probablemente notificable. Si es un correo interno con un nombre de pila, el riesgo es mínimo. En todos los casos, documente el incidente en su registro de violaciones (obligación Art.33(5)) aunque no notifique a la autoridad.

¿El plazo de 72h aplica los fines de semana y días festivos?

Sí, sin excepción. 72 horas calendario, no hábiles. Por eso el monitoreo continuo y la detección automatizada son indispensables, la violación no elige su momento.

¿Qué pasa si excedo las 72h?

Debe notificar de todos modos, explicando las razones del retraso (Art.33(1)). Un retraso justificado (investigación compleja, incidente de gran escala) será visto más favorablemente que una ausencia total de notificación. Pero los reguladores valoran el cumplimiento de plazos, es un factor en el cálculo de la sanción.

¿Debo notificar a la autoridad si los datos estaban cifrados?

Si el cifrado es robusto (AES-256, clave no comprometida) y los datos exfiltrados son inexplotables, el riesgo para las personas es nulo y la notificación no es requerida. Pero debe documentar esta evaluación. Si tiene la menor duda sobre la robustez del cifrado o si la clave pudo haber sido comprometida, notifique. Los reguladores prefieren una notificación "por precaución" a una no notificación injustificada.

Artículos relacionados