Los primeros estándares de DORA dejaron de ser teoría hace tiempo: ahora exigen pruebas, no promesas

La parte más incómoda de DORA no es la retórica sobre resiliencia. Es otra cosa: obliga a las entidades financieras a demostrar, con evidencia y no con powerpoints, que saben qué proveedores TIC sostienen sus funciones críticas, cómo clasifican un incidente grave y quién decide qué se notifica y cuándo. Ese es el verdadero golpe de los primeros estándares técnicos publicados por las tres Autoridades Europeas de Supervisión el 17 de enero de 2024.

Dos años y medio después, en 2026, ya no estamos ante un borrador con aroma de consulta pública. Estamos ante la arquitectura operativa que ha convertido la gestión del riesgo TIC en un problema de gobernanza, inventario y trazabilidad. Y eso cambia bastante más de lo que algunos departamentos jurídicos pensaron cuando leyeron DORA por primera vez.

La noticia original anunciaba el primer paquete de normas técnicas de desarrollo bajo el Reglamento (UE) 2022/2554: RTS sobre marco de gestión del riesgo TIC y su versión simplificada, RTS sobre clasificación de incidentes TIC y ciberamenazas significativas, RTS sobre la política de uso de servicios TIC que soportan funciones críticas o importantes, e ITS sobre las plantillas del registro de información relativo a acuerdos contractuales con terceros TIC. La base jurídica citada por las ESAs no era menor: artículos 15, 16.3, 18.3, 28.9 y 28.10 de DORA.

El anuncio de 2024 parecía técnico. En realidad, anticipaba un cambio de fondo. La pregunta ya no es si una entidad tiene una política de terceros o un procedimiento de incidentes. La pregunta es mucho más desagradable: ¿puede demostrar ante su supervisor que el inventario es completo, que la clasificación de incidentes es consistente entre filiales y que el consejo entiende la dependencia real de sus proveedores críticos? Ahí empieza el problema.

Tesis editorial

Mi tesis es simple: este primer paquete de RTS e ITS convirtió DORA en una norma de supervisión basada en evidencia documental y coherencia operativa, no en buenas intenciones. Y eso explica por qué tantas entidades descubrieron tarde que su mayor riesgo no era un ataque sofisticado, sino algo bastante más mundano y bastante más europeo: datos contractuales dispersos, taxonomías incoherentes, líneas de responsabilidad difusas y una dependencia de terceros que nadie había cartografiado de verdad.

Dicho sin maquillaje: muchas organizaciones llevaban años diciendo que gestionaban el riesgo de proveedores, que tenían continuidad de negocio y que notificaban incidentes. Los estándares técnicos han puesto a prueba esa afirmación. Algunas la sostienen. Otras no.

Lo relevante no es solo que DORA art. 28 regule el riesgo de terceros TIC o que el art. 18 obligue a clasificar incidentes importantes. Lo realmente decisivo es que los RTS e ITS bajan al terreno donde fallan los programas de compliance: definiciones, campos de datos, umbrales, gobernanza, consistencia entre documentos y supervisión reutilizable por la autoridad competente. Eso es supervisión de verdad. Lo otro era literatura corporativa.

Qué publicaron exactamente las ESAs y por qué importó más de lo que parecía

El 17 de enero de 2024, EBA, EIOPA y ESMA publicaron cuatro piezas normativas finales en borrador, remitidas después a la Comisión Europea para su adopción. La consulta pública se había abierto el 19 de junio de 2023 y cerró el 11 de septiembre de 2023. Las ESAs recibieron más de 420 respuestas del mercado. Ese número importa por una razón: no era una consulta cosmética. Había un nivel inusual de preocupación operativa, especialmente por la proporcionalidad, el detalle del registro y el alcance de las obligaciones sobre terceros TIC.

Los cuatro bloques fueron estos:

• RTS sobre el marco de gestión del riesgo TIC y sobre el marco simplificado, desarrollados bajo DORA art. 15 y art. 16.3.
• RTS sobre criterios para la clasificación de incidentes TIC graves y amenazas cibernéticas significativas, bajo DORA art. 18.3.
• RTS sobre la política respecto de servicios TIC que soportan funciones críticas o importantes prestados por terceros, bajo DORA art. 28.10.
• ITS sobre las plantillas del registro de información de los acuerdos contractuales con proveedores terceros TIC, bajo DORA art. 28.9.

Si uno mira esto con ojos de abogado, ve desarrollo normativo. Si lo mira con ojos de CISO, COO o responsable de outsourcing, ve otra cosa: una exigencia de industrializar procesos internos que antes vivían en silos. El registro de terceros ya no puede ser una hoja de cálculo local de compras, el análisis de criticidad ya no puede depender de una entrevista informal y la clasificación de incidentes ya no puede cambiar según el humor del equipo que está de guardia a las tres de la mañana.

El detalle es el mensaje. Los reguladores europeos no publicaron un manifiesto; publicaron instrumentos para comparar entidades entre sí, detectar inconsistencias y escalar la supervisión sobre terceros críticos. Esa era la jugada.

El registro de información: el documento más aburrido de DORA y probablemente el más peligroso si lo haces mal

Si tuviera que apostar por la pieza que más dolor ha causado en 2026, no elegiría la notificación de incidentes. Elegiría el registro de información. Porque obliga a unir piezas que en muchas entidades nunca habían convivido con disciplina: contratación, arquitectura tecnológica, continuidad, seguridad, cumplimiento, datos y cadena de suministro.

DORA art. 28 exige gestionar el riesgo derivado de terceros TIC. Pero el ITS sobre el registro convierte esa obligación general en un artefacto supervisable. La entidad tiene que mantener y actualizar información sobre sus acuerdos contractuales con proveedores terceros TIC. Y no se trata de guardar contratos en una carpeta. Se trata de estructurar datos que permitan a la autoridad entender dependencias, concentración, criticidad y capacidad de sustitución.

Aquí aparece una de las paradojas favoritas de cualquier regulador europeo: el documento parece administrativo, pero sus consecuencias son estratégicas. Un registro mal hecho no solo expone incumplimiento formal. También revela que la entidad no sabe con precisión:

• qué servicios TIC sostienen funciones críticas o importantes;
• qué proveedores intervienen de forma directa e indirecta;
• dónde hay concentración tecnológica o contractual;
• qué jurisdicciones afectan al servicio, al soporte o al tratamiento de datos;
• qué cláusulas contractuales faltan para continuidad, acceso, auditoría, salida o cooperación supervisora.

En otras palabras, el registro funciona como una radiografía de madurez operativa. Si la radiografía sale mal, el problema rara vez es el Excel. El problema es la anatomía.

El propio comunicado de ESMA subrayó que el registro jugaría un papel crucial tanto para la supervisión del cumplimiento de DORA como para la designación de proveedores TIC críticos sometidos al régimen de oversight. Eso significa que no estamos ante una obligación de archivo. Estamos ante una fuente estructurada de inteligencia supervisora.

Tu entidad ya lo tiene resuelto. Seguro. Hasta que descubre que un servicio relevante depende de un integrador, que a su vez depende de un hyperscaler, que a su vez distribuye cargas entre regiones, y que nadie ha documentado con precisión qué función crítica queda afectada si falla una parte concreta de esa cadena. Bienvenidos al verdadero problema del outsourcing TIC en 2026.

La política sobre terceros TIC: DORA no prohíbe depender de proveedores; prohíbe depender a ciegas

Otra lectura superficial de DORA ha sido pensar que el reglamento castiga el uso de terceros. No. Lo que castiga es la dependencia no gobernada. Los RTS sobre la política de servicios TIC que soportan funciones críticas o importantes, desarrollados al amparo de DORA art. 28.10, van precisamente de eso.

La obligación práctica es establecer arreglos de gobernanza, gestión del riesgo y control interno para todo el ciclo de vida del acuerdo contractual con el proveedor. Desde la debida diligencia previa hasta la salida. Y ese ciclo de vida, cuando se examina bien, es donde más se acumulan ficciones corporativas.

La primera ficción: la entidad cree que conoce a sus proveedores críticos porque conoce sus nombres comerciales. No basta. Hay que entender el servicio concreto, la función que soporta, la integración con procesos internos, los subcontratistas relevantes y el impacto de una disrupción.

La segunda ficción: el contrato estándar protege a la entidad. A veces sí. A veces el contrato está lleno de cláusulas bonitas y vacío de mecanismos ejecutables. Un derecho de auditoría sin capacidad real de ejercerse a escala o un derecho de terminación sin plan de salida no vale demasiado cuando llega el incidente.

La tercera ficción: la continuidad se resuelve con un BCP genérico. DORA no compra esa idea. Si el servicio sostiene una función crítica o importante, la entidad debe permanecer en control de su riesgo operacional, su seguridad de la información y su continuidad de negocio a lo largo de toda la relación contractual.

Eso tiene varias derivadas operativas nada menores en 2026:

• la clasificación de funciones críticas o importantes debe ser defendible y consistente con la lógica de continuidad y tolerancia al impacto;
• la due diligence sobre el proveedor no puede quedarse en un cuestionario comercial de 40 preguntas recicladas de hace cinco años;
• los mecanismos de salida y sustitución deben estar conectados con pruebas reales, no solo con una cláusula contractual decorativa;
• la supervisión del suboutsourcing deja de ser una nota a pie de página.

El problema es que muchas entidades financieras europeas han construido su stack digital sobre capas de externalización. No por irresponsabilidad, sino porque era eficiente. DORA no desmantela ese modelo. Lo pone bajo luz blanca. Y la luz blanca no favorece a nadie.

La clasificación de incidentes: cuando un incidente deja de ser “tema de IT” y se convierte en asunto de consejo

Los RTS sobre clasificación de incidentes TIC graves, vinculados a DORA art. 18.3, son probablemente la pieza más visible porque conectan con plazos de notificación y gestión de crisis. Pero su importancia real va más allá del reporte regulatorio.

Las ESAs indicaron que estos RTS especifican los criterios para clasificar incidentes graves, el enfoque de clasificación, los umbrales de materialidad para cada criterio, los criterios y umbrales para amenazas cibernéticas significativas, así como los elementos que permiten valorar la relevancia transfronteriza para otras autoridades competentes. Traducido al castellano llano: los supervisores quieren que dos entidades no llamen “grave” y “no grave” a incidentes equivalentes según conveniencia interna.

Esto ataca un problema clásico de la gobernanza tecnológica: la subjetividad. En demasiadas organizaciones, la severidad del incidente se mezcla con incentivos reputacionales, presión comercial o miedo a escalar. DORA intenta cerrar ese espacio mediante criterios armonizados. No elimina el juicio experto, pero sí acota el margen para el maquillaje.

El impacto en la práctica es muy concreto:

• hay que alinear taxonomías de incidentes entre seguridad, operaciones, continuidad, riesgo y cumplimiento;
• los playbooks de respuesta deben incluir el análisis regulatorio desde el minuto uno, no al final;
• la captura de evidencias durante el incidente debe soportar después la clasificación y la notificación;
• los equipos de crisis necesitan saber qué umbrales disparan obligaciones regulatorias, no solo técnicas.

Esto conecta con una realidad incómoda de 2026: la mayoría de incidentes complejos no son puramente “ciber” ni puramente “operacionales”. Son híbridos. Un fallo de proveedor cloud, una degradación de autenticación, un error de cambio en producción o una interrupción causada por software de terceros puede acabar afectando disponibilidad, integridad, continuidad y cumplimiento a la vez. DORA obliga a tratar esa complejidad de forma estructurada.

Y aquí viene la parte interesante: DORA no pide perfección. Pide un proceso gobernado y auditable para decidir. Si una entidad puede demostrar criterios claros, responsables definidos, trazabilidad temporal y racional de clasificación, su posición supervisora mejora incluso cuando el incidente ha sido serio. Si no puede hacerlo, el problema ya no es solo el incidente. Es la gobernanza.

El marco de gestión del riesgo TIC: el artículo 15 dejó de ser abstracto

DORA art. 15 establecía la obligación de contar con un marco sólido, integral y bien documentado de gestión del riesgo TIC. Hasta ahí, cualquiera puede asentir con la cabeza. Los RTS publicados por las ESAs hicieron algo más útil: concretaron elementos de herramientas, métodos, procesos y políticas, y además desarrollaron un régimen simplificado para entidades de menor escala, riesgo, tamaño y complejidad bajo el art. 16.3.

Esto último importa mucho. Una parte del mercado temía que DORA funcionara como una norma de talla única, diseñada mentalmente para grandes grupos bancarios y después arrojada sobre entidades más pequeñas con el mismo entusiasmo con que uno lanza una manta sobre una bicicleta. Los RTS intentaron responder a esa crítica con proporcionalidad.

Pero conviene no malinterpretar la simplificación. Simplificado no significa opcional. Significa que el supervisor admite calibrar la complejidad del marco, no prescindir de sus fundamentos. En 2026, muchas entidades pequeñas han descubierto que el reto no es tener menos controles, sino tener controles trazables que se correspondan con su realidad operativa.

La armonización intersectorial fue uno de los objetivos declarados por las ESAs. Esa armonización tiene una ventaja y un coste. La ventaja es obvia: menos fragmentación entre banca, seguros, mercados y otros subsectores. El coste también: desaparecen algunas zonas grises donde antes cabía defender interpretaciones muy locales o muy sectoriales. DORA busca un lenguaje común de resiliencia operacional. Y un lenguaje común siempre reduce la capacidad de improvisar explicaciones creativas.

La gran consecuencia: DORA ha convertido la resiliencia operativa en un problema de datos maestros

Hay un detalle que apenas se subrayó cuando se publicó el paquete en 2024 y que ahora, en 2026, es evidente: gran parte del cumplimiento efectivo de DORA depende de la calidad del dato interno. No del dato de negocio que llega al mercado. Del dato organizativo que rara vez tuvo glamour: inventarios, taxonomías, propietarios de activos, relaciones contractuales, dependencias de procesos, mapeo de funciones críticas, registros de cambios, pruebas de continuidad, responsables de notificación.

Si ese dato está roto, DORA se rompe con él.

Por eso muchas implementaciones han acabado pareciéndose menos a un proyecto jurídico y más a un programa de saneamiento de datos y gobernanza operativa. Hay entidades que empezaron preguntando por la interpretación del art. 28 y acabaron creando un modelo de datos común para proveedores TIC, servicios, contratos, subcontratistas, procesos y funciones críticas. No era una excentricidad. Era supervivencia regulatoria.

Esto también explica por qué los equipos de compliance que intentaron gestionar DORA sin operaciones, arquitectura, procurement, resiliencia y seguridad terminaron encallando. La norma no se deja encapsular en un control de segunda línea. Exige una vista transversal que muchas organizaciones no tenían institucionalizada.

Impacto regulatorio cruzado

DORA no opera en el vacío. Quien lo trate como una isla regulatoria perderá tiempo, dinero y probablemente paciencia. La intersección con otras normas es donde aparecen duplicidades, tensiones y, bien gestionado, cierto ahorro de esfuerzo.

DORA y GDPR: el incidente no siempre es una brecha de datos, pero a veces lo es en cuestión de horas

GDPR art. 33 obliga a notificar brechas de seguridad de los datos personales a la autoridad de control en un plazo máximo de 72 horas desde que el responsable tiene constancia, salvo que sea improbable que la brecha constituya un riesgo para los derechos y libertades de las personas físicas. DORA, por su parte, se centra en incidentes relacionados con TIC y su clasificación sectorial financiera. No son el mismo universo, aunque a menudo se solapan.

El riesgo operativo aquí es claro: una entidad puede activar el circuito DORA y olvidar durante demasiado tiempo el análisis de datos personales, o al revés. En incidentes que afectan autenticación, banca digital, fraude, indisponibilidad prolongada o exfiltración, los dos regímenes pueden convivir. La organización necesita un mecanismo de triage que separe tres preguntas desde el principio: impacto operativo, impacto en servicios financieros e impacto sobre datos personales.

Si no lo hace, el reloj no se detiene porque el comité interno siga debatiendo si aquello era “realmente un incidente”. El reglamento no tiene tanta paciencia.

DORA y NIS2: dos marcos de resiliencia, dos lógicas supervisoras

NIS2, en particular su art. 21 sobre medidas de gestión de riesgos de ciberseguridad y su régimen de notificación de incidentes, comparte terreno con DORA, pero no persigue exactamente lo mismo. DORA es sectorial y financiero; NIS2 es horizontal para entidades esenciales e importantes de sectores cubiertos. Una entidad financiera puede estar más intensamente encuadrada por DORA, mientras proveedores o terceros del ecosistema pueden caer bajo NIS2.

La consecuencia práctica: no basta con que el banco o aseguradora sea maduro. También necesita entender el grado de madurez regulatoria de proveedores que pueden estar sujetos a NIS2 o no estarlo. Esa asimetría crea fricción contractual y de supervisión. Un proveedor con controles razonables pero sin disciplina de notificación y evidencia al nivel esperado por una entidad DORA puede convertirse en cuello de botella.

Dicho de forma menos diplomática: tu resiliencia no vale más que la del tercero al que le has dado una función importante. DORA lleva años insinuándolo. Los RTS lo convierten en diligencia verificable.

DORA y AI Act: la IA entra por la puerta de proveedores, automatización y clasificación

La IA ya está metida hasta la cocina en banca y seguros este año. No solo en scoring o antifraude. También en SOCs, detección de anomalías, priorización de alertas, asistencia a agentes, revisión documental y automatización de vendor risk. Eso genera una tentación muy humana: delegar en sistemas de IA decisiones que DORA exige gobernar con claridad.

Ahí hay riesgo regulatorio de manual. Si una entidad usa IA para clasificar alertas, priorizar incidentes o evaluar criticidad de proveedores, debería aplicar al menos cuatro controles concretos:

• documentar el propósito exacto del sistema y dónde interviene en el flujo de decisión;
• mantener validación humana efectiva en decisiones que afecten clasificación regulatoria, notificación o evaluación de criticidad;
• probar sesgos operativos y tasas de falso negativo en escenarios de incidente y terceros;
• conservar trazabilidad de inputs, outputs, override humano y justificación.

No hace falta exagerar para ver el problema. Un modelo que minusvalore señales de degradación de servicio o agrupe erróneamente incidentes puede retrasar la escalada regulatoria. Y un sistema que haga scoring de proveedores con datos incompletos puede ofrecer una falsa sensación de control. La IA no arregla un inventario roto. Lo hace más rápido y con gráficos más bonitos.

DORA y eIDAS 2.0: identidad, confianza y dependencia de terceros

Con eIDAS 2.0, la infraestructura de identidad y confianza gana peso estratégico en servicios financieros digitales. Si una entidad depende de servicios de autenticación, firma o validación externa integrados en procesos críticos, esa dependencia debe leerse también bajo la lente de DORA art. 28. La cuestión no es solo la legalidad del servicio de confianza, sino su resiliencia operativa, su continuidad y su encaje contractual.

Cuando autenticación e identidad se externalizan, un fallo ya no es solo técnico. Puede paralizar onboarding, operaciones o acceso de clientes a servicios esenciales. Eso convierte a ciertos proveedores de identidad en piezas especialmente sensibles del mapa DORA.

DORA y NIST CSF 2.0: buen marco de seguridad, insuficiente como respuesta regulatoria

NIST CSF 2.0 sigue siendo útil este año para estructurar funciones, perfiles y prioridades de ciberseguridad. Pero cuidado con la confusión habitual: un programa alineado con NIST CSF 2.0 no equivale por sí solo a cumplimiento de DORA. Ayuda mucho en gobernanza, identificación, protección, detección, respuesta y recuperación. No resuelve, sin adaptación, las exigencias específicas de registro de terceros, clasificación armonizada sectorial ni interacción supervisora financiera.

La lectura inteligente es complementariedad. NIST CSF 2.0 puede ordenar el sistema de control; DORA define qué evidencia, qué alcance sectorial y qué deberes concretos espera el supervisor europeo financiero.

Lo que las entidades españolas deberían mirar dos veces

Para entidades financieras españolas, el efecto de este paquete no es abstracto ni marginal. El supervisor nacional puede pedir consistencia entre lo que la entidad declara bajo DORA y lo que muestra en inspecciones, auditorías internas, outsourcing, continuidad, ciberseguridad y gestión de riesgos operacionales. Y esa consistencia se pone a prueba especialmente en grupos con estructuras societarias complejas, integraciones heredadas o dependencia intensa de proveedores internacionales.

Hay cuatro puntos donde las entidades españolas suelen tropezar más de lo que admiten:

• Inventario contractual incompleto: contratos vivos, anexos técnicos fuera del repositorio central, renovaciones automáticas y servicios realmente consumidos que no coinciden con la taxonomía contractual.
• Clasificación débil de funciones críticas o importantes: definiciones poco homogéneas entre áreas o heredadas de marcos de continuidad que no se alinean bien con DORA.
• Gobernanza de grupo: filiales, sucursales y servicios compartidos con procesos de escalado distintos y ownership poco claro.
• Dependencia cloud e integradores: visibilidad insuficiente del suboutsourcing y de la cadena real de prestación del servicio.

En España, además, la conversación entre riesgo operacional, ciber, continuidad y compliance sigue mejorando, pero no siempre llega a tiempo a la práctica contractual. Ese desfase es justo donde DORA aprieta más.

Qué debería revisar ya una entidad que crea que “esto ya lo tenemos”

Hay una frase especialmente peligrosa en 2026: “esto ya lo tenemos cubierto”. A veces es verdad. A menudo significa que la organización tiene piezas sueltas y asume que forman un sistema. No siempre lo forman.

Si una entidad quiere saber si su posición es sólida frente a estos estándares, debería hacerse preguntas bastante menos cómodas que las habituales:

Sobre el registro de terceros TIC

• ¿Existe una única fuente autoritativa para acuerdos con terceros TIC, o conviven procurement, legal, seguridad y negocio con versiones distintas?
• ¿Cada servicio está vinculado a una función crítica o importante cuando procede, y esa vinculación puede justificarse documentalmente?
• ¿La entidad conoce los subcontratistas relevantes y las jurisdicciones implicadas en prestación, soporte y tratamiento?
• ¿El registro se actualiza con cambios reales de servicio, no solo con hitos contractuales?

Sobre incidentes

• ¿Los criterios de severidad internos encajan con los criterios regulatorios de DORA art. 18 y sus RTS, o son taxonomías paralelas que luego alguien reconcilia a mano?
• ¿Los equipos de primera respuesta saben cuándo involucrar a legal, compliance y privacidad sin esperar al comité de crisis?
• ¿La organización conserva evidencia suficiente del razonamiento que llevó a clasificar un incidente como grave o no grave?

Sobre gobernanza de terceros

• ¿La due diligence precontractual analiza realmente resiliencia, seguridad, continuidad y salida, o es un check administrativo?
• ¿Existen derechos contractuales útiles y ejercitables sobre auditoría, acceso, cooperación e información?
• ¿Hay estrategia de salida para servicios que soportan funciones críticas o importantes, y ha sido probada de alguna forma?

Si la respuesta honesta a varias de estas preguntas es “más o menos”, la entidad todavía no ha terminado el trabajo. Y no pasa nada por admitirlo. Lo que sale caro es fingir lo contrario.

Checklist de evidencias para auditoría

En una materia tan documental como esta, la evidencia manda. No porque lo diga el auditor, sino porque el supervisor y la segunda línea querrán ver rastros verificables. Si la entidad quiere aguantar una revisión seria, estas evidencias suelen ser las primeras en salir a la mesa:

• política aprobada sobre uso de servicios TIC para funciones críticas o importantes, con roles, criterios de aprobación y revisión periódica;
• metodología formal para identificar funciones críticas o importantes y asignarlas a servicios/proveedores;
• registro de información de terceros TIC mantenido en formato estructurado y con control de cambios;
• mapa de dependencias entre procesos de negocio, activos, servicios TIC y terceros relevantes;
• evidencia de due diligence precontractual y reevaluaciones periódicas por riesgo;
• cláusulas contractuales trazables sobre acceso, auditoría, cooperación, incidentes, continuidad, terminación y suboutsourcing;
• procedimiento de clasificación de incidentes alineado con DORA art. 18 y formación a equipos operativos;
• actas de comités, escalados y decisiones de clasificación con sello temporal y responsables identificados;
• resultados de pruebas de continuidad, escenarios de fallo de proveedor y acciones correctoras;
• evidencia de oversight del consejo o del órgano de dirección sobre resiliencia TIC y terceros críticos.

La clave aquí no es acumular documentos. Es poder enlazarlos. Una política sin registro vivo vale poco. Un registro sin vínculo con continuidad vale poco. Un playbook de incidentes sin actas y sin rastro de decisión vale aún menos.

La objeción habitual: “esto es demasiada carga administrativa”

La objeción no carece de base. Sí, DORA aumenta carga documental, necesidad de coordinación y presión sobre funciones de control. Sí, especialmente para entidades medianas y pequeñas, el esfuerzo puede ser notable. Y sí, algunas exigencias del registro o del ciclo de vida de terceros pueden sentirse pesadas cuando el ecosistema proveedor es amplio y cambiante.

Pero la objeción se cae en cuanto se mira la alternativa. El sector financiero europeo ya vivía con una dependencia masiva de proveedores TIC, concentración cloud, interconexión operativa y complejidad transfronteriza. Pretender que eso podía seguir gobernándose con inventarios parciales, contratos poco operativos y taxonomías de incidente inconexas era un acto de fe, no un modelo de control.

DORA añade burocracia. Cierto. También añade visibilidad en un terreno donde la opacidad había sido tolerada durante demasiado tiempo. Y cuando un regulador financiero detecta un riesgo sistémico en la cadena digital, la tolerancia a la opacidad se evapora bastante rápido.

Lo que realmente está en juego en 2026

En 2026, la discusión madura sobre estos estándares ya no es “qué quiso decir el regulador”. La discusión seria es otra: qué entidades han conseguido convertir DORA en un sistema operativo de gobernanza y cuáles siguen tratándolo como una colección de entregables.

Las primeras están usando el trabajo de DORA para limpiar inventarios, endurecer governance, racionalizar proveedores, conectar continuidad con arquitectura y profesionalizar la clasificación de incidentes. Les cuesta, claro. Pero obtienen un retorno que no siempre se dice en voz alta: mejor visión de dependencia, mejor capacidad de crisis y menos autoengaño interno.

Las segundas están produciendo documentación, pero todavía no han cosido los procesos. Suelen detectarse rápido. El registro no cuadra con procurement. La taxonomía de incidentes no cuadra con el SOC. La clasificación de funciones críticas cambia según quién pregunte. El consejo recibe dashboards, pero no decisiones incómodas. Mucha presentación. Poca evidencia integrada.

Ese es el verdadero legado del primer paquete de RTS e ITS bajo DORA. No fue un mero desarrollo técnico. Fue el momento en que la resiliencia operativa dejó de ser un ideal abstracto y pasó a ser un examen de consistencia organizativa. Un examen europeo, además: metódico, documental y poco impresionable ante explicaciones creativas.

Y si una entidad todavía cree que esto va solo de compliance, conviene decirlo sin rodeos: no. Va de si conoce su dependencia digital antes de que la descubra el supervisor, el incidente o ambos a la vez. Lo segundo siempre sale peor.