Notificación de incidentes en 72 horas: RGPD, NIS2 y DORA comparados

El día que ocurre un incidente grave, el reloj empieza a correr en varias direcciones a la vez. La notificación de incidentes es una de las obligaciones donde más se nota el solapamiento normativo: el RGPD, NIS2 y DORA imponen plazos y destinatarios distintos sobre, muchas veces, el mismo suceso. Sin un proceso único, ese día se convierte en un caos.

Tres normativas, tres relojes

El RGPD exige notificar a la autoridad de control una brecha de datos personales en un máximo de 72 horas desde que se tiene conocimiento. NIS2 impone una alerta temprana mucho más exigente: 24 horas para incidentes significativos, con un informe posterior más detallado. Y el reglamento DORA añade, en el sector financiero, sus propios plazos para los incidentes graves relacionados con las TIC.

El problema es evidente: un mismo ciberataque que comprometa datos personales de una entidad financiera puede activar las tres obligaciones simultáneamente, cada una con su plazo y su destinatario.

Comparativa de plazos y destinatarios

RGPD

72 horas a la autoridad de protección de datos, y comunicación a los afectados si hay alto riesgo para sus derechos. El foco es el dato personal.

NIS2

Alerta temprana en 24 horas, notificación en 72 horas y un informe final posterior, dirigidos al CSIRT o autoridad competente. El foco es el impacto en el servicio esencial.

DORA

Plazos propios para incidentes graves relacionados con las TIC, con notificación a la autoridad financiera competente. El foco es la resiliencia operativa del sistema financiero.

Cómo diseñar un proceso único de notificación

La solución no es tener tres procedimientos, sino uno solo bien diseñado. Defino un flujo único de detección, clasificación y escalado que, según el tipo de incidente, dispara automáticamente las notificaciones que correspondan a cada marco. Esa lógica de un proceso que cubre varias normativas es justo lo que he integrado en la herramienta de cumplimiento que desarrollo, porque coordinar tres relojes a mano bajo presión es una receta para el incumplimiento.

La clave está en clasificar bien el incidente desde el primer minuto: saber qué dimensiones afecta determina qué relojes se activan.

El error de tener tres procesos separados

El fallo que más me encuentro en las organizaciones es mantener tres procedimientos de notificación independientes: uno para protección de datos, otro para NIS2 y otro para DORA. En el papel parece ordenado, pero cuando ocurre un incidente real a las tres de la madrugada, nadie sabe qué reloj corre primero ni quién avisa a quién. El resultado son plazos incumplidos y sanciones que se podían haber evitado. Por eso defiendo un único proceso de detección y clasificación que, una vez activado, dispare en paralelo las notificaciones que correspondan según la naturaleza del incidente.

La clave está en la fase de triaje. En los primeros minutos hay que responder a tres preguntas: ¿hay datos personales afectados?, ¿se ve comprometido un servicio esencial?, ¿es una entidad financiera bajo DORA? Las respuestas determinan qué relojes arrancan. Tener esa decisión protocolizada, y no improvisada, es lo que marca la diferencia entre cumplir los plazos y quedarse fuera de juego.

La cadena de suministro complica los plazos

Un matiz que muchas empresas pasan por alto es que el incidente puede no ocurrir en tu casa, sino en la de un proveedor. Si un servicio del que dependes sufre una brecha, tus obligaciones de notificación pueden activarse igualmente, y el plazo no se detiene mientras esperas que tu proveedor te informe. Por eso conviene exigir por contrato avisos rápidos y revisar cómo se evalúa el riesgo de terceros, un tema que desarrollo en mi artículo sobre NIS2 y la cadena de suministro.

Mi recomendación práctica es mapear, antes de que pase nada, qué proveedores podrían disparar una obligación de notificación y acordar con ellos canales y tiempos de aviso. Cuando el incidente llega, ese trabajo previo ahorra horas críticas que, con un reloj de 72 horas en marcha, valen oro.

En el fondo, la notificación de incidentes no es un trámite burocrático: es la prueba de fuego de toda tu estrategia de resiliencia. Una organización que notifica bien es una que ha ensayado, que sabe quién decide y que tiene los contactos a mano. Esa madurez no se improvisa el día del ataque; se construye antes, con procedimientos claros y simulacros periódicos.

La clave para cumplir un plazo de notificación tan ajustado no está en correr cuando llega el incidente, sino en haberlo ensayado antes. En los equipos que acompaño, organizo simulacros periódicos donde practicamos quién decide que algo es notificable, quién redacta la comunicación y quién la envía. Esos ensayos revelan los cuellos de botella reales —un responsable ilocalizable, una plantilla que no existía— mucho antes de que cuenten de verdad. Cuando llega el incidente real, el equipo no improvisa: ejecuta un proceso que ya conoce, y ahí es donde se gana o se pierde el plazo.

Conviene recordar que muchos de los incidentes que hay que notificar no se originan dentro de casa, sino en un proveedor. Por eso la gestión del plazo de 72 horas está íntimamente ligada a cómo controlas a tus terceros, un tema que desarrollo en mi artículo sobre NIS2 y la evaluación de proveedores. Si un proveedor crítico tarda días en avisarte de una brecha, tu reloj regulatorio ya habrá empezado a correr sin que lo supieras.

Conclusión: ensayar antes de que pase

La notificación de incidentes no se improvisa. Un proceso único, documentado y ensayado con simulacros es lo que permite responder con cabeza cuando todos los relojes corren a la vez. He visto cómo esa preparación marca la diferencia entre una gestión profesional y una crisis dentro de la crisis.

Preguntas frecuentes sobre la notificación de incidentes