Saltar al contenido

This page is also available in English.

Almenara
← Volver al blog
13 minDirigido a: Compliance, CISO

¿Cuándo un incidente es grave según DORA? Criterios, umbrales y cinco casos resueltos

La respuesta corta: según DORA, un incidente relacionado con las TIC es grave cuando afecta a servicios esenciales de la entidad financiera y, además, se cumple una de estas dos condiciones: ha habido un acceso malintencionado y no autorizado que puede acabar en pérdida de datos, o se superan dos o más umbrales de los que fija el artículo 9 del Reglamento Delegado (UE) 2024/1772. Si es grave, la notificación inicial va al supervisor en 4 horas desde que lo clasificas como grave y nunca más tarde de 24 horas desde que lo conoces.

El resto de este artículo es el detalle que hace falta para aplicar esa frase a las tres de la madrugada: qué cuenta como servicio esencial, cuáles son los umbrales exactos, cómo se miden y cinco casos clasificados paso a paso.

La regla en dos pasos

La clasificación no es una suma de puntos. Es un filtro y, después, una cuenta.

Paso 1: la puerta. Si el incidente no afecta a servicios esenciales, no es grave, por muchos clientes que afecte. El artículo 6 del Reglamento Delegado 2024/1772 dice que afecta a servicios esenciales cuando se cumple cualquiera de estas tres cosas:

  1. Afecta a servicios TIC o a redes y sistemas de información que sustentan funciones esenciales o importantes de la entidad.
  2. Afecta a servicios financieros que requieren autorización o registro, o que están supervisados.
  3. Es un acceso efectivo, malintencionado y no autorizado a las redes y sistemas de información de la entidad.

Paso 2: la cuenta. Si ha pasado la puerta, el incidente es grave (artículo 8.1) cuando:

  • a) hay un acceso malintencionado y no autorizado a redes y sistemas que puede dar lugar a pérdida de datos (el umbral del artículo 9.5.b). Basta con eso; o
  • b) se superan dos o más de los demás umbrales del artículo 9.

La versión inglesa habla de critical services y critical or important functions. La española, de «servicios esenciales» y «funciones esenciales o importantes». Es lo mismo.

Los seis criterios y sus umbrales

Estos son los umbrales del artículo 9. Cada fila es un criterio: si se cumplen dos condiciones de la misma fila, cuenta como uno, no como dos.

CriterioSe supera cuando se cumple cualquiera de estas condiciones
Clientes, contrapartes financieras y transacciones (art. 9.1)Más del 10 % de los clientes que usan el servicio afectado · más de 100 000 clientes afectados · más del 30 % de las contrapartes financieras relacionadas con el servicio · más del 10 % del número medio diario de transacciones del servicio · más del 10 % del valor medio diario de esas transacciones · se ven afectados clientes o contrapartes que la entidad ha identificado como pertinentes
Repercusión en la reputación (art. 9.2)Ha salido en los medios · quejas reiteradas de distintos clientes o contrapartes · la entidad no puede, o probablemente no podrá, cumplir requisitos reglamentarios · la entidad perderá, o probablemente perderá, clientes o contrapartes con consecuencias importantes
Duración e interrupción del servicio (art. 9.3)El incidente dura más de 24 horas · o el servicio está interrumpido más de 2 horas, si es un servicio TIC que sustenta funciones esenciales o importantes
Extensión geográfica (art. 9.4)Tiene consecuencias en dos o más Estados miembros, sea en clientes, sucursales, entidades del grupo, infraestructuras de mercado o proveedores terceros
Pérdidas de datos (art. 9.5)El impacto en la disponibilidad, autenticidad, integridad o confidencialidad de los datos perjudica los objetivos de negocio o el cumplimiento normativo · o hay un acceso malintencionado y no autorizado que puede causar pérdida de datos. Esta segunda condición ya hace grave el incidente por sí sola
Consecuencias económicas (art. 9.6)Los costes y pérdidas superan, o probablemente superarán, 100 000 EUR

El séptimo criterio de DORA, el carácter esencial de los servicios afectados, no está en la tabla porque no se cuenta: es la puerta del paso 1.

Cómo se mide cada cosa

Los umbrales son claros. Lo que cambia el resultado es cómo se mide. El Reglamento Delegado lo concreta en sus artículos 1 a 7:

  • Duración del incidente: desde que se produce hasta que se resuelve. Si no sabes cuándo empezó, desde que se detectó; pero si los registros muestran que empezó antes, desde lo que digan los registros.
  • Interrupción del servicio: desde que el servicio deja de estar disponible, total o parcialmente, hasta que vuelve al nivel de antes. Si después quedan operaciones retrasadas, la interrupción dura hasta que se completan.
  • Clientes afectados: los que no pueden usar el servicio y también los que se ven afectados negativamente. Incluye a terceros cubiertos por el contrato como beneficiarios del servicio.
  • Transacciones: todas las que implican un importe monetario con al menos una parte en la Unión: pagos, valores, criptoactivos, materias primas, garantías.
  • Costes y pérdidas: cuentan los fondos expropiados, sustituir o reubicar software, hardware o infraestructura, el personal extra y las horas extraordinarias, los incumplimientos contractuales, las indemnizaciones a clientes, el lucro cesante, la comunicación y los asesores legales y forenses. No cuentan el mantenimiento ordinario, las mejoras posteriores al incidente ni las primas de seguro. Y las recuperaciones, como lo que pague el seguro, no se descuentan.
  • Si no tienes el dato: estímalo con periodos de referencia comparables. La norma lo permite expresamente; no hace falta esperar a tener la cifra exacta.

Cinco casos clasificados paso a paso

Los cinco casos son de ACME, un banco.

Caso 1. La app de ACME, caída tres horas

ACME tiene 400 000 clientes en su app. Un martes a las 10:00 falla el servicio de autenticación y 150 000 clientes no pueden entrar durante 3 horas.

  • Puerta: la app sustenta una función esencial. Pasa.
  • Clientes: 150 000 supera los 100 000 y también el 10 %. Es un criterio cumplido, aunque se den dos condiciones.
  • Interrupción: 3 horas, más de 2 en un servicio que sustenta una función esencial. Segundo criterio.
  • Resultado: grave. Dos criterios. La notificación inicial vence 4 horas después de clasificarlo, y como tarde 24 horas después de conocerlo.

Caso 2. Ransomware contenido en 40 minutos

Un atacante cifra un servidor de ficheros de Recursos Humanos de ACME. El equipo lo aísla en 40 minutos. Ningún cliente nota nada.

  • Puerta: es un acceso efectivo, malintencionado y no autorizado a los sistemas de la entidad (artículo 6.c). Pasa, aunque no toque ninguna función esencial.
  • Atajo del artículo 8.1.a: ese acceso puede dar lugar a pérdida de datos. Con esto basta.
  • Resultado: grave, aunque haya durado 40 minutos y no haya afectado a ningún cliente. Además, si había datos personales, hay que valorar por separado la notificación a la AEPD en 72 horas por el RGPD.

Es el caso que más se clasifica mal: quien solo mira clientes, duración y dinero lo deja como menor.

Caso 3. Caída del portal de ACME por su proveedor de nube

El proveedor de nube de ACME tiene una avería. El portal de clientes, que sustenta una función esencial, cae 90 minutos. Se ven afectados el 8 % de los clientes del portal y un periódico regional lo publica.

  • Puerta: pasa.
  • Interrupción: 90 minutos, por debajo de las 2 horas. No cumple.
  • Clientes: 8 %, por debajo del 10 %, y menos de 100 000. No cumple.
  • Reputación: ha salido en los medios. Un criterio.
  • Resultado: no es grave. Solo un criterio. Pero hay que registrarlo con su causa, porque puede contar como incidente recurrente.

Que el fallo sea del proveedor no cambia nada: la entidad clasifica el impacto en sus propios servicios.

Caso 4. El mismo fallo, siete semanas después

Siete semanas más tarde, la misma avería del mismo proveedor vuelve a tirar el portal: 70 minutos y el 6 % de los clientes.

Por separado, ninguno de los dos es grave. Pero el artículo 8.2 dice que los incidentes recurrentes son graves cuando se cumplen las tres condiciones:

  • han ocurrido al menos dos veces en seis meses: sí;

  • tienen la misma causa subyacente aparente: sí;

  • juntos cumplen los criterios de incidente grave: los clientes afectados suman un 14 %, por encima del 10 %, y la reputación ya se cumplió con el primero. Dos criterios.

  • Resultado: grave como incidente recurrente.

La revisión de recurrentes es mensual, y no se aplica a las microempresas ni a las entidades del artículo 16.1 de DORA.

Mi criterio para sumar incidentes recurrentes

La norma dice que los incidentes recurrentes son graves si «colectivamente» cumplen los criterios, pero no dice cómo se suman. Ahí cada entidad tiene que decidir, y esta es la regla que yo aplico:

  • Lo que se cuenta, se suma: clientes, contrapartes, transacciones y costes de todos los incidentes de la serie. Si un cliente aparece en dos incidentes, se cuenta una vez.
  • Lo que es un sí o un no, basta con que pase una vez: si cualquiera de los incidentes salió en los medios o tocó otro Estado miembro, la serie cumple ese criterio.
  • La duración no se suma. Dos caídas de 70 minutos no son una de 140: se mira cada incidente por separado. Sumarlas convertiría en grave cualquier fallo intermitente, y no creo que esa sea la intención de la norma.
  • Ante la duda, se notifica. Notificar de más cuesta un informe. No notificar algo que el supervisor consideraba grave cuesta una explicación mucho más larga.

Sea cual sea tu criterio, déjalo por escrito antes de necesitarlo y aplícalo siempre igual. Lo que un supervisor no acepta es un criterio que cambia según convenga.

Caso 5. Un proceso nocturno que duplica cargos

Un error en el proceso por lotes de domiciliaciones de ACME duplica 2 000 cargos. El proceso corrió a la 01:00; se detecta a las 09:00 y se corrige a las 07:00 del día siguiente, 30 horas después de producirse. Muchos clientes llaman a quejarse. Las devoluciones y compensaciones cuestan 40 000 EUR.

  • Puerta: afecta a un servicio financiero que requiere autorización. Pasa.
  • Clientes y transacciones: 2 000 cargos frente a una media diaria de 60 000 son un 3,3 %; en valor, también por debajo del 10 %. No cumple.
  • Duración: 30 horas, contadas desde que se produjo a la 01:00, no desde que se detectó. Más de 24 horas. Un criterio.
  • Reputación: quejas reiteradas de distintos clientes. Segundo criterio.
  • Económico: 40 000 EUR, por debajo de 100 000. No cumple.
  • Resultado: grave.

Si la duración se hubiera contado desde la detección, serían 22 horas y el resultado cambiaría. Por eso importa medir desde el primer registro.

Si es grave: plazos de notificación

Los fija el Reglamento Delegado (UE) 2025/301, en su artículo 5:

InformePlazo
Notificación inicialLo antes posible y como máximo 4 horas desde que lo clasificas como grave, sin pasar de 24 horas desde que tuviste conocimiento. Si lo clasificas como grave más tarde de esas 24 horas, 4 horas desde la clasificación
Informe intermedioComo máximo 72 horas desde la notificación inicial, aunque no haya cambiado nada. Se actualiza sin demora indebida y, en todo caso, cuando se recupera la actividad normal
Informe finalComo máximo un mes desde el último informe intermedio
  • Fines de semana y festivos: si el plazo cae en uno, se puede presentar antes del mediodía del siguiente día hábil. No vale para la notificación inicial ni el informe intermedio de entidades de crédito, entidades de contrapartida central, gestores de centros de negociación y entidades esenciales o importantes según NIS2. El supervisor también puede quitárselo a otras entidades significativas.
  • Si no llegas: avisa al supervisor antes de que venza el plazo y explica por qué.
  • A quién: a tu autoridad competente. En España, según el tipo de entidad, el Banco de España, la CNMV o la Dirección General de Seguros y Fondos de Pensiones.

Los errores más frecuentes

  1. Contar dos veces el mismo criterio. Superar a la vez el 10 % y los 100 000 clientes es un criterio, no dos.
  2. Olvidar el atajo del acceso malintencionado. Un acceso no autorizado que puede causar pérdida de datos es grave por sí solo, aunque no afecte a clientes.
  3. Medir la duración desde la detección. Se mide desde que se produjo, si los registros lo muestran. Ojo: el plazo de 24 horas para notificar sí corre desde que tienes conocimiento.
  4. No registrar los incidentes menores. Sin un registro con la causa de cada uno, la revisión mensual de recurrentes es imposible.
  5. Mal cálculo del coste. Meter las primas de seguro o el proyecto de mejora posterior, o descontar lo que paga el seguro.
  6. Esperar a tener certeza. La norma permite estimar y reclasificar después. La notificación inicial incluso tiene un campo para informar de la reclasificación de grave a no grave.

Cómo dejarlo resuelto antes de que pase

La clasificación se decide en la primera hora, y en la primera hora nadie tiene tiempo de buscar datos. Lo que funciona es tenerlos preparados:

  • El mapa de servicios esenciales: qué servicios sustentan funciones esenciales o importantes, sobre qué sistemas y con qué proveedores.
  • Las líneas base de cada servicio: clientes que lo usan, contrapartes, y número y valor medio diario de transacciones. Sin ellas no puedes calcular un 10 % de madrugada.
  • Una hoja de clasificación con los seis criterios y la hora de cada decisión, para poder justificar después por qué se clasificó así y cuándo.
  • Un registro de todos los incidentes con su causa, para la revisión mensual de recurrentes.

En Almenara, el módulo de Incidentes cruza el incidente con el inventario y el análisis de impacto, propone la clasificación con estos criterios y lleva los plazos por ti. Si quieres ver cómo se vive un caso así, la demo «Cae tu proveedor de nube» lo recorre de principio a fin. Y en la guía de DORA tienes el resto de obligaciones.

Preguntas frecuentes

¿Un incidente que no afecta a ningún cliente puede ser grave?

Sí. Un acceso malintencionado y no autorizado a los sistemas de la entidad que puede causar pérdida de datos es grave por sí solo, aunque no haya clientes afectados ni interrupción del servicio (caso 2).

¿Cuántos criterios hacen falta para que un incidente sea grave en DORA?

Dos o más de los umbrales del artículo 9 del Reglamento Delegado 2024/1772, siempre que el incidente afecte a servicios esenciales. La excepción es el acceso malintencionado con posible pérdida de datos, que basta por sí solo.

¿Desde cuándo corren las 24 horas para notificar?

Desde que la entidad tiene conocimiento del incidente. Dentro de ese margen, la notificación inicial debe enviarse como máximo 4 horas después de clasificarlo como grave.

¿Si el fallo es de mi proveedor TIC, también tengo que notificarlo?

Sí, si cumple los criterios. La entidad financiera clasifica el impacto en sus propios servicios, sea cual sea el origen del fallo (caso 3).

¿Qué pasa si lo clasifico como grave y luego resulta que no lo era?

Puedes reclasificarlo. La notificación inicial y los informes recogen la reclasificación de grave a no grave. Es mejor notificar con estimaciones que esperar a tener todos los datos y pasarse del plazo.

¿Qué es un incidente recurrente en DORA?

Dos o más incidentes en seis meses, con la misma causa subyacente aparente, que por separado no son graves pero juntos cumplen los criterios. Se revisan cada mes. La regla no se aplica a las microempresas.

¿Hay que notificar también las ciberamenazas?

Solo voluntariamente. El artículo 10 del Reglamento Delegado 2024/1772 define cuándo una ciberamenaza es importante, y el Reglamento Delegado 2025/301 fija qué debe contener esa notificación voluntaria.

Este artículo tiene fines informativos y no constituye asesoramiento jurídico. Consulta con un profesional del derecho para aplicar estas obligaciones a tu situación concreta.

J

José Ramón Santos Crespo

Fundador de Almenara. Trabaja en gobierno, riesgo y cumplimiento de ciberseguridad y prepara organizaciones para sus auditorías.

Para empezar a orientarte

¿Quieres verlo aplicado a tus proveedores?

Una reunión con tus propios cuestionarios y evidencias, no una presentación genérica.

Solicitar información