Anatomía de un incidente DORA: del indicio a la notificación
El reloj de Digital Operational Resilience Act: reglamento UE 2022/2554 sobre resiliencia operativa digital. Exige a entidades financieras de la UE resistir, responder y recuperarse de incidentes TIC. En vigor desde 17 enero 2025. Leer más → DORA no empieza cuando decides reportar: empieza cuando detectas. El siguiente es un escenario ilustrativo (no un cliente real) de cómo una fintech recorre un incidente grave desde el primer indicio hasta la notificación al regulador, y dónde el proceso manual pierde las horas que la norma no perdona.
El escenario
Una entidad de pago detecta a las 09:14 una degradación en su pasarela: latencias anómalas y un subconjunto de transacciones rechazadas. No hay aún certeza de causa. La pregunta operativa no es "¿qué ha fallado?" sino "¿esto es un incidente grave a efectos de DORA, y desde cuándo corre el plazo?". La respuesta determina obligaciones de notificación con horas contadas.
Hora 0: detección y triaje
DORA (Reglamento (UE) 2022/2554) parte del concepto de incidente relacionado con las TIC. Lo primero es registrar el momento de detección y abrir un expediente. Ese timestamp es el origen del cómputo: si la cronología no queda registrada desde el minuto cero, reconstruirla después ante la autoridad competente es una conjetura, no una prueba.
¿Es un incidente grave? La clasificación
DORA exige notificar los incidentes graves. Los criterios de clasificación (desarrollados en los RTS) no son una corazonada: son umbrales evaluables.
| Criterio | Qué mide |
|---|---|
| Clientes y contrapartes afectados | Número y proporción sobre el total. |
| Duración e indisponibilidad | Tiempo de servicio degradado o caído. |
| Dispersión geográfica | Alcance en otros Estados miembros. |
| Pérdida de datos | Integridad, disponibilidad o confidencialidad comprometidas. |
| Criticidad de los servicios | Afectación a funciones esenciales o importantes. |
| Impacto económico | Costes y pérdidas asociados. |
La clasificación no es un trámite posterior: es la decisión que arranca el reloj de notificación. Y debe poder justificarse con los datos que la sustentan.
El reloj regulatorio
Una vez clasificado como grave, DORA estructura la notificación en tres entregas, cada una con su ventana:
| Entrega | Ventana orientativa |
|---|---|
| Notificación inicial | En las primeras horas tras la clasificación como grave (y dentro del plazo máximo desde la detección). |
| Informe intermedio | Al restablecerse la actividad o según evolucione el incidente. |
| Informe final | Cuando se cierra el análisis de causa raíz, dentro del plazo del mes. |
El plazo se mide desde la detección, no desde la calma
El error recurrente es empezar a documentar cuando el incidente ya está controlado. Para entonces, la notificación inicial puede ir tarde. El cómputo corre en paralelo a la respuesta técnica, no después.
Dónde se rompe el proceso manual
En el escenario, el equipo técnico está mitigando mientras alguien, en paralelo, intenta reunir los datos para clasificar y redactar. Ahí aparecen las grietas:
| Punto de fallo | Consecuencia |
|---|---|
| Cronología dispersa | El timestamp de detección no es defendible. |
| Clasificación a ojo | Sin trazabilidad de qué umbral se cruzó y con qué dato. |
| Plazos sin alarma | La ventana de la notificación inicial se descubre tarde. |
| Reporte manual | Redactar bajo presión multiplica errores y omisiones. |
El incidente técnico se resuelve. La defensa regulatoria del incidente, no.
Qué automatiza un sistema
La automatización aquí no sustituye el juicio: lo cronometra y lo documenta.
- Sello temporal en la detección, con expediente abierto desde el minuto cero.
- Scoring de clasificación sobre los criterios de los RTS, con el dato que justifica cada umbral.
- Alarmas de plazo ancladas al momento de detección y de clasificación.
- Pre-rellenado de las tres entregas con la cronología y la causa raíz.
- Audit trail inmutable de quién decidió qué y cuándo.
El principio se mantiene: el sistema cronometra, la persona decide
Clasificar un incidente como grave y notificarlo al regulador es una decisión humana. El sistema garantiza que esa decisión llega a tiempo y queda documentada, no que se tome sola.
Cómo aborda BlueUPALM el ciclo de incidente DORA
| Capacidad | Implementación |
|---|---|
| Detección | Apertura de incidente con sello temporal desde el primer indicio. |
| Clasificación | Evaluación sobre los criterios de gravedad de los RTS. |
| Plazos | Seguimiento de las tres entregas anclado a detección y clasificación. |
| Reporting | Pre-rellenado de notificación inicial, intermedia y final. |
| Audit trail | Registro inmutable de la cronología y las decisiones. |
Lecturas relacionadas
- DORA 2026: guía práctica para entidades financieras — El marco completo del que sale este escenario.
- Software SEPBLAC: automatizar el reporting sin perder trazabilidad — El mismo principio de trazabilidad aplicado al reporting Anti-Money Laundering: prevención de blanqueo de capitales. Consume 5-10% del presupuesto operativo de una entidad media; los sistemas tradicionales generan >95% falsos positivos. Leer más → AML.
- Calculadora DORA — Evalúa en minutos tu madurez DORA.
¿Quieres ver el ciclo de incidente DORA automatizado?
Te mostramos el flujo de clasificación, plazos y notificación de BlueUPALM con un escenario de tu sector.