Regulación

DORA

Digital Operational Resilience Act

Reglamento europeo en vigor desde enero de 2025 que impone a todos los actores financieros —bancos, fintechs, aseguradoras, CASP— un marco estricto de resiliencia de TI.

Definición

DORA (Digital Operational Resilience Act) es un reglamento europeo en vigor desde el 17 de enero de 2025.

Impone a todos los actores financieros de la UE —bancos, fintechs, aseguradoras, CASP, gestoras de activos, plataformas de crowdfunding— un marco estricto de resiliencia operativa de TI: gestión de riesgos, gestión de incidentes, pruebas de penetración, supervisión de los proveedores de TI críticos.

Por qué existe DORA

Antes de DORA, la resiliencia de TI estaba fragmentada: cada sector tenía sus reglas, y los proveedores de TI críticos (nube, SaaS, procesadores de pago) escapaban a toda supervisión — aunque una avería en uno de ellos pudiera paralizar el sistema financiero. DORA armoniza todo eso en un marco paneuropeo único.

Los 5 pilares

  • Gestión de riesgos de TI: gobernanza, mapeo de los activos y procesos críticos, copia de seguridad, restauración, plan de continuidad.
  • Gestión de incidentes: clasificación y notificación obligatoria a la NCA en plazos cortos (notificación inicial en un plazo de 4h, informe intermedio en 72h).
  • Pruebas de resiliencia: escaneos, auditorías y, para los actores significativos, un TLPT (Threat-Led Penetration Testing) cada 3 años.
  • Riesgo de terceros de TI: registro obligatorio de los proveedores críticos, contratos regulados, due diligence, derecho de auditoría.
  • Intercambio de información: participación en el intercambio de Cyber Threat Intelligence entre los actores.

La gran novedad: supervisar a los proveedores de TI críticos

Es la innovación más disruptiva. Los proveedores considerados críticos para el sistema financiero —AWS, Azure, Google Cloud, OVH, pero también editores de SaaS especializados— son designados por las AES (EBA, ESMA, EIOPA) y colocados bajo supervisión europea directa: auditorías, sanciones, incluso obligación de modificar sus prácticas. Es la primera vez que un proveedor de nube estadounidense es supervisado directamente por un regulador europeo.

Lo que DORA no hace

  • No crea ningún estatus nuevo: se aplica por encima de los estatus existentes (banco, EP, EDE, CASP, aseguradora).
  • No cubre los datos personales: eso es el RGPD.
  • No sustituye a NIS 2 (ciberseguridad general de la UE) pero se articula con ella.
  • No exime de las reglas sectoriales (PSD2, MiCA, Solvencia II): se añade a ellas.

Calendario

  • Diciembre de 2022 — adopción del reglamento.
  • Enero de 2023 → enero de 2025 — 24 meses de adaptación.
  • 17 de enero de 2025 — aplicación efectiva, sin excepción.
  • 2025-2026 — primeros controles reforzados y primeras designaciones de proveedores de TI críticos.

En el ecosistema PSD2

DORA no es específica de la PSD2, pero toda fintech que opere un servicio de pago se ve afectada. Es ya una pieza de cumplimiento ineludible, al mismo nivel que la SCA o la lucha contra el blanqueo de capitales.

Ejemplos concretos

  • Reporte de incidente: una API que se cae 2 horas en plena producción desencadena 4h para notificar a la ACPR y 72h para un informe intermedio — algo que cablear en el runbook antes del incidente.
  • TLPT: un PSP como Worldline, Adyen o Stripe Europe organiza un Threat-Led Penetration Testing cada 3 años, llevado a cabo por un proveedor autorizado (100 a 500 K€ por ejercicio).
  • Supervisión de la nube: alojar la infraestructura crítica en AWS exige un contrato DORA-compliant (reversibilidad, derecho de auditoría, plan de salida), de ahí los contratos fintech de la UE que ofrecen AWS, Azure y GCP desde 2024.
  • Registro de los proveedores de TI: mantenido al día con la criticidad y un plan de salida, a menudo vía OneTrust, MetricStream u hojas de cálculo internas.
  • Plan de continuidad: poder conmutar a un sitio o una nube secundaria en caso de incidente grave — una exigencia concreta, que hay que probar con regularidad.
  • Vigilancia: seguir los RTS y las directrices de las AES y el calendario de designación de los proveedores de TI críticos.

Fuentes

Profundizar

En el blog

Lecturas más completas para ir más allá de la definición.

7 de abril de 2026
técnico

Arquitectura técnica de una API DSP2: lo que hay que saber antes de escribir la primera línea de código — Leer el artículo

Panorama técnico de la DSP2 para CTO, desarrolladores y PM técnicos: estándares de API, seguridad (mTLS, certificados eIDAS), OAuth2, flujos SCA, gestión del consentimiento, trampas de implementación.

6 de abril de 2026
regulación

Entender la PSD2: lo que cambia para sus clientes y su negocio — Leer el artículo

Todo lo que un directivo, un product manager o un equipo de negocio debe entender de la PSD2 (DSP2). Actores, consentimiento, oportunidades, sin jerga técnica.