Notificación de incidentes graves bajo DORA: plazos, plantillas y errores que penalizan

Un incidente TIC grave no empieza cuando el CISO abre una incidencia en ServiceNow. Empieza cuando alguien debe decidir si aquello que está ocurriendo supera los umbrales de DORA y activa una obligación regulatoria. Esa decisión tiene reloj propio: cuatro horas desde la clasificación como incidente grave y, en todo caso, veinticuatro horas desde que la entidad tiene conocimiento del incidente.

La diferencia entre ambas referencias temporales no es académica. Una entidad puede tardar varias horas en confirmar el alcance de una intrusión, pero no puede utilizar la incertidumbre como permiso para esperar indefinidamente. DORA exige un proceso documentado de clasificación, una notificación inicial con información todavía incompleta y actualizaciones posteriores. El regulador prefiere una primera comunicación imperfecta a un silencio cuidadosamente redactado.

Desde el 17 de enero de 2025, el Reglamento (UE) 2022/2554 sobre resiliencia operativa digital del sector financiero se aplica a las entidades incluidas en su ámbito. En 2026, el problema ya no es entender que DORA existe. El problema es demostrar, durante una crisis, que la organización sabe identificar un incidente grave, asignar responsabilidades, usar la plantilla correcta y conservar la evidencia que explica por qué notificó —o por qué decidió no hacerlo—.

La pregunta decisiva no es “¿hemos sufrido un ciberataque?”

La pregunta regulatoria es otra: ¿se ha producido un incidente relacionado con las TIC que cumple los criterios de gravedad de DORA? Esa distinción evita dos errores opuestos. El primero es notificar cualquier alerta de seguridad y convertir el canal regulatorio en un buzón de tickets. El segundo es esperar a tener una reconstrucción forense completa antes de comunicar un incidente que ya está afectando a servicios críticos, clientes o datos.

DORA utiliza la categoría de incidente relacionado con las TIC para referirse a un acontecimiento que compromete la seguridad de las redes y sistemas de información, afecta a la disponibilidad, autenticidad, integridad o confidencialidad de los datos, o interrumpe los servicios prestados por la entidad. No todo fallo tecnológico alcanza la categoría de “grave”. Pero un incidente puede ser grave aunque no exista ransomware, exfiltración confirmada ni una imagen cinematográfica de un atacante dentro de la red.

Una caída prolongada del sistema de pagos, una indisponibilidad de la banca digital, la corrupción de datos de negociación o un fallo de un proveedor TIC crítico pueden activar DORA sin que nadie haya visto una demanda de rescate. La resiliencia operativa no se limita a la ciberseguridad ofensiva. También cubre el fallo accidental, la mala configuración, la dependencia tecnológica y la pérdida de capacidad para prestar servicios financieros.

Qué obligan realmente los artículos 17, 18 y 19

Los artículos 17, 18 y 19 del Reglamento DORA forman una cadena. Separarlos es una de las formas más rápidas de diseñar un proceso que funciona en una presentación y falla a las tres de la mañana.

Artículo 17: proceso de gestión y clasificación

El artículo 17 obliga a las entidades financieras a establecer un proceso de gestión de incidentes relacionados con las TIC. Ese proceso debe detectar, registrar, clasificar y notificar los incidentes. También debe permitir que la entidad identifique qué acontecimientos tienen que elevarse al órgano de dirección y cuáles deben comunicarse a la autoridad competente.

La clasificación no puede depender exclusivamente del analista que recibe la alerta. Debe existir una cadena de decisión que conecte operaciones, seguridad, continuidad de negocio, cumplimiento normativo, legal y comunicación corporativa cuando el impacto lo justifique. La razón es sencilla: los criterios de DORA no son puramente técnicos. Para decidir si un incidente es grave hay que saber qué servicios están afectados, cuántos clientes utilizan esos servicios, si existen pérdidas económicas, si se han comprometido datos y si el servicio puede recuperarse dentro de los niveles establecidos.

Artículo 18: criterios para determinar la gravedad

El artículo 18 establece los criterios que deben utilizarse para clasificar los incidentes. Entre ellos figuran el número y la importancia de los clientes o contrapartes afectados, la duración del incidente y del periodo de indisponibilidad, la extensión geográfica, las pérdidas de datos, la criticidad de los servicios afectados y el impacto económico.

El detalle operativo de esos criterios se desarrolla en el Reglamento Delegado (UE) 2024/1772, que especifica los criterios de clasificación de los incidentes relacionados con las TIC y las amenazas cibernéticas significativas. Ahí es donde una política genérica de “incidente crítico” se encuentra con umbrales regulatorios concretos. La entidad debe mapear sus servicios, clientes, transacciones, datos y pérdidas a las variables que utiliza ese acto delegado.

Algunos umbrales se expresan en términos absolutos y otros en proporción al volumen habitual de la entidad o del servicio afectado. Por eso, conservar solo el número de clientes afectados no basta. Hay que saber qué denominador se utilizó, durante qué periodo y con qué fuente de datos. Una interrupción que afecta a 30.000 clientes puede ser material para una entidad y poco representativa para otra; el porcentaje, la criticidad del servicio y el efecto sobre las operaciones completan el análisis.

Artículo 19: notificación a la autoridad competente

El artículo 19 exige notificar los incidentes graves relacionados con las TIC a la autoridad competente pertinente. La notificación inicial debe enviarse lo antes posible y, en cualquier caso, dentro de las cuatro horas siguientes a la clasificación del incidente como grave. Existe además un límite absoluto: no puede superar las veinticuatro horas desde el momento en que la entidad tuvo conocimiento del incidente.

La notificación inicial no es el informe final disfrazado. Su función es proporcionar a la autoridad una primera visión operativa: qué ha ocurrido, qué servicios están afectados, cuál es el impacto conocido, qué medidas se han adoptado y si el incidente sigue activo. La información puede ser preliminar. Lo que no puede ser es deliberadamente vaga.

La notificación intermedia debe remitirse, como regla general, dentro de las setenta y dos horas desde la notificación inicial. Debe actualizar la información disponible y explicar la evolución del incidente, las medidas de respuesta y recuperación, y, cuando sea posible, las causas preliminares y las consecuencias operativas.

La notificación final debe presentarse, por regla general, en el plazo de un mes desde la notificación intermedia. Debe incluir una descripción completa del incidente, sus causas subyacentes cuando se hayan identificado, las medidas de mitigación y las acciones adoptadas para evitar la recurrencia. Si el incidente sigue abierto, la entidad debe facilitar actualizaciones periódicas y presentar el informe final cuando la situación se haya resuelto, conforme al procedimiento aplicable.

Estos plazos no son una secuencia administrativa que empieza cuando el departamento de cumplimiento recibe un correo. El reloj arranca con el conocimiento del incidente y con la decisión de clasificación. Si esa decisión queda atrapada entre el SOC, operaciones y legal durante ocho horas, el retraso ya es parte del problema regulatorio.

El error más caro: confundir conocimiento, clasificación y notificación

DORA contiene tres momentos distintos que muchas organizaciones mezclan:

1. Conocimiento: la entidad tiene información suficiente para saber que se ha producido un incidente relacionado con las TIC.
2. Clasificación: la entidad aplica los criterios del artículo 18 y del Reglamento Delegado (UE) 2024/1772 para decidir si es grave.
3. Notificación: la entidad remite la comunicación inicial, intermedia y final dentro de los plazos del artículo 19 y de las normas técnicas aplicables.

La confusión suele adoptar dos formas. Algunas entidades consideran que el plazo empieza cuando el comité de crisis declara formalmente el incidente. Otras creen que pueden completar la clasificación después de enviar la notificación inicial. La primera práctica puede retrasar la comunicación; la segunda puede generar una notificación sin una base metodológica clara.

La solución no es elegir entre velocidad y rigor. Es diseñar un proceso que documente una clasificación provisional y permita revisarla. El registro debería conservar, como mínimo, la hora de la primera detección, la hora en que el equipo competente confirmó que se trataba de un incidente TIC, la hora de la clasificación como grave, la autoridad destinataria, el responsable de aprobar la comunicación y la justificación de los datos utilizados.

Tu entidad puede reconstruir esos seis momentos con precisión después de un incidente ocurrido en fin de semana? Si la respuesta depende de buscar mensajes en Teams, llamadas privadas y hojas de cálculo locales, la trazabilidad no está preparada para una revisión supervisora.

Los umbrales no se calculan mirando solo al SOC

El SOC suele saber cuándo empezó una intrusión o cuánto tiempo estuvo caído un servicio. No siempre sabe cuántas contrapartes utilizan ese servicio, qué operaciones quedaron pendientes, qué datos estaban sujetos a obligaciones de conservación o qué pérdida económica se materializó. Esa información está repartida entre tecnología, negocio, operaciones, riesgo y finanzas.

Para aplicar correctamente el artículo 18, la entidad necesita un inventario operativo que conecte cuatro capas:

• Servicios: qué procesos financieros dependen de cada aplicación, plataforma, red o proveedor.
• Clientes y contrapartes: cuántos usuarios o entidades resultan afectados y qué importancia tienen para el servicio.
• Datos: qué categorías se han perdido, alterado, expuesto o vuelto inaccesibles.
• Impacto: duración, indisponibilidad, pérdidas, operaciones fallidas, incumplimientos contractuales y alcance geográfico.

El inventario debe estar disponible antes del incidente. Intentar calcularlo durante una crisis produce estimaciones incompatibles entre departamentos. Tecnología puede informar de 90 minutos de indisponibilidad; operaciones puede identificar cuatro horas de transacciones no conciliadas; atención al cliente puede registrar miles de reclamaciones. Los tres datos pueden ser correctos y, juntos, cambiar la clasificación.

La criticidad también importa. Una interrupción breve en un servicio administrativo puede no superar los criterios aplicables, mientras que una interrupción más corta en un servicio esencial para pagos, compensación, liquidación, negociación o acceso de clientes puede exigir una valoración distinta. La política interna no debe limitarse a etiquetas como “P1” o “P2”. Tiene que explicar cómo se traducen esas prioridades técnicas al lenguaje del artículo 18.

Qué debe contener una buena notificación inicial

Las plantillas armonizadas reducen la discusión sobre el formato, pero no resuelven el problema de fondo: la entidad debe tener los datos. El Reglamento de Ejecución (UE) 2025/302 establece normas técnicas de ejecución sobre formularios, plantillas y procedimientos para notificar incidentes graves relacionados con las TIC y amenazas cibernéticas significativas. La plantilla es común; la calidad de la información sigue siendo responsabilidad de la entidad.

Una notificación inicial útil debería permitir a la autoridad responder rápidamente a cinco preguntas:

1. Qué ha ocurrido: tipo de incidente, vector conocido o sospechado y sistemas afectados.
2. Cuándo ocurrió: hora de detección, inicio estimado, primera respuesta y situación actual.
3. Qué servicios están afectados: funciones críticas o importantes, canales y operaciones interrumpidas.
4. Cuál es el impacto: clientes, contrapartes, datos, territorio, transacciones y pérdidas conocidas o estimadas.
5. Qué está haciendo la entidad: contención, recuperación, comunicación a terceros y asistencia de proveedores.

Una frase como “se investiga una anomalía que podría afectar a varios sistemas” no es una notificación informativa. Puede ser una descripción válida durante los primeros minutos de detección interna, pero no debería sobrevivir intacta al envío regulatorio. Si el alcance es desconocido, hay que decir qué se conoce, qué se desconoce, qué hipótesis se están evaluando y cuándo se actualizará la información.

La comunicación inicial debe evitar también la falsa precisión. Indicar que se han visto afectados exactamente 48.216 clientes cuando el dato procede de una consulta incompleta puede ser peor que informar de una estimación de 45.000 a 50.000, acompañada de la metodología y de un compromiso de actualización. La precisión regulatoria no consiste en poner muchos decimales; consiste en distinguir hechos confirmados, estimaciones y cuestiones pendientes.

La armonización con NIS2 tiene límites claros

La comparación con NIS2 es inevitable porque ambas normas utilizan plazos escalonados y exigen una respuesta documentada. Pero tratarlas como si fueran dos formularios intercambiables es una mala idea.

El artículo 23 de la Directiva NIS2 establece, para las entidades incluidas en su ámbito, un aviso temprano en veinticuatro horas desde que se tiene conocimiento de un incidente significativo, una notificación del incidente en setenta y dos horas y un informe final en el plazo de un mes. DORA, en cambio, exige para los incidentes graves un plazo inicial de hasta cuatro horas desde la clasificación y, en todo caso, veinticuatro horas desde el conocimiento. El nivel de urgencia y la lógica de clasificación no son idénticos.

El artículo 4 de NIS2 contiene reglas de relación con actos jurídicos sectoriales de la Unión. Para las entidades financieras sujetas a DORA, DORA opera como régimen sectorial específico para los requisitos que cubre, incluida la notificación de incidentes TIC. Eso no significa que toda obligación de NIS2 desaparezca automáticamente para cualquier empresa que trabaje con una entidad financiera. Un proveedor tecnológico, una empresa de servicios digitales o una entidad perteneciente a otro sector crítico puede seguir estando sujeta a NIS2 por derecho propio.

La diferencia práctica es decisiva en grupos empresariales. Un banco puede notificar un incidente grave bajo DORA a su autoridad competente, mientras que una filial tecnológica o un proveedor no financiero puede tener que activar un canal NIS2 ante el CSIRT o la autoridad nacional correspondiente. Si el grupo utiliza un único procedimiento, debe indicar qué entidad comunica a qué organismo y bajo qué base jurídica. “Ya lo ha notificado el grupo” no es una categoría legal.

También deben coordinarse las obligaciones de protección de datos. Si el incidente implica una violación de datos personales, el artículo 33 del RGPD puede exigir notificación a la autoridad de protección de datos en un plazo de setenta y dos horas desde que el responsable tiene conocimiento, salvo que sea improbable que exista un riesgo para los derechos y libertades. Si el riesgo es alto, el artículo 34 puede exigir comunicación a las personas afectadas. DORA no sustituye esas obligaciones, y el envío de una notificación DORA no demuestra por sí solo que se haya evaluado el RGPD.

La organización debe mantener un mapa de destinatarios, criterios y plazos. No hace falta enviar el mismo texto a todos los reguladores; sí hace falta que todas las comunicaciones describan hechos compatibles. Una cronología que cambia entre la notificación DORA, la comunicación RGPD y el informe a NIS2 invita a preguntas que nadie quiere responder durante una inspección.

Proveedores TIC: el incidente rara vez llega con una etiqueta DORA

La dependencia de terceros complica la identificación del momento de conocimiento. Un proveedor puede informar de una “degradación del servicio” sin confirmar si existe un incidente de seguridad. Puede comunicarlo primero a un gestor de cuenta, después al equipo de compras y finalmente al responsable de seguridad. Mientras tanto, el reloj de la entidad financiera puede haber empezado.

El artículo 28 de DORA exige gestionar el riesgo de terceros proveedores de servicios TIC. Esa obligación no se cumple incluyendo una cláusula genérica de notificación de incidentes en el contrato. El acuerdo debe permitir recibir información suficientemente rápida y detallada para que la entidad pueda valorar los criterios del artículo 18, activar sus procedimientos y cumplir el artículo 19.

Los contratos y procedimientos con proveedores deberían resolver, al menos, estas cuestiones:

• qué evento debe notificarse, aunque el proveedor todavía no haya confirmado la causa;
• cuál es el punto de contacto operativo disponible fuera del horario comercial;
• qué datos iniciales deben facilitarse y con qué frecuencia se actualizarán;
• cómo se calcularán la duración, los clientes afectados y la indisponibilidad;
• qué asistencia prestará el proveedor para el informe final y el análisis de causa raíz;
• cómo se conservarán evidencias, registros y comunicaciones para la autoridad competente.

Los proveedores críticos de servicios TIC designados bajo DORA están sujetos además a la supervisión de las autoridades europeas de supervisión mediante el marco de supervisión de terceros. Pero esa supervisión no transfiere la responsabilidad de notificar de la entidad financiera. El banco, asegurador o empresa de inversión sigue teniendo que saber qué le ocurrió a su servicio y comunicarlo a su autoridad.

La gobernanza decide si cuatro horas son viables

Un proceso de notificación que requiere la firma de seis personas no es un proceso de cuatro horas. La aprobación debe estar delegada con claridad y el órgano de dirección debe recibir información sin convertirse en una cola de autorizaciones.

El artículo 5 de DORA atribuye al órgano de dirección la responsabilidad última del marco de gestión del riesgo TIC. En materia de incidentes, eso se traduce en decisiones concretas: quién puede clasificar un incidente como grave, quién puede aprobar la notificación inicial, quién sustituye al responsable durante festivos y cómo se informa al órgano de dirección sin bloquear la respuesta.

La función de cumplimiento no debería escribir sola la notificación. Tampoco debería dejarla por completo en manos del SOC. La mejor práctica es un modelo de redacción conjunta: seguridad aporta la cronología técnica, operaciones describe el efecto sobre los servicios, negocio cuantifica clientes y transacciones, riesgo estima el impacto, legal coordina las obligaciones concurrentes y cumplimiento verifica el encaje regulatorio y la trazabilidad.

El simulacro útil no consiste en leer un procedimiento. Consiste en poner a prueba un caso ambiguo: un proveedor cloud informa de una interrupción, los sistemas se recuperan tras dos horas, aparecen datos inconsistentes en una cartera y todavía no se sabe si hubo acceso no autorizado. El ejercicio debe medir cuánto se tarda en obtener los datos del artículo 18, quién decide, qué información entra en la primera plantilla y cuándo se actualiza.

Qué evidencias pedirá una revisión supervisora

La autoridad no solo mirará el PDF enviado. Querrá entender cómo se tomó la decisión. Por eso, el expediente del incidente debería incluir la alerta original, los registros de monitorización, la cronología de decisiones, la matriz de clasificación aplicada, los datos utilizados para calcular clientes y duración, las aprobaciones, las versiones de la notificación y la correspondencia con proveedores.

También conviene conservar los casos que no se notificaron. Un incidente descartado puede ser tan relevante para la supervisión como uno comunicado, especialmente si se repite o si la decisión parece basarse en una descripción subjetiva. El registro debería indicar el criterio evaluado, el umbral no alcanzado, la evidencia utilizada, quién revisó la conclusión y si se estableció una vigilancia adicional.

La consistencia entre inventarios es otra prueba silenciosa. Si el catálogo de servicios críticos dice que una plataforma soporta 400.000 clientes, pero la notificación de un incidente utiliza como denominador 250.000 sin explicación, la autoridad preguntará por la diferencia. Si el análisis de impacto de continuidad fija un objetivo de recuperación de treinta minutos y el incidente permaneció indisponible dos horas sin activar la clasificación, habrá que explicar por qué.

La documentación no necesita convertir cada incidente menor en una tesis doctoral. Sí debe permitir que un tercero reconstruya la decisión sin depender de la memoria de las personas que estaban de guardia. La rotación de equipos hace que la memoria corporativa sea un control bastante poco fiable.

Errores que parecen prudentes y terminan siendo riesgos regulatorios

Esperar a conocer la causa raíz

La causa raíz pertenece sobre todo al informe final. La notificación inicial debe activar la visibilidad supervisora, no esperar a que termine la investigación forense. Si la entidad sabe que un servicio crítico está indisponible y que el impacto supera los criterios aplicables, la falta de atribución del ataque no justifica el retraso.

Utilizar “P1” como sustituto de “grave”

Las prioridades internas sirven para organizar la respuesta, pero no sustituyen la clasificación de DORA. Un P1 técnico puede no ser un incidente grave desde el punto de vista regulatorio; un incidente que no active la máxima prioridad técnica puede afectar a datos, clientes o servicios de forma suficiente para exigir notificación.

Mandar una notificación inicial sin plan de actualización

Una comunicación breve puede ser correcta si identifica las incógnitas y fija el siguiente punto de información. Una notificación vaga que nunca se actualiza transmite falta de control. La plantilla inicial debe estar conectada desde el principio con la notificación intermedia y el informe final.

Delegar el cálculo del impacto al proveedor

El proveedor puede conocer sus sistemas, pero no necesariamente el número de clientes, operaciones o servicios financieros afectados en la entidad. La responsabilidad de clasificar y notificar sigue siendo de la entidad financiera. Los datos del tercero son una entrada, no la conclusión.

Tratar la notificación como un asunto exclusivamente regulatorio

Un incidente grave puede activar obligaciones bajo DORA, RGPD, NIS2, contratos de externalización, continuidad de negocio, prevención del blanqueo o reglas de mercado, según el tipo de entidad y el hecho ocurrido. Un único comité debe coordinar el análisis, pero cada obligación necesita su propia base jurídica y destinatario.

La conclusión incómoda para 2026

DORA no está pidiendo a las entidades que predigan el futuro. Les pide algo menos espectacular y más difícil: que puedan tomar una decisión defendible con información incompleta, dentro de un plazo corto y con responsabilidades claras.

La madurez de un proceso de incidentes se mide en la primera hora. ¿Puede la entidad demostrar cuándo supo que había un incidente? ¿Puede calcular rápidamente qué servicios, clientes y datos están afectados? ¿Tiene una autoridad delegada para enviar la notificación? ¿Puede explicar por qué un evento no se clasificó como grave? ¿Puede coordinar DORA con el artículo 33 del RGPD y, cuando corresponda, con el artículo 23 de NIS2?

Si la respuesta es no, el problema no se arregla comprando otra herramienta de gestión de incidentes. Hace falta conectar el SOC con el inventario de servicios, el mapa de terceros, los datos de clientes, los planes de continuidad y el circuito de gobierno. La plantilla es el último eslabón. La verdadera obligación está en todo lo que debe ocurrir antes de abrirla.

La prueba definitiva será el próximo incidente ambiguo: no el que viene con un ransomware visible y una hora de inicio clara, sino el que mezcla una caída de proveedor, datos inconsistentes, impacto limitado pero crítico y una investigación que todavía no ha terminado. Ahí es donde DORA deja de ser cumplimiento documental y se convierte en una disciplina operativa. Y ahí también se verá qué entidades han preparado una respuesta y cuáles solo han preparado una carpeta.