DORA afina la letra pequeña que de verdad dolerá: las ESAs cierran el segundo paquete técnico y suben la presión sobre incidentes, TLPT y terceros TIC

La noticia se publicó en julio de 2024, pero su impacto se está jugando ahora, en 2026, cuando ya no sirve esconder el retraso detrás de un PowerPoint con flechas azules. EBA, EIOPA y ESMA remitieron a la Comisión Europea el segundo bloque de estándares y guías de DORA, y ese paquete es justo el tipo de texto que muchas entidades subestimaron: no cambia el discurso político, cambia el trabajo de verdad.

Traducido al castellano operativo: aquí se concreta cómo se reportan los incidentes TIC graves, cómo se ejecutan las pruebas de penetración guiadas por amenazas, cómo se articula la supervisión sobre terceros TIC críticos y cómo se estima el coste agregado anual de los incidentes. Es decir, el corazón incómodo de DORA. No la parte que queda bien en la memoria anual, sino la que obliga a seguridad, operaciones, cumplimiento, compras y consejo a hablar el mismo idioma sin improvisar demasiado.

El paquete, publicado por las tres Autoridades Europeas de Supervisión el 17 de julio de 2024, incluye cuatro proyectos finales de RTS, un ITS y dos guías. Los textos cubren: el contenido, formato, plantillas y plazos del reporte de incidentes TIC graves y amenazas cibernéticas significativas; los RTS sobre las condiciones para las actividades de oversight; los criterios para la composición del joint examination team o JET; los RTS sobre threat-led penetration testing o TLPT; y dos guías, una sobre estimación de costes y pérdidas agregadas por incidentes TIC graves y otra sobre cooperación de supervisión. Las consultas públicas se celebraron entre el 8 de diciembre de 2023 y el 4 de marzo de 2024, con más de 364 respuestas, más otras 9 respuestas en la consulta separada sobre JET. No es una anécdota burocrática: ese volumen de comentarios indica dónde dolía el texto.

La pregunta útil en 2026 no es si DORA ya está aquí. Eso se acabó. La pregunta es otra: ¿tu entidad ha traducido estos productos de nivel 2 a procesos auditables, contratos exigibles y decisiones de gobierno? Porque si la respuesta es “más o menos”, el problema no es regulatorio. Es ejecutivo.

Lo que realmente añade este segundo paquete

DORA como reglamento base ya fijó las grandes obligaciones: gestión del riesgo TIC, notificación de incidentes, pruebas de resiliencia digital, gestión del riesgo de terceros proveedores TIC e intercambio de información. Eso está en el Reglamento (UE) 2022/2554 y no era precisamente un secreto. Lo que faltaba era la mecánica fina. Y la mecánica fina es donde nacen los incumplimientos.

El segundo paquete aterriza sobre todo tres frentes.

El primero es el reporting de incidentes TIC. DORA dedica sus artículos 17 a 23 a la gestión, clasificación y notificación de incidentes relacionados con las TIC. El reglamento ya exigía procesos para detectar, gestionar y notificar incidentes importantes, y contemplaba la notificación voluntaria de ciberamenazas significativas. Pero una cosa es decir “debes reportar” y otra decidir qué campos rellenas, cuándo lo haces, qué constituye una actualización intermedia y cómo garantizas consistencia entre negocio, seguridad, legal y regulatorio. Ahí entran el RTS y el ITS de este paquete.

El segundo frente es el TLPT, el terreno favorito de quienes disfrutan pronunciando “TIBER” en comités donde la mitad de la sala aún cree que un pentest anual y una prueba de phishing ya cuentan como resiliencia avanzada. No. DORA, en sus artículos 26 y 27, exige un programa de pruebas de resiliencia digital y prevé que determinadas entidades financieras realicen pruebas avanzadas basadas en amenazas. El RTS publicado por las ESAs baja a detalles sobre alcance, criterios, salvaguardas, testers internos y externos, control de riesgos y validación de resultados.

El tercer frente es el marco de oversight sobre terceros proveedores TIC críticos. Aquí convergen el artículo 28 y siguientes de DORA con un hecho muy simple: una parte creciente del riesgo operativo del sector financiero ya no vive dentro del perímetro clásico de la entidad. Vive en proveedores cloud, procesadores, infraestructuras de pagos, servicios de identidad, plataformas de datos, software de seguridad gestionada y cadenas de subcontratación que no siempre soportan demasiada luz. Los RTS sobre condiciones de supervisión y composición del JET, junto con las guías de cooperación, construyen la maquinaria que permitirá a las autoridades supervisar de forma más coordinada a esos terceros críticos.

Hay una cuarta pieza menos vistosa pero nada menor: las guías para estimar costes y pérdidas agregadas anuales causadas por incidentes TIC graves. Si esto te suena administrativo, cuidado. Cambia cómo se documenta el impacto económico, cómo se consolida la información en grupos complejos y cómo se prepara una conversación con supervisor en la que ya no basta decir “el incidente fue contenido”. La pregunta será “¿cuánto costó, cómo lo calculaste y qué dejaste fuera?”

Incidentes TIC: el gran choque entre regulación y realidad de operaciones

La parte de incident reporting será, para muchas entidades, la más ingrata. También la más fácil de revisar por un supervisor. El reglamento base ya era claro: DORA exige clasificación de incidentes TIC y reporte de los graves, con criterios armonizados a nivel UE. El artículo 18 se centra en la clasificación de incidentes y ciberamenazas; el artículo 19, en la notificación de incidentes graves; el artículo 20, en la armonización del contenido y plantillas; y el artículo 21, en la centralización de reportes por las autoridades competentes cuando corresponda. Eso estaba escrito. Lo que faltaba era el molde exacto.

Ese molde importa porque el mayor fallo práctico no suele ser detectar el incidente, sino construir un relato regulatorio consistente mientras el incidente sigue vivo. Seguridad ve indicadores técnicos. Operaciones mira disponibilidad. Negocio mide clientes afectados. Legal pregunta si hay datos personales y si se activa GDPR art. 33. Cumplimiento intenta reconciliar plazos. Comunicación ya está redactando algo con demasiados adjetivos. Y el regulador, con bastante razón, quiere una secuencia coherente y comparable.

El RTS y el ITS sobre incidentes intentan cerrar esa brecha con plantillas, taxonomía y hitos temporales. Aunque el texto fuente de ESMA resumía el paquete en términos generales, el mensaje de fondo era nítido: el reporte debe ser más claro, más estructurado y más homogéneo. No es cosmética. Tiene tres consecuencias operativas muy concretas.

Primera consecuencia: DORA obliga a reconciliar DORA con GDPR, NIS2 y marcos sectoriales internos

Si una entidad sufre una indisponibilidad grave por ransomware y hay riesgo para datos personales, el caso no se queda dentro de DORA. GDPR art. 33 exige notificar a la autoridad de protección de datos la brecha de seguridad de los datos personales en un plazo de 72 horas desde que el responsable tenga constancia, salvo que sea improbable que constituya un riesgo para los derechos y libertades de las personas físicas. Si además la entidad cae dentro de NIS2 por su condición o por actividades cubiertas a través de infraestructuras críticas o servicios relevantes, entran también los deberes de notificación de la Directiva (UE) 2022/2555, especialmente su art. 23, con alerta temprana en 24 horas, notificación en 72 horas y reporte final en un mes tras conocer el incidente significativo.

¿Ves el choque? DORA no vive solo. La entidad necesita una capa de orquestación regulatoria capaz de decidir, con base documental, si un mismo hecho activa uno, dos o tres canales distintos, con definiciones no idénticas y relojes que no siempre arrancan exactamente igual. Quien siga gestionando esto con hojas de cálculo y correos entre equipos está pidiendo una observación del supervisor por escrito. Y con razón.

Segunda consecuencia: el dato de impacto ya no puede improvisarse

Cuando DORA y las guías de costes y pérdidas piden consistencia, están diciendo algo muy poco glamuroso y muy exigente: debes poder demostrar cómo calculaste impacto financiero, clientes afectados, duración, servicios críticos comprometidos, costes de respuesta, recuperación, comunicaciones, asesoramiento externo, pérdida de ingresos, reclamaciones y quizá efectos reputacionales si el método lo soporta. No vale lanzar una cifra de daños “aproximada” en una call y corregirla diez días después sin trazabilidad.

Para una entidad mediana o grande, eso exige al menos cinco piezas de gobierno de datos internas: un catálogo de tipologías de costes, criterios de inclusión y exclusión, responsables de validación por función, reglas de consolidación para filiales y un registro de cambios. Parece burocrático hasta que recuerdas que un incidente serio suele mezclar costes de ciberseguridad, tecnología, negocio, atención al cliente, legal, fraude y terceros externos. Si no preparas ese modelo antes del incidente, lo montarás en mitad del caos. Nada sale bien ahí.

Tercera consecuencia: el supervisor podrá comparar mejor entre entidades

Esta es la pieza que muchos pasan por alto. La armonización de plantillas no solo sirve para que tú rellenes formularios bonitos. Sirve para que las autoridades comparen más fácilmente patrones, tiempos de contención, causas raíz, dependencia de terceros, recurrencia de fallos y calidad de las notificaciones. En otras palabras, mejora la capacidad supervisora para detectar quién controla de verdad y quién solo documenta bien después.

Y eso cambia el juego para el consejo de administración. Bajo DORA, el órgano de dirección tiene responsabilidades directas en la gestión del riesgo TIC; véase el art. 5 sobre gobernanza y organización. Si las notificaciones muestran reiteración, mala clasificación o incapacidad para explicar impacto, el problema no se queda en el SOC. Sube.

TLPT: si tu programa se parece a un pentest ampliado, probablemente no llega

El RTS sobre threat-led penetration testing es quizá el texto técnicamente más interesante del paquete y, para algunas entidades, el más costoso de ejecutar bien. DORA art. 26 exige que las entidades financieras establezcan, mantengan y revisen un programa de pruebas sólido y completo como parte del marco de gestión del riesgo TIC. El art. 27 va más allá: determinadas entidades deben realizar pruebas avanzadas basadas en amenazas al menos cada tres años, salvo que el perfil de riesgo o la supervisión exijan otra frecuencia.

Aquí se acabó la confusión interesada. Un TLPT bajo DORA no es un pentest más profundo ni una simple simulación de red team para consumo interno. Requiere inteligencia de amenazas relevante, alcance sobre funciones críticas o importantes, coordinación robusta, protección de la estabilidad operativa y validación formal del cierre de hallazgos. El modelo bebe claramente de experiencias previas como TIBER-EU, pero DORA lo convierte en obligación regulatoria para el subconjunto de entidades que sean designadas.

¿Qué añade este RTS en términos prácticos? Añade disciplina donde más suele faltar.

Primero, obliga a definir mejor el alcance. La tentación habitual es acotar demasiado la prueba para que sea “manejable”. El problema es que una prueba demasiado higiénica produce resultados igualmente higiénicos. DORA quiere pruebas sobre funciones críticas o importantes, no sobre una parcela segura diseñada para no molestar a nadie. Si un servicio depende de identidad federada, conectividad, middleware, APIs con terceros y procesos humanos de escalado, el alcance debe reflejar esa realidad. Lo contrario es teatro caro.

Segundo, introduce una conversación seria sobre terceros implicados. Muchas funciones críticas dependen parcial o totalmente de proveedores TIC. Eso obliga a revisar contratos, ventanas de prueba, cláusulas de cooperación, límites de responsabilidad, uso de intelligence sharing y protocolos de notificación. Aquí DORA se cruza de lleno con el art. 28 y siguientes sobre riesgo de terceros. Una entidad puede tener un TLPT teóricamente impecable y descubrir demasiado tarde que su proveedor crítico no permite determinadas técnicas, no participa en ejercicios coordinados o exige aprobaciones que tardan más que la prueba entera.

Tercero, endurece el requisito de remediación verificable. El valor de una prueba avanzada no está en el informe. Está en cerrar las rutas de compromiso identificadas, revalidar controles y documentar decisiones cuando un hallazgo no se corrige de inmediato. Suena obvio. No lo es. Muchas organizaciones siguen tratando el red teaming como un ritual anual con un informe pesado y una tasa de cierre generosa en apariencia, pero basada en tickets mal definidos, mitigaciones parciales y excepciones que caducaron hace meses.

En 2026, el supervisor esperará algo más sólido: trazabilidad desde el hallazgo hasta el cierre, justificación de riesgos aceptados, validación independiente cuando proceda y capacidad de demostrar que la prueba ha mejorado resiliencia real. Si no, la entidad habrá comprado una experiencia inmersiva de ciberseguridad. Muy entretenida. Poco útil.

Oversight sobre terceros TIC críticos: la parte de DORA que más cambia la política de proveedores

El paquete también avanza una de las piezas más ambiciosas de DORA: la supervisión europea de terceros proveedores TIC críticos. Esto descansa en el capítulo V del reglamento, especialmente en los arts. 28 a 44. La lógica es impecable: si la estabilidad financiera depende de un conjunto concentrado de proveedores tecnológicos, no basta con exigir a cada entidad financiera que gestione sus contratos. Hace falta una capa de supervisión agregada.

Los RTS sobre las condiciones para realizar actividades de oversight y sobre la composición del joint examination team, más las guías de cooperación entre ESAs y autoridades competentes, le ponen músculo a ese diseño. No estamos ante un matiz menor. Estamos ante la base de una supervisión transfronteriza más intrusiva sobre proveedores cuya relevancia sistémica no viene de ser “financieros”, sino de soportar funciones críticas de muchas entidades a la vez.

Aquí hay una ironía regulatoria deliciosa: durante años, buena parte del sector habló de “gestión de terceros” como un asunto de procurement vitaminado con algunas cláusulas de seguridad. DORA responde, con bastante flema europea, que no; que cuando el proveedor concentra dependencias de mercado, deja de ser solo tu proveedor y se convierte en una cuestión de estabilidad sectorial.

Esto importa por cuatro razones.

Concentración y monocultivo tecnológico

DORA no prohíbe la concentración, pero la hace más visible y más gobernable. El art. 29 exige una estrategia sobre riesgo derivado de terceros TIC, incluida la dependencia de proveedores concretos. El art. 30 baja a los elementos contractuales clave. En la práctica, el nuevo marco de oversight aumenta la presión para que las entidades dejen de hablar de “multi-cloud” como slogan y documenten dependencias reales: región, servicio, plano de control, autenticación, herramientas de observabilidad, soporte privilegiado y subcontratistas relevantes.

Muchas entidades descubrieron, al mapear servicios críticos para DORA, que tenían aparente diversificación comercial pero dependencia técnica concentrada. Distintas marcas. Mismo backend. Contratos distintos. Misma fragilidad. Ese tipo de hallazgo no salta en una due diligence superficial.

La cadena de subcontratación sigue siendo el agujero menos fotogénico

La propia nota de las ESAs recordaba que quedaba pendiente el RTS sobre subcontratación. Esa ausencia no era trivial entonces y sigue siendo relevante como señal regulatoria. La subcontratación dentro de la cadena TIC es donde se esconden opacidades molestas: soporte remoto, operaciones de desarrollo, herramientas de terceros embebidas, proveedores de cuarto nivel, acceso privilegiado indirecto. DORA ya obliga a gestionar esto, pero la pendiente del RTS específico mostraba lo complejo que resulta encajar detalle técnico, proporcionalidad y realidad contractual.

En 2026, el mensaje práctico para las entidades es simple: no esperes a que cada inciso de subcontratación te llegue cerrado para revisar contratos, inventario de servicios y derecho de auditoría. El supervisor no premiará la pasividad defensiva.

JET y cooperación supervisora: menos arbitraje, más consistencia

Los criterios para la composición del JET y las guías de cooperación apuntan a un problema muy europeo: varias autoridades, varias jurisdicciones, mismos proveedores, riesgos compartidos. Si esa coordinación falla, el oversight se fragmenta y el proveedor aprende rápido a gestionar supervisores en lugar de gestionar riesgo. Con JET y mecanismos de intercambio de información, DORA intenta reducir ese arbitraje blando.

Para las entidades usuarias, esto significa que ciertas debilidades en proveedores críticos podrán generar una conversación supervisora más coordinada y, por tanto, menos fácil de relativizar. No bastará con decir que “el proveedor ya está trabajando en ello” si el problema afecta a varias entidades y tiene relevancia sistémica.

Compras, legal y seguridad ya no pueden negociar por carriles separados

La letra del art. 30 de DORA sobre contenido contractual mínimo ya era suficientemente clara: descripción de funciones y servicios, lugares de prestación, disponibilidad, integridad, confidencialidad, acceso, recuperación, derechos de terminación, cooperación con autoridades y condiciones de subcontratación, entre otros extremos. El segundo paquete no sustituye esa obligación; la hace más exigente al integrarla en un marco de supervisión más operativo.

La consecuencia interna es dura y bastante sana: procurement no puede cerrar renovaciones críticas sin validación de requisitos DORA; legal no puede negociar cláusulas de auditoría sin entender el modelo operativo del servicio; seguridad no puede exigir controles imposibles de verificar; resiliencia y continuidad no pueden vivir en documentos aparte del contrato. O trabajan juntos o el contrato acaba siendo una ficción jurídica con SLA bonitos y escasa utilidad bajo presión.

Las guías de costes y pérdidas: el detalle aparentemente aburrido que terminará en comité de auditoría

La guía sobre estimación de costes y pérdidas agregadas anuales causadas por incidentes TIC graves es uno de esos textos que nadie presume de haber leído completo y que, sin embargo, puede cambiar la conversación con el regulador y con auditoría interna. ¿Por qué? Porque obliga a construir metodología.

Mientras el mercado hablaba de resiliencia en términos de uptime, recuperación y testing, las ESAs introdujeron una exigencia menos vistosa pero muy reveladora: medir de forma agregada los costes y pérdidas ocasionados por incidentes TIC graves. El regulador quiere visibilidad sobre impacto económico, no solo sobre taxonomía técnica. Tiene sentido. Una resiliencia que no traduce daño financiero es una resiliencia a medias.

Esto fuerza a las entidades a responder preguntas incómodas: ¿qué consideras coste directo? ¿Incluyes horas internas de respuesta? ¿Cómo valoras interrupción parcial de servicio frente a caída total? ¿Cómo separas pérdidas por fraude derivado de un incidente TIC de otras pérdidas operacionales? ¿Consolidas por evento o por campaña? ¿Cómo evitas doble conteo entre filiales y central? Si tu organización no ha definido estas respuestas, no tiene un modelo de pérdidas TIC. Tiene opiniones.

Y ahí entra el comité de auditoría. Porque en cuanto una cifra de pérdidas agregadas alimenta reporting regulatorio, informes de riesgo no financiero, apetito de riesgo, escenarios de continuidad o provisiones relacionadas, deja de ser una nota técnica. Pasa a ser información de gestión que debe ser consistente, defendible y trazable.

También hay una derivada estratégica. Las entidades que midan bien podrán priorizar mejor inversiones de resiliencia. No por miedo al regulador, sino porque empezarán a ver qué clases de incidentes cuestan de verdad: indisponibilidades breves pero masivas, errores de cambio, fallos de autenticación, proveedores con tiempos lentos de restauración, fraude apoyado en fallos de canales digitales o acumulación de deuda técnica en servicios críticos. Sin medición mínimamente sólida, esa conversación termina en intuiciones, y las intuiciones suelen tener mejor marketing que precisión.

Qué cambia para una entidad financiera española en 2026

Para bancos, aseguradoras, gestoras, entidades de pago, emisores de dinero electrónico, infraestructuras de mercado y otros sujetos de DORA en España, el segundo paquete técnico no añade una nueva fecha milagrosa. Añade algo más incómodo: elimina ambigüedad útil.

El Banco de España, la CNMV y la Dirección General de Seguros y Fondos de Pensiones se mueven ya en un ecosistema europeo donde las expectativas supervisoras sobre DORA son mucho más detalladas que en 2024. La coordinación con las ESAs, y en ciertos ámbitos con el BCE y ENISA, hace menos probable que una entidad pueda justificar retrasos estructurales alegando que “faltaba concreción técnica”. A estas alturas, esa coartada caducó.

En España hay además tres focos específicos.

Uno: alta dependencia de terceros TIC en servicios distribuidos

Las entidades españolas, igual que el resto de la UE, han externalizado capas críticas de infraestructura, desarrollo, observabilidad, soporte y experiencia digital. DORA obliga a conocer esa dependencia a un nivel menos decorativo. No basta con inventario de proveedores por gasto o por categoría contractual. Hace falta inventario por función crítica o importante, servicio consumido, subservicios relevantes, flujos de datos, accesos privilegiados, localización y puntos únicos de fallo. Si ese mapa no existe, no hay forma seria de defender clasificación de criticidad ni estrategia de salida.

Dos: convivencia de DORA con GDPR y NIS2 en grupos complejos

Los grupos financieros con filiales tecnológicas, operaciones transfronterizas o servicios compartidos necesitan un modelo integrado de notificación y escalado. Un incidente en un servicio de autenticación puede activar DORA para la entidad regulada, GDPR para el tratamiento de datos personales y obligaciones internas de continuidad para varias filiales al mismo tiempo. Gestionar esto por silos nacionales o por función aumenta el riesgo de mensajes inconsistentes a supervisores y autoridades.

La solución no es crear otra política. Es diseñar una célula de decisión de incidente con mandato claro, criterios de activación documentados y autoridad para cerrar clasificación, materialidad y ruta de reporte en horas, no en días.

Tres: el consejo ya no puede delegar ignorancia

DORA art. 5 y siguientes son incómodamente explícitos con el órgano de dirección. En 2026, un consejo que siga tratando el riesgo TIC como asunto técnico subordinado a un informe trimestral de 20 diapositivas se expone a quedar mal retratado si ocurre un incidente serio o si una inspección pregunta por apetito de riesgo, tolerancias de impacto, dependencias críticas y remediación de hallazgos de testing. El estándar supervisor ya no es “que exista un comité”. Es que el gobierno pueda demostrar comprensión y decisión.

Lo que muchas entidades siguen haciendo mal

Después de dos años de aterrizaje de DORA, todavía se repiten errores bastante previsibles. No todos son fallos técnicos; muchos son de diseño organizativo.

El primero es separar compliance DORA de operación DORA. Hay entidades con gap analysis impecable y escasa capacidad de ejecutar una clasificación de incidente en tiempo real, coordinar una notificación intermedia o forzar a un proveedor crítico a entregar evidencias útiles. El reglamento premia menos el documento y más el músculo.

El segundo es tratar el inventario de terceros como una base de datos de procurement con algunos campos de seguridad añadidos. DORA exige algo más granular: relación entre tercero, servicio, función crítica, dependencia tecnológica, estrategia de salida y controles de monitorización. Si tu inventario no responde a la pregunta “qué función crítica cae si este subservicio falla”, el inventario sirve para compras. No para resiliencia.

El tercero es confundir pruebas con assurance. Un pentest puntual, una simulación de ransomware y un ejercicio de continuidad no equivalen, por acumulación, a un programa de pruebas maduro bajo DORA art. 26. Las pruebas deben estar conectadas con escenarios, riesgos, funciones críticas, terceros y remediación. Si no, generan actividad; no necesariamente resiliencia.

El cuarto es mantener cláusulas contractuales heredadas que chocan frontalmente con DORA art. 30: restricciones al derecho de auditoría, opacidad sobre subcontratación, ventanas de notificación excesivas, obligaciones vagas de cooperación en incidentes o inexistencia de compromisos de soporte en pruebas avanzadas. Muchos de estos contratos fueron aceptables antes. Ahora son deuda regulatoria.

El quinto es subestimar la calidad del dato regulatorio. Cuando llegue una revisión temática o una inspección, los supervisores preguntarán por evidencias: tiempos de detección, clasificación, escalado, decisiones, contenido de reportes, cambios de criterio, mapas de dependencia, resultados de pruebas y remediación. La entidad que no gobierna ese dato llega desordenada a una conversación donde el orden importa mucho.

La Comisión, las ESAs y la trampa del “ya está publicado”

Conviene recordar el siguiente paso institucional que describieron las ESAs en 2024: las guías fueron adoptadas por los Boards of Supervisors de las tres autoridades y los proyectos finales de RTS e ITS se remitieron a la Comisión Europea para su revisión y adopción en los meses siguientes. En apariencia, trámite normal. En la práctica, una fase decisiva, porque convierte diseño supervisor en norma aplicable de nivel 2 una vez culminado el proceso formal.

Muchas organizaciones interpretan este tipo de hitos de forma binaria: o está plenamente adoptado y entonces actuamos, o no lo está y entonces esperamos. Ese reflejo es cómodo, pero poco inteligente. Cuando un paquete llega a ese grado de madurez, la dirección de viaje está básicamente definida. Esperar al último acto formal para empezar a ajustar reporting, testing o contratos con terceros es la manera elegante de convertir un proyecto regulatorio en un programa de remediación bajo presión.

Además, en 2026 el entorno ha seguido endureciéndose. Las ESAs han ido elevando expectativas sobre gobernanza del riesgo TIC, supervisión coherente y, como demostró su comunicación de agosto de 2026 sobre riesgos de frontier AI models en finanzas, están conectando resiliencia digital con nuevas fuentes de riesgo sistémico. DORA no se queda quieto. Se está convirtiendo en la columna vertebral de cómo Europa quiere supervisar la tecnología financiera crítica. Quien aún lo trate como una obligación aislada de compliance se está perdiendo la película.

Qué deberían hacer ahora los equipos de CISO, COO, compliance y legal

Sin caer en plantillas de consultoría con pretensión épica, hay cuatro movimientos que en 2026 siguen marcando la diferencia entre una entidad razonablemente preparada y otra que vive de presentaciones.

El primero es probar el proceso de notificación de extremo a extremo. No un tabletop genérico, sino un ejercicio cronometrado sobre un incidente plausible que fuerce clasificación, activación de DORA, análisis de posible activación de GDPR art. 33 y, si aplica, de NIS2 art. 23, redacción del primer reporte y actualización posterior con datos incompletos. Si el ejercicio tarda horas en decidir quién aprueba qué, ya has encontrado un fallo real.

El segundo es revisar los contratos de terceros TIC críticos y high-risk no solo por cláusula, sino por operabilidad. Tener derecho de auditoría en papel sirve de poco si el proveedor impone preavisos incompatibles con un incidente, niega ciertas evidencias o no soporta participación efectiva en pruebas avanzadas. La pregunta útil es esta: ¿podemos ejercer lo firmado cuando más importa?

El tercero es reconciliar el programa de pruebas DORA con threat intelligence, continuidad y gestión de cambios. Si las pruebas no reflejan escenarios actuales, dependencias de terceros y rutas reales de degradación de servicios críticos, la entidad está testeando una arquitectura imaginaria. Y esa arquitectura nunca cae. Qué alivio.

El cuarto es construir una metodología única para costes y pérdidas TIC, aprobada por riesgo, finanzas, seguridad y cumplimiento. Sin eso, cada incidente terminará midiéndose de una forma distinta y el dato agregado será un collage imposible de defender.

La lectura incómoda: DORA ya no va de cumplimiento, va de credibilidad operativa

El segundo paquete de productos de política bajo DORA no es vistoso. No trae una gran frase para titular congresos. Trae algo más serio: convierte ambiciones regulatorias en requisitos comparables, auditables y, sobre todo, ejecutables. Ahí está su importancia.

La lección para 2026 es bastante cruda. La fase en la que una entidad podía decir “estamos siguiendo de cerca los desarrollos de nivel 2” ya pasó. Ahora toca demostrar que entiende cómo clasifica incidentes, cómo notifica bajo presión, cómo cuantifica pérdidas, cómo somete a prueba sus funciones críticas y cómo gobierna dependencias tecnológicas que no controla del todo pero de las que depende muchísimo.

Ese es el verdadero examen de DORA. No si conoces el acrónimo. Eso lo conoce ya hasta media industria que aún no ha renegociado ni una cláusula crítica. El examen es otro: si mañana falla un proveedor clave, se degrada una función crítica y aparece riesgo de brecha de datos, ¿tu entidad puede responder con disciplina regulatoria y operativa a la vez?

Si la respuesta no es un sí rotundo, el segundo paquete técnico de las ESAs no es lectura opcional. Es la lista de lo que te van a pedir que demuestres.