Reglamento DORA: qué es, a quién aplica y qué exige

El Reglamento (UE) 2022/2554, conocido como DORA (Digital Operational Resilience Act), es la norma europea de resiliencia operativa digital del sector financiero. Y hay un dato que conviene fijar desde la primera línea: ya es obligatorio. Es aplicable desde el 17 de enero de 2025.

Al ser un Reglamento —y no una directiva—, es obligatorio en todos sus elementos y directamente aplicable en cada Estado miembro. No necesita transposición nacional. A diferencia de NIS2, aquí no hay ley española que esperar: DORA ya rige.

Qué persigue DORA

La premisa es sencilla: el sistema financiero depende de la tecnología, y un fallo o un ciberataque en un proveedor tecnológico puede propagarse por todo el sector. DORA responde armonizando los requisitos de seguridad de las redes y los sistemas de información que sustentan los procesos de las entidades financieras y —esto es lo verdaderamente novedoso— extendiendo la supervisión a los proveedores tecnológicos de los que dependen.

Dicho de otro modo: por primera vez, un regulador financiero europeo puede mirar directamente a la empresa que le presta la nube a su banco.

A quién aplica (artículo 2)

El ámbito va mucho más allá de la banca. DORA se aplica, entre otras, a:

• entidades de crédito;
• entidades de pago y proveedores de servicios de información sobre cuentas;
• entidades de dinero electrónico;
• empresas de servicios de inversión;
• proveedores de servicios de criptoactivos y emisores de fichas referenciadas a activos;
• depositarios centrales de valores, entidades de contrapartida central, centros de negociación y registros de operaciones;
• gestores de fondos de inversión alternativos y sociedades de gestión;
• proveedores de servicios de suministro de datos;
• empresas de seguros y de reaseguros e intermediarios de seguros;
• fondos de pensiones de empleo;
• agencias de calificación crediticia y administradores de índices de referencia.

Y, de forma decisiva, alcanza también a los proveedores terceros de servicios de TIC que prestan servicio a esas entidades. Muchas empresas tecnológicas que no se consideran «financieras» descubren así que DORA les afecta por la puerta de atrás: a través de sus clientes.

Proporcionalidad real: el marco simplificado (artículo 16)

DORA no trata igual a un gran banco que a una entidad pequeña. El artículo 16 establece un marco simplificado de gestión del riesgo TIC: los artículos 5 a 15 no se aplican a las empresas de servicios de inversión pequeñas y no interconectadas, a las entidades de pago exentas y a otras entidades de menor entidad. La proporcionalidad no es retórica: está en el articulado.

Los cinco pilares (artículo 1)

1. Gestión del riesgo relacionado con las TIC. Un marco completo de identificación, protección, detección, respuesta y recuperación, con políticas de copias de seguridad y aprendizaje tras los incidentes.

2. Notificación de incidentes. Comunicación a las autoridades competentes de los incidentes graves relacionados con las TIC y, con carácter voluntario, de las ciberamenazas importantes. Para determinadas entidades, también de los incidentes operativos o de seguridad graves relacionados con los pagos.

3. Pruebas de resiliencia operativa digital. No basta con declarar que los sistemas resisten: hay que probarlo, con un programa periódico de pruebas.

4. Gestión del riesgo derivado de terceros proveedores de TIC. Incluye requisitos sobre los acuerdos contractuales y un marco europeo de supervisión de los proveedores esenciales.

5. Intercambio de información e inteligencia sobre ciberamenazas y vulnerabilidades entre entidades.

La responsabilidad es del consejo (artículo 5)

El órgano de dirección de la entidad financiera define, aprueba y supervisa todas las disposiciones del marco de gestión del riesgo TIC, y es responsable de su aplicación. No es una responsabilidad delegable al departamento de tecnología. Al igual que en NIS2, la resiliencia digital sube al consejo.

El marco de gestión del riesgo TIC (artículo 6)

DORA exige a las entidades financieras contar con un marco de gestión del riesgo TIC «sólido, completo y bien documentado», integrado en su sistema global de gestión de riesgos, que les permita afrontar el riesgo tecnológico de forma rápida, eficiente y exhaustiva y asegurar un alto nivel de resiliencia operativa digital.

Las tres palabras del artículo 6 no son adorno. «Sólido» significa que resista una inspección. «Completo» significa que no deje huecos. Y «bien documentado» significa que, si no está escrito y es demostrable, a efectos del supervisor no existe.

Notificación de incidentes graves (artículo 19)

Las entidades financieras deben notificar los incidentes graves relacionados con las TIC a la autoridad competente. Cuando una entidad esté supervisada por más de una autoridad nacional, el Estado miembro designa una autoridad única responsable de recibir esas notificaciones — lo que simplifica el interlocutor, pero no la obligación.

Junto a la notificación obligatoria de incidentes graves, DORA prevé la notificación voluntaria de ciberamenazas importantes: una vía para compartir inteligencia antes de que el incidente ocurra.

Como en NIS2, el problema no es el deber de notificar, sino el tiempo. Detectar, clasificar la gravedad y elevar la notificación exige un procedimiento montado y ensayado. No se improvisa.

Cláusulas contractuales fundamentales (artículo 30)

Este artículo es el que más trabajo está generando en las entidades, y por una razón simple: la mayoría de los contratos TIC firmados antes de 2025 no lo cumplen.

DORA exige que los derechos y obligaciones de la entidad y del proveedor estén claramente asignados y establecidos por escrito, en un contrato completo que incluya los acuerdos de nivel de servicio y que esté disponible en un documento duradero y accesible.

Y fija un contenido mínimo, que empieza por algo aparentemente obvio y sistemáticamente ausente: una descripción clara y completa de todas las funciones y servicios TIC que prestará el proveedor, indicando si se permite la subcontratación de un servicio que sustente una función esencial o importante —y, en tal caso, en qué condiciones—.

Traducción práctica: si su proveedor de nube subcontrata a un tercero una pieza crítica y su contrato no lo contempla, usted tiene un problema de conformidad, no él.

Pruebas de penetración basadas en amenazas: al menos cada tres años (artículo 26)

Aquí DORA aprieta más que la mayoría de marcos. Las entidades financieras —salvo las acogidas al marco simplificado y las microempresas— deben realizar al menos cada tres años pruebas avanzadas de penetración basadas en amenazas (conocidas como TLPT, Threat-Led Penetration Testing), definidas a partir del perfil de riesgo de la entidad y de sus circunstancias operativas.

No son pruebas de laboratorio: son ejercicios que simulan a un adversario real contra sistemas en producción.

Proveedores TIC: el pilar que cambia el mercado (artículos 28 a 31)

Las entidades financieras deben gestionar el riesgo de terceros como parte integrante de su marco de riesgo TIC. En la práctica, eso se traduce en:

• Registro de información de todos los acuerdos contractuales de servicios TIC.
• Cláusulas contractuales obligatorias con los proveedores.
• Evaluación del riesgo de concentración —depender de un único proveedor para funciones críticas—.
• Estrategias de salida creíbles.

Y por encima de todo eso, el artículo 31: las Autoridades Europeas de Supervisión, a través del Comité Mixto y por recomendación del Foro de Supervisión, designan a los proveedores terceros esenciales de servicios de TIC. Una vez designado, el proveedor queda bajo un marco europeo de supervisión directa.

Léase con atención lo que eso significa: un hiperescalar de nube puede acabar supervisado por autoridades financieras europeas por el hecho de ser crítico para el sector.

DORA prevalece sobre NIS2 en el sector financiero

Este punto se pasa por alto con frecuencia y resuelve muchas dudas. El artículo 1, apartado 2, establece que, para las entidades financieras identificadas como esenciales o importantes bajo NIS2, DORA se considera un acto jurídico sectorial de la Unión a efectos del artículo 4 de esa directiva.

Traducido: en lo que DORA regula, es la norma que manda para el sector financiero —opera como lex specialis frente a NIS2—. Eso evita la doble regulación, pero exige delimitar con precisión qué queda cubierto por cada norma. (El panorama de NIS2, en nuestra guía del silo.)

¿Y la inteligencia artificial?

DORA no menciona la IA ni una sola vez. Y sin embargo la regula de lleno: sus definiciones son funcionales, no tecnológicas, de modo que un modelo de scoring, un motor antifraude o un asistente conversacional son servicios de TIC a todos los efectos. Con una consecuencia que sorprende a muchos: su proveedor de IA es, para DORA, un proveedor tercero de servicios de TIC. (Lo desarrollamos en el análisis sobre DORA e inteligencia artificial.)

Hoja de ruta

1. Confirme su encaje: ¿entidad financiera del artículo 2? ¿Le corresponde el marco simplificado del artículo 16?
2. Inventaríe sus servicios TIC y construya el registro de información de proveedores.
3. Revise los contratos: la mayoría de los firmados antes de 2025 no contienen las cláusulas que DORA exige.
4. Evalúe la concentración y prepare estrategias de salida.
5. Monte el marco de gestión del riesgo TIC y llévelo al consejo.
6. Planifique las pruebas, incluidas las TLPT si le corresponden.
7. Prepare la evidencia: tendrá que demostrar, no afirmar.

Qué implica según el tamaño de su entidad

• Entidad pequeña o intermediario: compruebe si le aplica el marco simplificado del artículo 16. Puede ahorrarle una parte sustancial del esfuerzo — pero no le exime.
• Entidad mediana: su exposición real está en el inventario y los contratos con proveedores TIC. Es lo primero que se revisa.
• Gran entidad: además, el programa de TLPT y la evidencia auditable ante el supervisor. Y coordinación con NIS2 y el EU AI Act en un único marco de control.
• Proveedor tecnológico de entidades financieras: aunque usted no sea una entidad financiera, sus clientes le trasladarán las exigencias por vía contractual — y si es esencial, podría acabar designado y supervisado.

El reto de fondo: demostrar la resiliencia, no estimarla

DORA no se conforma con que usted tenga controles: le pide probar que resisten —con TLPT, con pruebas periódicas— y demostrarlo ante el supervisor. Y ahí reaparece la brecha estructural: las pruebas por muestreo y los ejercicios de penetración entregan una estimación de que el sistema aguanta —«no consiguieron entrar esta vez»—; el regulador pide prueba.

Deflank aborda exactamente esa distancia. Con una metodología de verificación propia, convierte los requisitos aplicables en una prueba demostrable, reproducible y auditable, en lugar de una estimación probabilística — y en un solo marco de control para DORA, NIS2 y el AI Act, que es como se abordan sin multiplicar el trabajo.

La prueba, no la estimación.

---

¿Sabría demostrar su resiliencia operativa ante el supervisor? Solicite un diagnóstico de conformidad DORA sin compromiso.

En este silo: [DORA e inteligencia artificial] · [DORA: a quién aplica] · [resiliencia operativa digital]. Puentes: [NIS2] · [EU AI Act].

Contenido informativo; no constituye asesoramiento jurídico. Fuente: Reglamento (UE) 2022/2554, artículos 1, 2, 5, 16, 26, 28, 31 y 64.