DORA aplicable desde el 17 de enero: Reglamento (UE) 2022/2554 y los cinco pilares operativos

El 17 de enero de 2025 entra en aplicación el Reglamento (UE) 2022/2554 —DORA, Digital Operational Resilience Act— para el sector financiero europeo. La fecha estaba en el calendario desde su publicación en el DOUE el 27 de diciembre de 2022, con dos años de transición. El reglamento estaba ya en vigor desde finales de 2022; lo que cambia este 17 de enero es la aplicabilidad —a partir de esta fecha, las obligaciones son exigibles y las autoridades pueden empezar a inspeccionar.

DORA cubrimos su recordatorio operativo en el boletín de diciembre. Este post entra en detalle: a quién aplica, los cinco pilares de obligaciones, cómo se relaciona con NIS2, qué se exige el 17 de enero y qué se exige durante los próximos 12-36 meses.

Lectura: análisis del texto publicado en DOUE (versión consolidada) y de las Regulatory Technical Standards (RTS) y Implementing Technical Standards (ITS) publicadas por las ESAs —EBA, ESMA, EIOPA— durante 2024. Las RTS sobre TLPT se aprueban formalmente a mediados de 2025; este post anticipa el calendario sobre el draft final disponible.

A quién aplica

El Art. 2 de DORA define el ámbito subjetivo. Dos categorías:

Entidades financieras (Art. 2.1)

Veinte tipos de entidad listados, agrupables en bloques:

• Crédito y pagos: entidades de crédito (bancos), entidades de pago, entidades de dinero electrónico, proveedores de servicios de información de cuentas (AISPs bajo PSD2).
• Inversión y mercados: empresas de servicios de inversión, gestoras de fondos UCITS y AIFs, depositarios centrales de valores (CSDs), entidades de contrapartida central (CCPs), centros de negociación, repositorios de operaciones (TRs), proveedores de servicios de crowdfunding.
• Seguros: empresas de seguros y reaseguros, intermediarios de seguros y reaseguros, IORPs (instituciones de pensiones de empleo).
• Cripto regulado: proveedores de servicios de criptoactivos autorizados bajo MiCA (Reglamento 2023/1114), emisores de asset-referenced tokens.
• Otros: gestoras de fondos de inversión a largo plazo (ELTIFs), agencias de calificación crediticia, administradores de benchmarks críticos, proveedores de servicios de reporting de datos.

Hay exenciones limitadas para entidades pequeñas (Art. 16) con régimen simplificado, pero la regla general es: si está autorizada como entidad financiera bajo legislación EU, está bajo DORA.

Proveedores ICT terceros críticos (Art. 2.2 y Cap. V Sección II)

Los ICT third-party service providers (TPPs) no están bajo DORA por defecto. Lo están cuando son designados como críticos por las ESAs (Art. 31). La designación se basa en criterios del Art. 31.2: impacto sistémico, dependencia operativa de entidades financieras, sustituibilidad. El primer batch de designaciones se espera durante 2025; las ESAs publicarán la lista oficial.

Categorías de TPPs que probablemente caerán en críticos: hiperscalers cloud (AWS, Microsoft Azure, Google Cloud), proveedores SaaS de core banking (Temenos, Finastra, Mambu), plataformas de market data (Bloomberg, Refinitiv), proveedores de SWIFT messaging, proveedores de identity (Okta, IBM, Microsoft), MSSPs grandes. El régimen de los TPPs críticos es de oversight directo por las ESAs, no exigencias de cumplimiento al estilo de las entidades financieras.

Quién queda fuera

• Aseguradoras y reaseguradoras pequeñas bajo el umbral de Solvencia II.
• Microempresas (Art. 3.60 con definición del Anexo a la Recomendación 2003/361/CE), con régimen muy simplificado.
• Auditores externos —no son TPPs en el sentido de DORA.
• Entidades financieras de terceros países sin sucursal en la UE —pero si tienen sucursal autorizada, la sucursal sí aplica.

Los cinco pilares de obligaciones

DORA estructura las obligaciones en cinco bloques. Cada uno tiene su capítulo y artículos. Tabla operativa:

Los cinco se aplican de golpe el 17 de enero. El que requiere planificación a 12-36 meses por separado es el TLPT.

Pilar 1 — ICT risk management framework

El Art. 6 establece la pieza central: un ICT risk management framework documentado, aprobado por el órgano de dirección de la entidad, integrado en la estrategia de negocio y revisado al menos una vez al año.

Componentes obligatorios (Arts. 7–14):

• Identificación: inventario de funciones de negocio que dependen de ICT, business impact analysis (BIA) que mapea cada función a sistemas, activos, dependencias. Clasificación de activos por criticidad y sensibilidad.
• Protección y prevención: políticas de seguridad de la información, control de accesos, gestión de identidades, segmentación de redes, cifrado, gestión de cambios, gestión de parches, hardening.
• Detección: mecanismos de monitoring continuo, alerting, capacidad de detectar incidentes anómalos en tiempo razonable.
• Respuesta y recuperación: ICT business continuity policy, planes de respuesta, planes de recuperación con RTOs y RPOs por función, sitios de recuperación, backups inmutables.
• Aprendizaje y evolución: lecciones aprendidas tras incidentes, mejora continua, ICT-related incident root cause analysis.

Para entidades grandes (no microempresas), Art. 6.4 exige un rol de control independiente que supervise la gestión del riesgo ICT —típicamente el CISO con reporte funcional al consejo o comité de riesgos.

Pilar 2 — ICT-related incident management y reporting

Cap. III es donde DORA aprieta más sobre el día a día operativo. El Art. 17 obliga a un proceso documentado de gestión de incidentes ICT. El Art. 18 obliga a clasificar cada incidente y a determinar si es major según criterios del RTS sobre clasificación (publicado por las ESAs en 2024).

Criterios de major incident del RTS (combinación de):

1. Número de clientes afectados / valor de transacciones afectado.
2. Reputación.
3. Duración.
4. Dispersión geográfica.
5. Pérdida de datos.
6. Criticidad de los servicios afectados.
7. Impacto económico.

Si el incidente cruza los umbrales, hay obligación de reportar a la autoridad competente nacional (en España, Banco de España, CNMV, DGSFP según el tipo de entidad) con plazos del Anexo III:

Significant cyber threats (Art. 19): obligación voluntaria de notificar amenazas cyber significativas que no se han materializado en incidente pero que se han detectado.

El reporte usa plantillas armonizadas que las ESAs publican como ITS. No es prosa libre.

Pilar 3 — Digital operational resilience testing

El Cap. IV (Arts. 24–27) distingue dos niveles de testing:

Testing general (Art. 24–25) —obligatorio para todas las entidades sujetas. Programa anual de testing que incluye, según criticidad: vulnerability assessments, scans, source code reviews, scenario-based tests, compatibility testing, performance testing, end-to-end testing, penetration testing. Las entidades pequeñas tienen régimen proporcional.

TLPT —Threat-Led Penetration Testing (Arts. 26–27) —obligatorio para entidades importantes designadas por la autoridad competente nacional según criterios del RTS sobre TLPT.

El RTS final sobre TLPT (publicado por las ESAs en julio 2024, en aprobación de la Comisión durante 2025) establece:

• Frecuencia: al menos una vez cada tres años (Art. 26.1).
• Alcance: sistemas críticos de producción, no entornos de prueba. Cubrir funciones críticas que soportan servicios financieros principales.
• Metodología: estructura prácticamente alineada con TIBER-EU —el framework de threat-led red teaming que el BCE coordina desde 2018. Test consiste en: scoping, threat intelligence específica (Targeted Threat Intelligence report producido por un TI provider acreditado), red team exercise (semanas-meses), post-test reporting, remediation tracking.
• Testers: pueden ser externos o internos. Internos permitidos en hasta dos de cada tres ciclos (un test cada tres ciclos debe ser externo). Los testers deben cumplir requisitos del Art. 27 —certificaciones reconocidas, experiencia mínima, separación de funciones.
• Primer TLPT: el plazo para completar el primer TLPT depende de la designación de la entidad como sujeta a TLPT por la autoridad competente. Para las primeras designaciones (durante 2025), la fecha realista de primer TLPT cae en 2027–2028.

Para un equipo de red team interno, lo operativo del TLPT son tres cosas:

1. El TI provider tiene que estar acreditado. No es un consultor de pentesting genérico —tiene que producir un Targeted Threat Intelligence report siguiendo metodología TIBER-EU. La lista de TI providers acreditados la mantiene cada banco central nacional.
2. El test es intelligence-led. Antes de empezar a romper, hay 4-6 semanas de TI dedicada a la entidad: qué actores la persiguen, qué TTPs usan, qué objetivos asumirían. El red team simula esos actores, no actores genéricos.
3. Hay un Test Authority —típicamente el banco central nacional, en España el Banco de España vía TIBER-ES— que coordina el ejercicio, valida los entregables y archiva el reporte final. No es ejercicio interno auto-validado.

Pilar 4 — ICT third-party risk management

Cap. V Sección I (Arts. 28–30) obliga a gestionar el riesgo ICT terceros. Las piezas operativas:

Register of information (Art. 28.3) —cada entidad mantiene un registro detallado de todos los contractual arrangements con TPPs ICT, distinguiendo los que soportan funciones críticas o importantes. El registro usa el formato armonizado del ITS sobre register of information (publicado por las ESAs en 2024). Se entrega anualmente a la autoridad competente.

Due diligence pre-contractual (Art. 28.4) —antes de firmar, evaluación del riesgo del proveedor: situación financiera, capacidades técnicas, controles de seguridad, ubicación de datos, riesgo de concentración, dependencias del proveedor con otros proveedores (cuarta-parte risk).

Cláusulas contractuales obligatorias (Art. 30) —Anexo del Art. 30 lista cláusulas que deben estar en contratos con TPPs que soportan funciones críticas. Bloque operativo:

• Descripción completa del servicio.
• SLAs con métricas medibles.
• Ubicaciones de procesamiento de datos.
• Disposiciones sobre seguridad de la información.
• Derecho de acceso, inspección y auditoría para la entidad financiera y para la autoridad competente.
• Cooperación con las autoridades.
• Disposiciones de exit strategy con plazos y portabilidad.
• Subcontratación: condiciones, notificación previa, cadena visible.

Concentración (Art. 29) —exigencia de evaluar y mitigar el riesgo de concentración con un único TPP o con un grupo de TPPs interdependientes. Para entidades grandes, el regulador puede pedir reducción activa de concentración.

Oversight de TPPs críticos (Cap. V Sección II) —para los proveedores designados como críticos (Art. 31), aplican obligaciones directamente a ellos vía oversight de las ESAs. Esto es nuevo en EU —es la primera vez que las ESAs ejercen supervisión directa sobre proveedores no financieros.

Pilar 5 — Information & intelligence sharing

El Art. 45 habilita —no obliga— el intercambio de cyber threat intelligence entre entidades financieras dentro de trusted communities. La idea operativa es facilitar legalmente que un banco comparta IoCs y TTPs con otros sin riesgo legal por intercambio de información de clientes o datos personales.

Para esto las entidades necesitan: arreglos de intercambio documentados, salvaguardas de confidencialidad, salvaguardas de protección de datos (compatible con GDPR), validación de la fuente, marco de uso de la información recibida.

En la práctica, este pilar se construye sobre comunidades ya existentes —FS-ISAC, comunidades nacionales tipo CCN-CERT, ENISA Financial Sector Cyber Threat Intelligence Group. DORA da soporte legal sin reemplazar lo existente.

Mapping DORA ↔ NIS2 ↔ NIST CSF 2.0

DORA convive con NIS2 (Directiva 2022/2555) y con frameworks como NIST CSF 2.0. La regla administrativa importante:

DORA es lex specialis para el sector financiero. Donde DORA y NIS2 coinciden sobre la misma entidad, DORA prevalece (Art. 1.2 de DORA y Art. 4 de NIS2).

Esto resuelve el conflicto de obligaciones pero no la duda operativa, porque muchas entidades financieras también son operadores de servicios esenciales bajo NIS2 vía actividades no-financieras (procesamiento de pagos para infraestructura crítica, por ejemplo). Mapping práctico:

La diferencia más operativa para un CISO de banco que ya estaba mapeando NIS2: DORA es más prescriptivo en testing y en third-party. NIS2 dice “haz testing de resiliencia”; DORA dice “haz testing anual y, si eres importante, TLPT cada 3 años con TI provider acreditado y autoridad supervisora”. NIS2 dice “gestiona riesgo de proveedores”; DORA dice “lleva un register con formato armonizado, mete estas cláusulas en contratos, y si tu proveedor es designado crítico, las ESAs lo supervisan directamente”.

El reporte de incidentes también difiere: DORA exige reporte inicial en 4 horas desde clasificación como major; NIS2 exige early warning en 24h pero el inicial real es a 72h. Para una entidad financiera con incidente que cruza umbrales de las dos normas, los plazos más estrictos son los de DORA.

Flowchart de decisión

Para una organización que se pregunta si DORA aplica:

1. ¿Eres entidad financiera autorizada bajo legislación EU? (banco, fintech, gestora, aseguradora, IORP, CASP MiCA, etc.) → DORA aplica desde 17-ene-2025. Va al paso 4.
2. ¿Eres ICT third-party provider designado como crítico por las ESAs? (la lista la publican las ESAs durante 2025-2026) → Oversight directo de las ESAs bajo Cap. V Sección II. Régimen diferente al de entidades financieras.
3. ¿Eres ICT third-party provider no designado pero das servicio a entidades financieras? → DORA no te aplica directamente, pero tus clientes financieros te van a pasar cláusulas DORA-compliant. Prepárate para auditorías, derechos de acceso, exit strategies con plazos, register entries que tu cliente va a entregar a su autoridad.
4. Estás bajo DORA. ¿Eres “entidad importante” según los criterios del RTS sobre TLPT? (umbrales por activos bajo gestión, número de clientes, criticidad sistémica) → Sí: añade TLPT cada 3 años. No: testing general anual, sin TLPT obligatorio.
5. ¿Eres también operador de servicios esenciales bajo NIS2? → DORA prevalece para las obligaciones que se solapan. NIS2 aplica al resto.

La pregunta 2 es la que más debate va a generar durante 2025: las primeras designaciones de TPPs críticos van a marcar precedente operativo —qué hiperscalers, qué SaaS de core banking, qué proveedores de identity. La metodología de designación está en el RTS sobre criticality assessment.

Qué tener listo a 17 de enero

Para un CISO o COO de entidad financiera que llega a la fecha con trabajo pendiente, mínimo viable a 17-ene-2025:

1. ICT risk management framework documentado y aprobado por el consejo / órgano de dirección. Aunque sea v1 perfeccionable, tiene que existir con aprobación formal.
2. Inventario completo de funciones de negocio críticas y de activos ICT que las soportan, con BIA preliminar. RTOs y RPOs definidos por función.
3. Política de gestión de incidentes ICT con criterios de clasificación alineados con el RTS, escalation interno definido, plantilla de reporte inicial preparada para los 4h del Anexo III.
4. Register of information de proveedores ICT —al menos para los que soportan funciones críticas. Formato armonizado del ITS. Se entregará por primera vez con periodicidad anual; la entrega real al regulador suele caer en Q1-Q2 de cada año.
5. Revisión de contratos con TPPs críticos —identificar gaps con las cláusulas obligatorias del Art. 30, plan de renegociación. Los contratos antiguos no se renegocian de golpe el 17 de enero; pero hay que tener identificado qué falta y plan de remediación.
6. Programa anual de testing con calendario para 2025: qué tipos de test, qué sistemas, qué proveedores.
7. Designación interna del rol de control independiente de riesgo ICT (típicamente el CISO con reporte funcional al consejo o comité de riesgos).

Lo que no tiene que estar a 17 de enero pero sí en el calendario:

• Primer TLPT: 24-36 meses desde la designación de la entidad como sujeta. Empieza con designación durante 2025 → primer TLPT 2027-2028.
• Migración total de contratos a cláusulas DORA-compliant: realista a 2-3 años.
• Integración completa del marco con NIS2 si aplicable: NIS2 sigue sin transponer en España al 17 de enero. Cuando se transponga, hay solape que coordinar.

Lo que sigue abierto

A 17 de enero quedan cosas pendientes:

• Lista oficial de TPPs designados como críticos: las ESAs publicarán durante 2025. La metodología de designación está en RTS pero la lista no.
• RTS final sobre TLPT: el draft de julio 2024 está en aprobación de la Comisión Europea. La versión final con Official Journal publication se espera durante 2025.
• Transposición de NIS2 en España: anteproyecto en Cortes a diciembre 2024, sin fecha firme de aprobación. La coordinación operativa DORA ↔ NIS2 en España depende de cómo quede la ley nacional de NIS2.
• Sanciones específicas: DORA no tiene tramos de multa al estilo del AI Act o el GDPR. Las sanciones se aplican vía régimen sancionador de cada autoridad competente nacional. En España aplicará el régimen de Banco de España, CNMV o DGSFP según el sector.
• Primer ciclo de inspección: las autoridades nacionales abrirán inspecciones a partir del 17 de enero. Las primeras se esperan dirigidas a entidades sistémicas; el resto del sector lo verá durante 2025-2026.

Referencias

• Texto oficial DOUE — Reglamento (UE) 2022/2554: https://eur-lex.europa.eu/eli/reg/2022/2554/oj
• Art. 6 (ICT risk management framework): https://www.digital-operational-resilience-act.com/Article_6.html
• Arts. 26–27 (Threat-Led Penetration Testing): https://www.digital-operational-resilience-act.com/Article_26.html
• ESAs Joint Committee — DORA RTS and ITS published 2024: https://www.eba.europa.eu/regulation-and-policy/operational-resilience
• ESAs Final report on DORA RTS on TLPT (JC 2024/29, julio 2024): https://www.esma.europa.eu/sites/default/files/2024-07/JC_2024-29_-_Final_report_DORA_RTS_on_TLPT.pdf
• TIBER-EU framework (BCE): https://www.ecb.europa.eu/paym/cyber-resilience/tiber-eu/html/index.en.html
• TIBER-ES (Banco de España): https://www.bde.es/wbe/es/areas-actuacion/estabilidad-financiera-y-politica-macroprudencial/ciberresiliencia/tiber-es.html
• EIOPA — DORA overview: https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en
• Post previo de IRONHACKERS: Boletín — diciembre 2024