DORA ya no es una promesa: lo que Banco de España vio venir en 2023 y pesa de verdad en 2026

Lo complicado de DORA no es leer el reglamento. Lo complicado es ejecutarlo sin convertir el cumplimiento en una colección de documentos impecables y controles a medias. Ahí es donde muchas entidades han descubierto que el verdadero problema no está en el texto legal, sino en las costuras: proveedores TIC, solapamientos normativos y un principio de proporcionalidad que suena razonable hasta que alguien tiene que traducirlo a evidencias, presupuesto y comités.

Esa sigue siendo la discusión útil. No la retórica sobre resiliencia, que a estas alturas ya no sorprende a nadie, sino la parte incómoda: quién decide qué es “proporcionado”, cómo se articula DORA con otras obligaciones de ciberseguridad y qué margen real tiene una entidad cuando una parte crítica de su operación depende de un tercero que no controla del todo.

Si uno separa el ruido regulatorio de lo que de verdad genera trabajo, aparecen tres frentes persistentes. Primero, la gestión de terceros TIC bajo DORA, especialmente en los artículos 28 a 30, donde el reglamento deja claro que externalizar no externaliza la responsabilidad. Segundo, la convivencia de DORA con otros marcos, en particular con regímenes de notificación de incidentes y gestión de riesgos que no siempre encajan de forma elegante. Tercero, la proporcionalidad: DORA la invoca, sí, pero eso no evita que cada entidad tenga que justificar por qué su diseño de control es suficiente para su tamaño, perfil de riesgo, complejidad y dependencia tecnológica.

El punto ciego no era el texto. Era la dependencia

Durante años, buena parte del sector financiero trató el riesgo de terceros como una extensión de compras, vendor management o outsourcing. DORA desmonta ese enfoque por la vía dura. El artículo 28 obliga a gestionar el riesgo derivado de terceros proveedores de servicios TIC como parte integrante del marco de gestión del riesgo TIC de la entidad. No como un anexo. No como una excepción. Como parte del núcleo de control.

La consecuencia práctica es bastante menos elegante que el lenguaje del reglamento. Si una entidad depende de un proveedor cloud, de un servicio gestionado de ciberseguridad, de software crítico o de una plataforma de pagos, no basta con tener cláusulas contractuales razonables y una due diligence inicial. DORA exige estrategia sobre riesgo de terceros, registro de acuerdos contractuales, evaluación antes de contratar, seguimiento continuo y condiciones de salida. Eso está repartido entre los artículos 28, 29 y 30. Y cada una de esas piezas pide evidencias.

Aquí está el quid: muchas entidades creían tener controlado el riesgo de terceros porque tenían inventario de proveedores. DORA pide bastante más. Quiere saber qué servicio TIC soporta qué función, si esa función es crítica o importante, qué concentración existe, qué dependencia técnica o jurídica se ha creado y cómo se sale del proveedor sin provocar un accidente operativo. La palabra de moda es “resiliencia”; la palabra útil es “salida”. Cuando una entidad no puede responder con cierto detalle cómo abandonaría un proveedor crítico, el supuesto control se queda en presentación de PowerPoint.

No es casual que el artículo 30 entre en un nivel contractual muy concreto para servicios TIC que soportan funciones críticas o importantes: descripción completa de funciones y servicios, lugares de prestación, disposiciones sobre disponibilidad, integridad, accesibilidad y confidencialidad, derechos de acceso, inspección y auditoría, apoyo en incidentes, terminación y periodos de preaviso. Quien esperaba una norma de principios ha recibido, en esta parte, una norma con dientes.

DORA y el problema real de la superposición regulatoria

La convivencia entre marcos no es una cuestión académica. Es una cuestión de calendarios, equipos y criterios de reporte. Las entidades financieras no viven solo bajo DORA. También arrastran obligaciones sectoriales, expectativas supervisoras, normas nacionales de ciberseguridad y, dependiendo del caso, reglas de privacidad y continuidad de negocio que tienen lógica propia. El resultado no siempre es un mosaico armonioso. A veces se parece más a una mesa de control con demasiadas alarmas y no todos los botones etiquetados.

Tomemos la notificación de incidentes. DORA establece en el artículo 17 la obligación de gestionar, clasificar y notificar incidentes relacionados con las TIC, y en el artículo 19 desarrolla la notificación de incidentes graves y, de forma voluntaria, de ciberamenazas significativas. Eso después se aterriza mediante normas técnicas. La lógica de DORA es sectorial y financiera: quiere una taxonomía y un circuito de notificación que sirvan a supervisores financieros y a la estabilidad operativa de las entidades.

NIS2, por su parte, regula la notificación de incidentes en su artículo 23 con una secuencia más precisa de lo que muchas piezas divulgativas resumen demasiado rápido. El artículo exige una alerta temprana sin demora indebida y, en cualquier caso, dentro de las 24 horas desde que la entidad tenga conocimiento del incidente significativo; una notificación del incidente dentro de las 72 horas desde ese conocimiento; y un informe final no más tarde de un mes desde la presentación de la notificación inicial. Además, la autoridad competente o el CSIRT puede pedir un informe intermedio sobre actualizaciones pertinentes de la situación. Ese matiz importa, porque afecta a playbooks, escalados internos y ownership operativo.

El problema no es solo que existan varios plazos. El problema es que los marcos no persiguen exactamente lo mismo ni usan necesariamente las mismas categorías. Una entidad puede tener que clasificar un mismo evento con criterios de severidad distintos según el canal de reporte. Si, además, el incidente implica datos personales, entra en escena el GDPR: el artículo 33 obliga a notificar a la autoridad de control las violaciones 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 ellas. Ya no hablamos de una obligación. Hablamos de varias, con vocabularios que se solapan sin ser idénticos.

Eso explica por qué la discusión seria no va de “cumplir DORA” en abstracto, sino de diseñar un modelo de incident reporting que evite duplicidades, contradicciones y escalados paralelos. Si tus equipos de seguridad, privacidad, continuidad y cumplimiento siguen funcionando como compartimentos estancos, el incidente llegará una vez y se gestionará cuatro veces. Mal negocio.

Sobre NIS2 y el sector financiero: menos eslogan, más matiz

Conviene aquí limpiar una simplificación que circula demasiado. Decir sin más que NIS2 “incluye al sector financiero como sector crítico” puede inducir a error si no se añade el matiz de lex specialis. La directiva sí enumera sectores de alta criticidad y otros sectores críticos en sus anexos, pero su artículo 4 prevé que, cuando actos jurídicos sectoriales de la Unión impongan requisitos de ciberseguridad o de notificación de incidentes al menos equivalentes, esas disposiciones sectoriales prevalezcan respecto de las entidades cubiertas por ellas.

En otras palabras: para entidades financieras sujetas a DORA, la interacción con NIS2 no se resuelve con un eslogan de inclusión general, sino analizando el alcance exacto de la norma sectorial aplicable y el efecto de la cláusula de especialidad. Esa diferencia no es menor. Cambia quién supervisa qué, qué régimen de reporte aplica y cómo se coordinan las autoridades. Quien presente DORA y NIS2 como dos capas simplemente acumulativas está vendiendo una versión demasiado ordenada de una realidad que no lo es tanto.

La pregunta útil para una entidad no es “¿nos afecta NIS2 sí o no?”. La pregunta útil es otra: “¿qué obligaciones quedan absorbidas por el régimen sectorial, cuáles no, y cómo lo documentamos para no descubrir la respuesta durante un incidente serio o una inspección?”.

Proporcionalidad: la palabra favorita del regulador y el dolor de cabeza del control interno

Todo regulador adora la proporcionalidad. Le permite reconocer que no todas las entidades son iguales sin renunciar a exigir mucho. DORA sigue esa tradición. El artículo 4 establece que las entidades financieras aplicarán el reglamento de conformidad con el principio de proporcionalidad, teniendo en cuenta su tamaño y perfil de riesgo general, así como la naturaleza, escala y complejidad de sus servicios, actividades y operaciones.

Sobre el papel suena impecable. En la práctica, abre una discusión permanente: ¿qué significa proporcionalidad cuando el riesgo tecnológico de una entidad pequeña puede dispararse por una dependencia intensa de un único proveedor cloud, un core bancario heredado o una cadena de subcontratación poco visible? Una entidad menos compleja en términos societarios no es necesariamente menos frágil en términos digitales.

Ese es uno de los puntos menos cómodos de DORA. La proporcionalidad no rebaja por defecto las expectativas sobre gobierno, terceros, pruebas o respuesta a incidentes. Lo que hace es permitir una aplicación ajustada. Pero ajustada no significa laxa. Si una entidad quiere apoyarse en el artículo 4 para justificar un enfoque menos exigente en algún control, tendrá que demostrar por qué ese control sigue siendo suficiente para su perfil de riesgo. Y demostrarlo exige trazabilidad: decisiones, criterios, apetito al riesgo, inventario de activos, dependencias, escenarios y aprobación de gobernanza.

Dicho de forma menos diplomática: invocar la proporcionalidad sin una lógica probatoria detrás es una invitación a que el supervisor haga preguntas desagradables. Y con razón.

El marco de supervisión de terceros críticos no es decorativo

Otra área donde conviene evitar etiquetas apresuradas es la supervisión de terceros proveedores de servicios TIC considerados críticos. DORA crea un marco específico en los artículos 31 a 44 para esa supervisión a escala de la Unión. El diseño institucional gira alrededor de las Autoridades Europeas de Supervisión, que actúan como Lead Overseer según los criterios y procedimientos previstos en el reglamento. A partir de ahí, el marco incorpora cooperación con autoridades competentes y otros actores públicos en los términos establecidos por la norma.

Lo que puede afirmarse con seguridad es esto: el régimen no convierte la supervisión de terceros críticos en un asunto puramente bilateral entre proveedor y entidad financiera, porque introduce una capa de oversight supranacional sobre determinados proveedores TIC críticos. Lo que no conviene hacer es asignar de forma ligera papeles institucionales con etiquetas no ancladas al texto legal. En este terreno, cada verbo importa.

Para las entidades, la implicación práctica sí está clara. Aunque el proveedor crítico quede sometido a un marco de supervisión europeo, la responsabilidad de la entidad financiera sobre su propio riesgo TIC no desaparece. DORA no ofrece una amnistía por dependencia compartida. Que un proveedor esté sometido a escrutinio europeo no exime a la entidad de cumplir los artículos 28 a 30, ni de mantener capacidad de evaluación, monitorización y salida.

El error más común: convertir DORA en una suma de políticas

Muchas implementaciones de DORA han empezado por donde era más visible: actualizar políticas, rehacer taxonomías de incidentes, revisar plantillas contractuales y preparar el registro de información de terceros. Todo eso es necesario. Ninguna de esas piezas basta.

El fallo recurrente aparece cuando la entidad trata DORA como si fuera un ejercicio de documentación en lugar de un rediseño operativo. El reglamento exige gobierno, sí, pero también pruebas, detección, respuesta, continuidad, aprendizaje postincidente y disciplina sobre terceros. Si esas piezas no están conectadas, el cumplimiento queda formalmente ordenado y funcionalmente cojo.

Un ejemplo sencillo. Una entidad puede tener una política impecable de gestión de terceros y, al mismo tiempo, no haber mapeado con precisión qué activos, procesos y datos dependen de cada proveedor. Puede tener un proceso de clasificación de incidentes y no haber alineado esa clasificación con los criterios que activan obligaciones de privacidad, continuidad o notificación sectorial. Puede haber definido una estrategia de salida y no haber probado nunca su viabilidad. En los tres casos, el papel dice “cumplido”; la realidad dice “veremos”. Y “veremos” no suele gustar a auditoría interna, mucho menos al supervisor.

Qué exige de verdad una lectura madura de DORA

La lectura inmadura del reglamento pregunta: “¿qué documentos tenemos que producir?”. La lectura madura pregunta otra cosa: “¿qué decisiones de riesgo tenemos que tomar y qué pruebas necesitamos para defenderlas?”. El cambio de enfoque parece semántico. No lo es.

En gobierno interno, DORA pone a la dirección en el centro. El artículo 5 atribuye al órgano de dirección la responsabilidad última de definir, aprobar, supervisar y responder por la aplicación del marco de gestión del riesgo TIC. Eso obliga a abandonar una comodidad muy extendida: tratar el riesgo tecnológico como asunto casi exclusivo de seguridad de la información o de sistemas. Bajo DORA, la gobernanza tiene que demostrar implicación real, no mera recepción de informes.

En gestión del riesgo TIC, los artículos 6 a 16 piden un marco interno amplio que cubra identificación, protección y prevención, detección, respuesta y recuperación, aprendizaje y comunicación. La estructura recuerda a otros marcos de ciberseguridad, pero DORA lo aterriza con exigencias supervisables. No basta con declarar capacidades; hay que mantenerlas, probarlas y revisarlas.

En resiliencia operativa, las pruebas no son accesorias. El artículo 24 exige un programa de pruebas de resiliencia operativa digital proporcionado al tamaño, perfil de negocio y riesgo de la entidad. Para algunas entidades, además, DORA prevé pruebas avanzadas basadas en amenazas, desarrolladas en los artículos 26 y 27. Esto importa porque rompe otra fantasía habitual del compliance tecnológico: creer que un control existe porque alguien lo describió bien. Si no se prueba, no se sabe.

La coexistencia con GDPR no se resuelve sola

Uno de los choques más delicados no es solo con normas de ciberseguridad, sino con privacidad. Cuando un incidente TIC afecta a la disponibilidad o integridad de sistemas financieros, la prioridad operativa puede ser contener, restaurar y seguir prestando servicio. Cuando además hay datos personales implicados, GDPR añade una lógica distinta: evaluar riesgo para los derechos y libertades de las personas, documentar la violación y notificar conforme al artículo 33; y, cuando proceda, comunicar a los interesados según el artículo 34.

El desajuste no es teórico. Los equipos de seguridad suelen pensar en activos, servicios y severidad técnica. Los equipos de privacidad piensan en categorías de datos, volumen, impacto sobre individuos y medidas de mitigación. Si ambos análisis no convergen rápido, aparecen dos problemas. El primero es de plazo. El segundo es de narrativa: dos funciones internas pueden describir el mismo incidente de formas distintas ante autoridades distintas. No hace falta explicar por qué eso acaba mal.

Una arquitectura de cumplimiento mínimamente seria necesita un único proceso de triage inicial con ramas regulatorias coordinadas. No una carrera entre departamentos para ver quién envía primero su formulario.

Lo que sí deberían hacer ahora las entidades

La respuesta útil no pasa por abrir otro programa transversal con nombre grandilocuente. Pasa por revisar algunos puntos concretos donde DORA suele encontrar fragilidad operativa.

• Mapear dependencias reales, no solo proveedores. El artículo 28 obliga a integrar el riesgo de terceros en el marco TIC. Eso requiere saber qué función soporta cada servicio, si esa función es crítica o importante y qué concentración técnica o contractual existe.
• Revisar contratos de funciones críticas o importantes con el artículo 30 en la mano. No en abstracto. Cláusula por cláusula: acceso, auditoría, localización, apoyo en incidentes, terminación, subcontratación cuando proceda y disponibilidad de datos.
• Unificar playbooks de incidentes. DORA art. 17 y 19, GDPR art. 33 y, cuando proceda, NIS2 art. 23 no pueden vivir en silos separados. La entidad necesita un árbol de decisión común y responsables claros desde la primera hora del incidente.
• Documentar la proporcionalidad. Si ciertos controles se aplican de forma ajustada por tamaño, complejidad o perfil de riesgo conforme al artículo 4, esa decisión debe dejar rastro: criterio, aprobación, revisión y justificación técnica.
• Probar salidas y contingencias. La estrategia de salida de terceros críticos no sirve si nunca se ha ensayado, aunque sea mediante escenarios de mesa, failover parcial o validaciones técnicas limitadas.

Nada de esto es glamuroso. Casi nada cabe bien en una nota de prensa. Precisamente por eso importa.

La trampa del cumplimiento narrativo

Hay una tentación muy reconocible en todo gran cambio regulatorio: construir una narrativa de preparación antes de haber resuelto las dependencias incómodas. Presentaciones al consejo, mapas de calor, programas de remediación y políticas actualizadas generan sensación de avance. A veces con razón. Otras veces sirven para maquillar que lo sustantivo sigue pendiente: renegociar contratos imposibles, limpiar inventarios, alinear taxonomías, corregir accesos privilegiados, probar restauraciones o discutir con negocio cuánto riesgo tecnológico está dispuesto a tolerar de verdad.

DORA castiga especialmente esa tentación porque conecta piezas que antes podían sobrevivir separadas. Un mal inventario perjudica la gestión de terceros. Una clasificación débil de funciones críticas contamina contratos, pruebas, continuidad y reporte de incidentes. Una gobernanza pasiva deja sin dueño los compromisos incómodos. Todo termina unido.

Por eso el reglamento está generando una consecuencia interesante: obliga a muchas entidades a descubrir si su modelo de control era realmente integrado o solo parecía integrado visto desde lejos. No todas van a disfrutar del resultado.

La pregunta que separa a las entidades preparadas de las demás

Hay una forma bastante sencilla de medir la madurez real frente a DORA. No consiste en preguntar cuántas políticas se han actualizado ni cuántos comités reciben reporting. Consiste en lanzar una escena concreta: caída grave de un proveedor TIC que soporta una función importante, impacto en clientes, datos personales potencialmente comprometidos, presión de negocio para restaurar, incertidumbre técnica y necesidad de decidir si se notifica y por qué canal.

Si la entidad puede identificar en pocas horas la dependencia exacta, el dueño interno, la criticidad de la función, los compromisos contractuales activables, las vías de escalado, los criterios de clasificación, las obligaciones regulatorias concurrentes y la estrategia de continuidad, está bastante más cerca de cumplir de verdad. Si no puede, el problema no es de redacción normativa. Es de arquitectura operativa.

DORA no ha inventado ese problema. Lo ha hecho imposible de ignorar.

La lectura menos complaciente

Conviene terminar sin autoengaños. La parte difícil de este reglamento no es descifrar qué quiso decir el legislador en cada artículo. La parte difícil es asumir lo que implica cuando se toma en serio. Implica que el riesgo TIC ya no puede quedarse en la periferia del gobierno corporativo. Implica que externalizar una capacidad crítica exige más disciplina, no menos. Implica que la proporcionalidad no es una coartada para el mínimo esfuerzo. E implica que el reporting de incidentes no puede seguir fragmentado entre funciones que apenas se hablan salvo cuando algo arde.

Ese es el núcleo del asunto. Lo demás, por muy vistoso que suene, es decoración regulatoria.

Si tu entidad todavía está discutiendo DORA como si fuera sobre todo un ejercicio documental, la conversación llega tarde. El reglamento, leído con algo de honestidad, va de decisiones operativas, de dependencia tecnológica y de capacidad real para responder cuando falle lo que no controlas del todo. Y eso, por desgracia para los aficionados al powerpointismo, no se arregla con otra política de veinte páginas.