DORA ya no es un proyecto: ahora el supervisor te pedirá pruebas, contratos y criterio

La excusa de que DORA era “algo que viene” murió hace más de un año. Desde el 17 de enero de 2025, el reglamento aplica. En 2026, la conversación seria ya no va de awareness, ni de slides bonitas para el comité de riesgos. Va de otra cosa: de si una entidad financiera puede demostrar, con evidencias y sin improvisar, que gobierna su riesgo ICT, que conoce de verdad sus dependencias tecnológicas y que no ha firmado con sus proveedores contratos que se deshacen en cuanto entra un supervisor por la puerta.

La página de EIOPA sobre DORA no trae grandes fuegos artificiales. No los necesita. El mensaje relevante está precisamente en la acumulación de piezas: reglamento nivel 1, directiva de ajuste sectorial, RTS, ITS, actos delegados, guías conjuntas y herramientas de reporting. Traducido al castellano llano: la fase de interpretación abstracta se está cerrando y empieza la fase incómoda, la de convertir una norma horizontal en controles operativos auditables.

Ese cambio tiene una consecuencia política y otra práctica. La política es que la resiliencia operativa digital ha dejado de ser un asunto de seguridad informática para convertirse en una materia de gobernanza formal, con consejo, alta dirección y funciones de control metidos hasta el cuello. La práctica es menos elegante: contratos que rehacer, registros de información que mantener, incidentes que clasificar con criterios armonizados y pruebas avanzadas que ya no se pueden despachar con un pentest estándar comprado deprisa y corriendo en diciembre.

Aquí está el quid: DORA no castiga solo la falta de controles. Castiga la ficción de control.

Tesis editorial

DORA es la primera norma europea que obliga al sector financiero a dejar de confundir ciberseguridad con tecnología, outsourcing con compras y resiliencia con continuidad de negocio de presentación en PowerPoint. Su novedad real no es que exija gestionar el riesgo digital; eso ya lo decían otros marcos. Lo decisivo es que une cinco planos que muchas entidades habían mantenido separados por comodidad burocrática: gobernanza, terceros ICT, notificación de incidentes, pruebas avanzadas y supervisión directa de proveedores críticos.

Mi tesis es simple: en 2026, el mayor riesgo de DORA no está en no conocer el texto, sino en seguir operando con estructuras organizativas heredadas que hacen imposible cumplirlo de forma creíble. Si el CISO no controla inventario y arquitectura contractual, si compras sigue negociando como si una cláusula de acceso y auditoría fuera un capricho, si cumplimiento revisa políticas pero no evidencia técnica, y si el consejo recibe métricas cosméticas, la entidad no tiene un problema documental. Tiene un problema de diseño.

Y el supervisor empieza a verlo. DORA no está escrito para premiar el paper compliance. Está escrito para detectar si una entidad sabe qué servicios dependen de qué proveedor, qué ocurre si falla una cadena de subcontratación y quién toma decisiones cuando un incidente deja de ser “técnico” y se convierte en “material”.

Lo que de verdad ha cambiado desde que DORA entró en aplicación

El Reglamento (UE) 2022/2554 entró en aplicación el 17 de enero de 2025. Ese dato ya no sirve como recordatorio de calendario; sirve como línea divisoria. Hasta esa fecha, muchas entidades podían alegar que estaban en transición. En 2026, lo que cuenta es si han aterrizado los requisitos en tres frentes que DORA trata con una precisión inusual para un reglamento horizontal.

Primero, el marco de gestión del riesgo ICT. DORA lo desarrolla en sus artículos 5 a 16 y lo baja a tierra con los RTS sobre el marco de gestión del riesgo ICT, publicados como Reglamento Delegado (UE) 2024/1774. Ahí desaparece la coartada del control genérico. La entidad debe tener mecanismos concretos para identificación, protección y prevención, detección, respuesta y recuperación, aprendizaje y evolución, y comunicación. No basta con que existan funciones; hay que demostrar que funcionan, que tienen responsables y que el órgano de dirección las aprueba, supervisa y revisa.

Segundo, la gestión del riesgo de terceros ICT. DORA dedica a esta materia un bloque central, del artículo 28 al 44, y no por casualidad. El legislador europeo ha entendido algo que durante años se fingió no ver: el riesgo operativo digital del sector financiero ya no reside solo dentro del perímetro de la entidad. Reside en nubes públicas, procesadores, proveedores de software, integradores, plataformas de autenticación, servicios de comunicaciones y una cadena de subcontrataciones donde nadie quiere ser el eslabón visible cuando algo falla. El RTS sobre política de terceros ICT, Reglamento Delegado (UE) 2024/1773, y el RTS sobre subcontratación, Reglamento Delegado (UE) 2025/532, convierten ese bloque en una obligación de ingeniería contractual y de gobierno del inventario. Si no sabes quién presta qué, desde dónde, con qué cuarto subcontratista y bajo qué derecho de acceso, no gestionas riesgo: apuestas.

Tercero, el reporting y la clasificación de incidentes. DORA no inventa el concepto de incidente grave, pero sí intenta armonizarlo. El RTS sobre clasificación de incidentes ICT está en el Reglamento Delegado (UE) 2024/1772. El proceso de notificación se desarrolla en el Reglamento Delegado (UE) 2025/301 y el formato técnico en el Reglamento de Ejecución (UE) 2025/302. Aquí el legislador ha hecho algo que la industria pidió durante años y a la vez temía: aproximar criterios comunes para que reportar no dependa de lecturas nacionales caprichosas. El problema, claro, es que armonizar no simplifica siempre. A veces solo estandariza la complejidad.

La gran trampa de 2026: creer que DORA se resuelve con políticas

Hay una escena que se repite demasiado. La entidad actualiza su marco normativo interno, aprueba una política de resiliencia digital, revisa el estándar de gestión de proveedores, organiza una sesión de formación al consejo y da por hecho que el grueso del trabajo está hecho. Luego llega la realidad.

La realidad es que DORA exige trazabilidad entre texto, control, evidencia y decisión. Si la política dice que existe un inventario de activos y servicios ICT críticos, el supervisor puede pedir la relación, el criterio de criticidad, la vinculación con procesos de negocio, la dependencia de terceros y la última fecha de revisión. Si el contrato con un proveedor estratégico dice que hay derecho de acceso, inspección y auditoría, la pregunta siguiente es si ese derecho es operativo o puramente decorativo. ¿La cláusula aplica a subcontratistas? ¿Hay límites geográficos? ¿Se puede ejercer sin plazos imposibles? ¿Cubre logs, entornos compartidos, evidencias de seguridad y resultados de pruebas?

DORA castiga especialmente la costumbre de trocear responsabilidades. El artículo 5 coloca al órgano de dirección en el centro de la responsabilidad sobre el marco de gestión del riesgo ICT. No es una licencia literaria. Significa que el consejo y la alta dirección tienen que aprobar, supervisar y ser capaces de cuestionar. En más de una entidad, ese será el punto de fricción real. Porque una cosa es que el órgano de dirección reciba un dashboard verde. Otra, que entienda qué implica concentrar pagos, autenticación o core policy administration en un mismo proveedor cloud con una cadena de subcontratación opaca.

Si tu entidad sigue presentando al consejo indicadores desconectados del riesgo de negocio, DORA no está maduro. Está disfrazado.

Terceros ICT: el lugar donde DORA se vuelve dolorosamente concreto

La parte más transformadora del reglamento no está en la retórica sobre resiliencia. Está en cómo trata a los terceros. DORA entiende que una entidad financiera no puede externalizar un servicio esencial y a la vez externalizar la responsabilidad. Parece obvio, pero hacía falta escribirlo con artículos, RTS y posibilidad de supervisión paneuropea para que dejara de parecer una recomendación amable.

Los artículos 28 y siguientes obligan a adoptar una estrategia de riesgo de terceros ICT, mantener un registro de información, evaluar el uso de servicios que soportan funciones críticas o importantes y asegurar determinadas cláusulas contractuales. La gracia amarga del asunto es que aquí chocan tres mundos que rara vez hablan bien entre sí: ciberseguridad, legal/compras y negocio.

Legal quiere contratos cerrables. Seguridad quiere control técnico. Compras quiere precio y velocidad. Negocio quiere continuidad y transformación digital. DORA obliga a todos a sentarse en la misma mesa y aceptar una verdad incómoda: un contrato ICT con una nube, un proveedor SaaS o un tercero de procesamiento no es un anexo comercial. Es una pieza de control prudencial.

El reglamento exige, entre otras cosas, que los contratos contemplen descripción clara de funciones y servicios, lugares de prestación y tratamiento, disposiciones sobre disponibilidad, autenticidad, integridad y confidencialidad, acceso, recuperación, asistencia en incidentes, terminación y derechos de auditoría e inspección. El RTS sobre subcontratación de 2025 aprieta aún más donde dolía menos mirar: la visibilidad de la cadena de subcontratistas que soporta funciones críticas o importantes.

Ese detalle importa por una razón que la industria conoce de sobra pero no siempre ordena bien en papel: el incidente raramente nace en el proveedor principal con quien has firmado. Nace dos o tres niveles más abajo, donde la negociación no llegó y la diligencia debida fue un ejercicio de fe con PDF corporativo incluido.

En 2026, la pregunta práctica no es si tienes una política de terceros. Es si puedes responder sin titubeos a cinco preguntas básicas:

• Qué servicios ICT soportan funciones críticas o importantes.
• Qué proveedor principal los presta y bajo qué modelo tecnológico.
• Qué subcontrataciones materiales existen y cómo se aprueban.
• Qué derechos efectivos de acceso, auditoría e inspección tiene la entidad y el supervisor.
• Cuál es el plan de salida o sustitución si el proveedor falla, empeora o deja de ser aceptable.

Si alguna de esas respuestas depende de preguntar a cinco departamentos y esperar una semana, la resiliencia está cogida con alfileres.

El registro de información no es burocracia: es el mapa del riesgo que muchas entidades nunca tuvieron

Uno de los elementos menos glamourosos y más reveladores de DORA es el registro de información sobre acuerdos contractuales relativos al uso de servicios prestados por terceros ICT. La obligación deriva del artículo 28 y de su desarrollo técnico, incluido el ITS sobre Register of Information publicado en 2024. No suena épico. Precisamente por eso importa.

Durante años, muchas entidades han gestionado inventarios parciales: un repositorio de contratos por un lado, un CMDB a medio cocer por otro, hojas de cálculo de outsourcing en la segunda línea, y listas separadas para continuidad, privacidad o seguridad. DORA fuerza a unir esas capas. Y al unirlas, expone carencias de gobierno de datos interno que nada tienen que ver con una ciberamenaza sofisticada y mucho con el hábito corporativo de no limpiar la casa hasta que viene visita.

El registro no sirve solo para remitir información que contribuya a la designación de proveedores críticos. Sirve para algo más básico: que la entidad entienda su propia anatomía operativa. Qué tercero soporta qué servicio, para qué función, en qué país, con qué dependencia tecnológica, bajo qué renovación contractual, y con qué impacto de salida.

EIOPA, EBA y ESMA, actuando conjuntamente como ESAs, han empujado esta pieza porque sin datos consistentes la supervisión de terceros críticos sería poco más que una ceremonia. La decisión de las ESAs sobre el reporting por autoridades competentes de la información necesaria para la designación de proveedores críticos refuerza esa lógica: sin un registro serio, el edificio de oversight se queda sin cimientos.

La ironía es evidente. Muchas entidades invierten millones en herramientas de observabilidad para descubrir en segundos un pico anómalo de CPU, pero tardan semanas en identificar todos los contratos y subservicios asociados a una función crítica. DORA viene a recordar que una arquitectura sin inventario fiable no es resiliente. Es solo cara.

Incidentes ICT: cuando DORA se cruza con GDPR y con la fatiga del reporting

Otro error frecuente es pensar que DORA sustituye obligaciones de notificación ya existentes. No lo hace. Añade una capa sectorial financiera armonizada sobre incidentes ICT y, dependiendo del caso, convivirá con otros regímenes de notificación.

Si un incidente ICT afecta a datos personales, el Reglamento General de Protección de Datos sigue plenamente vivo. El artículo 33 GDPR obliga a notificar a la autoridad de control una violación de seguridad de los datos personales sin dilación indebida y, de ser posible, a más tardar 72 horas después de haber tenido constancia de ella. Si además la violación entraña alto riesgo para los derechos y libertades de las personas físicas, el artículo 34 puede activar la comunicación a los interesados.

DORA juega en otro plano. Su objetivo no es la protección de datos personales, sino la resiliencia operativa del sector financiero. Por eso los criterios de clasificación del RTS de 2024/1772 se centran en variables como clientes afectados, duración, indisponibilidad, impacto económico, criticidad de servicios afectados y repercusión reputacional, entre otras. Puede haber incidentes reportables bajo DORA que no sean brechas personales bajo GDPR, y brechas bajo GDPR que no alcancen el umbral DORA. También puede haber las dos cosas a la vez. Ahí empiezan los dolores de cabeza de gobernanza.

El riesgo real en 2026 no es solo el doble reporting. Es el reporting descoordinado. Una entidad puede acabar con tres cronómetros corriendo a la vez: DORA para la autoridad financiera, GDPR para la autoridad de protección de datos y, si la entidad entra en ámbito NIS2 a través de su transposición nacional, notificaciones sectoriales de ciberincidentes a las autoridades competentes o CSIRT designados. Quien no haya unido los flujos de decisión, clasificación y escalado interno está preparando una receta clásica para contradicciones entre notificaciones.

La respuesta madura no pasa por nombrar tres dueños distintos del incidente. Pasa por un modelo único de mando del incidente, con criterios de calificación por régimen, coordinación legal y capacidad de generar versiones consistentes de los hechos. Parece elemental. No siempre existe.

TLPT: el momento en que el pentest de folleto deja de servir

DORA exige pruebas de resiliencia operativa digital proporcionales al perfil de riesgo de la entidad, pero reserva una capa avanzada para ciertas entidades significativas: el threat-led penetration testing, TLPT. Esta materia se desarrolla en el Reglamento Delegado (UE) 2025/1190. Y aquí muchas organizaciones van a descubrir que lo que durante años llamaron “pruebas avanzadas” era, en realidad, un ejercicio técnico útil pero lejos del listón regulatorio.

El TLPT inspirado en marcos como TIBER-EU no consiste en lanzar un escáner y redactar un informe con severidades. Exige un ejercicio basado en inteligencia de amenazas, centrado en funciones críticas o importantes, con alcance realista, participación de proveedores cuando sea necesario, controles de gobernanza estrictos y validación de remediación. No se diseña desde procurement ni se ejecuta como trámite anual. Requiere madurez operativa, compartimentación, reglas de engagement bien negociadas y patrocinio claro de la alta dirección.

Aquí aparece una de las contradicciones más interesantes de DORA. Las entidades llevan años externalizando parte de sus capacidades ofensivas y defensivas, pero el TLPT obliga a conocer tan bien el negocio y la arquitectura que no puede delegarse mentalmente. Puedes subcontratar la ejecución. No puedes subcontratar el entendimiento de qué estás poniendo a prueba y por qué.

Para aseguradoras, gestoras, bancos y PSPs con cadenas complejas de terceros, el verdadero reto del TLPT en 2026 no es técnico. Es de coordinación. Qué activos y procesos representan de verdad una función crítica. Qué terceros deben incluirse. Cómo se protege la producción sin vaciar de realismo el ejercicio. Cómo se documenta el cierre sin generar un festival de evidencias incompatibles entre seguridad, auditoría interna y supervisor.

Supervisión de proveedores críticos: el elemento que cambia la negociación de poder

DORA introduce algo que el mercado llevaba tiempo anticipando: un marco de supervisión a nivel de la UE para proveedores terceros de servicios ICT designados como críticos, los llamados CTPPs. Los criterios de designación se desarrollan mediante acto delegado, y el sistema se completa con normas sobre tasas de supervisión, condiciones armonizadas de oversight y funcionamiento de los Joint Examination Teams, estos últimos en el Reglamento Delegado (UE) 2025/420.

No conviene exagerar: que un proveedor sea crítico a ojos de DORA no convierte mágicamente a cada cliente en una parte negociadora fuerte. Pero sí altera el contexto. Por primera vez, ciertos grandes proveedores tecnológicos dejan de estar solo en la órbita contractual privada de miles de entidades y pasan a una dinámica de escrutinio supervisor europeo estructurado.

Eso tendrá dos efectos previsibles. El primero, una mejora gradual de la estandarización de evidencias, procesos de cooperación y respuesta a hallazgos. El segundo, una tensión sobre la asimetría tradicional del mercado cloud y SaaS. Porque cuando el supervisor puede pedir información, realizar inspecciones y emitir recomendaciones a un proveedor crítico, las entidades dejan de estar completamente solas intentando arrancar concesiones contractuales a gigantes con plantillas cerradas de términos y condiciones.

Ahora bien, sería ingenuo pensar que esta supervisión resolverá por sí sola el problema de concentración tecnológica. DORA obliga a gestionar el riesgo de concentración, pero no lo elimina. Si media industria depende de un puñado de hyperscalers, procesadores o plataformas críticas, el riesgo sistémico no desaparece porque lo hayas registrado bien en una tabla. Solo se vuelve más visible. Que no es poco, pero tampoco es magia.

Impacto regulatorio cruzado

DORA no vive aislado. Su fuerza real aparece cuando se cruza con otras normas que empujan en direcciones parecidas pero con finalidades distintas. Entender ese cruce es justo lo que separa el cumplimiento inteligente del cumplimiento duplicado.

DORA y NIS2: primos cercanos, no gemelos

La Directiva NIS2, en particular su artículo 21 sobre medidas de gestión de riesgos de ciberseguridad, exige a entidades esenciales e importantes adoptar medidas técnicas, operativas y organizativas adecuadas y proporcionadas. Hay solapamientos obvios con DORA: gestión de incidentes, continuidad, cadena de suministro, seguridad en adquisición y desarrollo, evaluación de eficacia. Pero NIS2 es una directiva horizontal de ciberseguridad para sectores esenciales e importantes; DORA es un reglamento sectorial financiero con una precisión mucho mayor en terceros ICT, testing y reporting financiero.

Para entidades financieras, la clave no es elegir marco, sino articularlos sin duplicar. DORA suele actuar como lex specialis en el perímetro financiero, pero la transposición nacional de NIS2 puede seguir afectando a grupos mixtos, filiales tecnológicas o entidades del grupo fuera del núcleo regulado financiero. Si el grupo mantiene dos marcos paralelos, acabará pagando dos veces por controles que deberían mapearse una sola vez.

DORA y GDPR: mismo incidente, distinta pregunta

GDPR pregunta si hay riesgo para derechos y libertades por una violación de datos personales. DORA pregunta si hay un incidente ICT que afecta a la resiliencia operativa financiera con criterios armonizados. No son preguntas intercambiables. Un ransomware con cifrado de sistemas críticos pero sin exfiltración confirmada puede ser devastador para DORA aunque el análisis GDPR sea distinto. A la inversa, una fuga acotada de datos personales en un sistema no crítico puede activar GDPR sin alcanzar umbral DORA.

La implicación operativa es clara: el playbook de incidentes debe contener desde el minuto uno ramas de decisión legales distintas, con hechos comunes y criterios separados. Si el equipo de respuesta intenta decidir primero “si es GDPR o si es DORA”, ya va tarde. La respuesta correcta es: puede ser ambos, o ninguno, y hay que modelarlo así.

DORA y AI Act: el riesgo no viene solo del modelo, sino del stack que lo soporta

En 2026, banca y seguros están acelerando despliegues de IA generativa, scoring asistido, automatización documental y analítica antifraude. El AI Act impone obligaciones específicas para sistemas de alto riesgo y reglas de transparencia en determinados usos. Pero incluso cuando el caso de uso no cae en la categoría más dura del AI Act, DORA sigue siendo relevante porque la IA se apoya en infraestructura, datos, APIs, terceros y procesos que generan riesgo operativo digital.

Aquí hay un punto que demasiadas entidades están subestimando: un modelo de IA puede no ser “alto riesgo” a ojos del AI Act y aun así introducir dependencia crítica de un proveedor externo, opacidad de subprocesadores, nuevos vectores de indisponibilidad o ampliación no controlada del perímetro de datos. Si una aseguradora integra un copiloto externo en gestión de siniestros o una entidad bancaria usa un motor de IA para priorizar alertas SOC, DORA obliga a mirar más allá de la fascinación tecnológica. Quién presta el servicio. Dónde se procesa. Qué ocurre si falla. Qué logs existen. Qué evidencias de seguridad y continuidad ofrece el proveedor. Cómo se revierte.

Los controles recomendables aquí son muy terrenales: inventario específico de casos de uso de IA con dependencia externa, due diligence técnica y contractual reforzada, evaluación de impacto sobre funciones críticas, segregación de datos sensibles, logging verificable, validación humana en decisiones relevantes y pruebas de degradación operativa si el servicio de IA queda indisponible o responde de forma errática. La IA no suspende DORA. La complica.

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

Con eIDAS 2.0 y la futura expansión de carteras de identidad digital europeas, muchas entidades financieras observarán nuevas integraciones de confianza digital, autenticación y atributos verificables. Eso abre oportunidades de onboarding y KYC más eficientes. También multiplica la dependencia de servicios de confianza e intermediarios tecnológicos. DORA entra ahí por la puerta lateral: toda nueva capa de identidad digital conectada a procesos críticos debe evaluarse como dependencia ICT, no como mero proyecto de negocio.

DORA y CSRD: resiliencia digital como asunto material para el gobierno corporativo

CSRD no impone controles de ciberseguridad como DORA, pero eleva el listón de transparencia y gobernanza sobre riesgos materiales. Para entidades sujetas a reporting de sostenibilidad y gobierno, la resiliencia operativa digital y la gestión de terceros pueden acabar aflorando como elementos materiales del gobierno del riesgo. Dicho sin eufemismos: lo que DORA obliga a controlar puede terminar siendo también relevante para lo que la empresa debe explicar sobre su gobernanza y gestión de riesgos en reporting corporativo.

España: por qué DORA será más una prueba de ejecución que de interpretación

Para entidades financieras españolas, el reto de 2026 no está tanto en entender la intención del texto europeo como en absorberlo en una estructura de supervisión ya densa, con Banco de España, CNMV y Dirección General de Seguros y Fondos de Pensiones según el tipo de entidad, además de la coordinación europea a través de las ESAs. España no parte de cero en outsourcing, continuidad, seguridad o notificación de incidentes. Precisamente por eso DORA aprieta donde más cuesta: en la consolidación.

Bancos significativos ya cargan con expectativas supervisoras maduras en riesgo operacional y outsourcing. Aseguradoras arrastran obligaciones de gobernanza bajo Solvencia II y ahora deben encajar DORA con marcos internos que a veces separaban demasiado TI, continuidad y función de riesgos. Las fintech reguladas y proveedores de servicios de pago, por su parte, suelen tener arquitecturas más nativas en cloud y procesos más ágiles, pero a menudo adolecen de una documentación contractual y de control menos robusta para un escrutinio supervisor prolongado.

La opinión de EIOPA sobre el alcance de DORA a la luz de la revisión de Solvencia II es relevante para el mercado asegurador porque muestra algo que conviene no perder de vista: el debate de perímetro no está completamente muerto. Sigue habiendo matices sobre qué entidades y actividades encajan exactamente y cómo interactúan las reformas sectoriales. Pero sería un error usar esas discusiones para aplazar trabajo. En 2026, el supervisor valorará más una interpretación razonada y bien documentada que una espera pasiva a la “clarificación definitiva” que nunca llega del todo.

Qué deberían estar haciendo ya CISOs, compliance y compras si no quieren llegar tarde otra vez

La parte incómoda de DORA es que no tiene un único dueño funcional. Y por eso mismo, la respuesta eficaz tampoco puede ser de silos. Hay varias decisiones concretas que una entidad madura ya debería haber resuelto este año.

La primera es de gobierno: quién tiene autoridad real para unir riesgo ICT, outsourcing, legal, continuidad y reporting. No un comité ornamental. Autoridad. DORA reparte obligaciones, pero no tolera vacíos entre líneas de defensa.

La segunda es de datos: cuál es la fuente maestra sobre servicios ICT, activos críticos, terceros, subcontrataciones y contratos asociados. Si hay varias, hay conflicto. Si hay conflicto, habrá incoherencias en incidentes, auditorías y supervisión.

La tercera es contractual: qué plantillas y playbooks de negociación se usan para terceros que soportan funciones críticas o importantes. Esto incluye derechos de acceso y auditoría, asistencia en incidentes, localización, borrado/retorno de datos, continuidad, salida y control de subcontratación. Si cada negociación empieza desde cero, la entidad se condena a una mezcla inestable de cláusulas incompatibles.

La cuarta es técnica: cómo se conectan los controles de seguridad con las obligaciones formales de DORA. Un SOC puede detectar incidentes, pero si no captura desde el inicio los datos necesarios para clasificación regulatoria y posible reporting, el valor del control queda a medias. Lo mismo con continuidad, backup, restauración, logging y pruebas.

La quinta es cultural: qué entiende el consejo cuando oye hablar de resiliencia operativa digital. Si solo recibe semáforos de vulnerabilidades y phishing, la conversación llega recortada. DORA exige un lenguaje de negocio: funciones críticas, dependencia externa, impacto de indisponibilidad, capacidad de recuperación, concentración y tolerancias.

Lo más útil en 2026 no es producir más documentos. Es cerrar tres brechas que casi siempre aparecen juntas: brecha de inventario, brecha contractual y brecha de escalado de incidentes. Cuando esas tres existen, todo lo demás parece ordenado hasta que deja de parecerlo.

La objeción habitual: “esto favorece a los grandes y asfixia a los pequeños”

La crítica no es absurda. DORA tiene una carga de complejidad que se digiere mejor con presupuesto, segunda línea robusta y equipos jurídicos especializados. Una entidad pequeña o mediana puede sentir, con razón, que el esfuerzo de registro, revisión contractual, testing y reporting es desproporcionado frente a su capacidad. Además, los grandes proveedores tecnológicos están mejor situados para absorber exigencias documentales y de supervisión que un proveedor nicho especializado.

Ahora bien, la respuesta no puede ser rebajar el problema a burocracia europea con mala leche. El riesgo operativo digital ya era desproporcionado para las entidades pequeñas; solo que estaba menos visible. Un fallo de proveedor, una mala restauración o un incidente mal escalado hacen tanto daño prudencial a una entidad mediana como a una grande, a veces más. DORA tiene mecanismos de proporcionalidad, pero no puede borrar la realidad de dependencia tecnológica del sector.

La crítica más seria no es que DORA sea exigente. Es que llega a un mercado financiero que todavía opera con niveles de concentración tecnológica difíciles de reconciliar con la idea de resiliencia distribuida. Ahí el reglamento diagnostica mejor de lo que cura. Pero no por ello el diagnóstico deja de ser correcto.

El mensaje de fondo de EIOPA y las ESAs: menos storytelling, más demostración

Si uno mira la arquitectura completa que ya está publicada o referenciada por EIOPA —RTS de riesgo ICT, clasificación y reporting de incidentes, TLPT, política de terceros, subcontratación, registro de información, criterios de designación de CTPPs, tasas, condiciones de oversight y JETs— la conclusión es bastante obvia. Los supervisores europeos no están construyendo una norma para escuchar promesas. Están construyendo un sistema para pedir pruebas comparables.

Eso cambia el tipo de preguntas que se harán en 2026 y 2027. Menos “tiene usted una política?” y más “cómo demuestra que esta función crítica puede recuperarse bajo este escenario?”. Menos “su proveedor cumple con estándares?” y más “qué derecho concreto tiene para obtener esta evidencia o imponer este cambio?”. Menos “ha notificado incidentes?” y más “cómo clasifica, con qué datos y quién valida la consistencia entre regímenes?”.

La era del cumplimiento narrativo se está acabando. No del todo, porque ninguna regulación mata del todo el teatro corporativo, pero sí lo suficiente como para que deje de ser una estrategia segura.

La conclusión incómoda

DORA no es solo una norma de resiliencia digital. Es una auditoría a la honestidad operativa de las entidades financieras. Obliga a reconocer qué se sabe, qué no se sabe y qué se ha delegado sin control real. Por eso genera tanta fricción: no porque invente obligaciones alienígenas, sino porque conecta puntos que muchas organizaciones habían preferido mantener separados.

En 2026, seguir tratando DORA como un proyecto de implantación es un error de calendario y de concepto. Ya no estás implantando; estás operando bajo DORA. La diferencia importa. Un proyecto termina. Una obligación supervisable no.

La pregunta adecuada para cualquier entidad financiera europea ya no es “estamos alineados con DORA?”. Esa frase permite demasiada poesía. La pregunta correcta es bastante menos cómoda: si mañana el supervisor pide evidencias sobre gobierno, terceros, incidentes y pruebas, ¿qué parte de nuestra respuesta será verificable en horas y qué parte dependerá de reconstruir la realidad a posteriori?

La segunda mitad de esa respuesta es donde empieza el problema. Y también donde empieza, si se hace bien, la resiliencia de verdad.