El Reglamento DORA (Digital Operational Resilience Act, Reglamento UE 2022/2554) entró en vigor el 17 de enero de 2025 para todas las entidades financieras sujetas a supervisión en la Unión Europea. No es una directiva que cada estado traspone a su ritmo: es un reglamento de aplicación directa, lo que significa que desde esa fecha los supervisores —el BCE, la EBA, la EIOPA, la ESMA y, en España, el Banco de España y la CNMV— pueden requerir evidencia de cumplimiento en cualquier momento. Si tu entidad todavía no tiene un programa formal, estás en mora.
Este artículo no repite el texto del reglamento. Lo que encontrarás aquí es una hoja de ruta operativa: qué hay que hacer, en qué orden, dónde se atascan la mayoría de las organizaciones y cómo estructurar el trabajo para llegar a un nivel de cumplimiento defendible ante el supervisor sin consumir dos años de recursos.
¿Qué exige DORA realmente? Los cinco pilares
El reglamento articula la resiliencia operativa digital en torno a cinco bloques que no son independientes, sino que se alimentan entre sí. Entender la lógica del conjunto evita el error habitual de tratar DORA como una lista de checks sin hilo conductor.
1. Gestión del riesgo TIC (artículos 5-16)
La entidad debe disponer de un marco de gestión del riesgo TIC documentado, aprobado por el órgano de dirección y revisado al menos una vez al año. Este marco incluye la identificación de activos TIC críticos, la evaluación de riesgos, las medidas de protección, los procedimientos de respuesta y recuperación, y el aprendizaje tras incidentes. El órgano de administración tiene responsabilidad directa y no delegable: DORA es explícito en que los miembros del consejo deben mantener conocimiento suficiente sobre riesgos TIC.
2. Gestión, clasificación y notificación de incidentes (artículos 17-23)
Las entidades deben clasificar los incidentes TIC según criterios armonizados que las Autoridades Supervisoras Europeas (ESAs) han concretado en normas técnicas de regulación (RTS). Los incidentes «importantes» se notifican en tres fases: notificación inicial (en las primeras 4 horas desde la clasificación, o máximo 24 horas desde la detección), informe intermedio y informe final. El incumplimiento del plazo de notificación es, por sí solo, motivo de sanción.
3. Pruebas de resiliencia operativa digital (artículos 24-27)
Todas las entidades deben realizar pruebas de sus herramientas y sistemas TIC al menos una vez al año. Las entidades significativas —definidas por umbrales de tamaño y criticidad— deben ir más lejos y realizar pruebas de penetración basadas en amenazas (TLPT) cada tres años, siguiendo el marco TIBER-EU. En España, el Banco de España ya ha iniciado ejercicios TIBER con entidades del sector bancario; la CNMV tiene previsto hacer lo propio con las de valores y fondos.
4. Gestión del riesgo de terceros TIC (artículos 28-44)
Este bloque es, en la práctica, el más costoso de implementar. DORA exige que los contratos con proveedores TIC críticos incluyan cláusulas obligatorias: derechos de auditoría, garantías de continuidad, salida sin perturbación, niveles de servicio, localización de datos y subcontratación. Las entidades deben mantener un registro de información de todos sus acuerdos contractuales con terceros TIC, en formato estandarizado según las RTS de las ESAs. Además, los proveedores TIC críticos designados directamente por las ESAs quedan sujetos a un marco de supervisión directa comunitario.
5. Intercambio de información (artículo 45)
DORA fomenta —y en ciertos casos obliga— a que las entidades participen en mecanismos de intercambio de inteligencia sobre ciberamenazas. En España, el CCN-CERT (Centro Criptológico Nacional) y el CERT Financiero canalizan buena parte de esta información para las entidades supervisadas.
Tabla comparativa: obligaciones según tipo de entidad
| Tipo de entidad | Marco de riesgo TIC | Notificación incidentes | Pruebas anuales | TLPT cada 3 años | Registro de terceros |
|---|---|---|---|---|---|
| Banco significativo (SSM) | Completo + aprobación consejo | Sí (4h / 24h) | Sí | Sí (TIBER-EU) | Sí (formato RTS) |
| Entidad de crédito menos significativa | Completo | Sí (4h / 24h) | Sí | A criterio supervisor | Sí |
| Empresa de servicios de inversión | Completo | Sí | Sí | Si supera umbrales | Sí |
| Empresa de seguros / reaseguros | Completo (coord. con Solvencia II) | Sí | Sí | Si supera umbrales EIOPA | Sí |
| Entidad de pago / dinero electrónico | Simplificado (art. 16) | Sí | Sí (pruebas básicas) | No obligatorio | Sí |
| Gestora de fondos (SGIIC / SGEIC) | Completo | Sí | Sí | Si designada | Sí |
| Microempresa (art. 3.1.k) | Simplificado | Sí | Sí (básicas) | No | Registro simplificado |
Fuente: Reglamento UE 2022/2554 (DORA) y RTS publicadas por EBA/EIOPA/ESMA en 2024.
Hoja de ruta práctica: seis fases para llegar a cumplimiento defendible
La experiencia acumulada desde 2007 acompañando proyectos de cumplimiento normativo en el sector financiero nos ha enseñado que las organizaciones que intentan abordar DORA «en paralelo a lo de siempre» fracasan o generan documentación que no sobrevive una revisión supervisora. La hoja de ruta que proponemos desde nuestro servicio de consultoría NIS2 y DORA organiza el trabajo en seis fases secuenciales, aunque las dos primeras pueden ejecutarse en paralelo.
Fase 1 — Inventario y clasificación de activos TIC (semanas 1-4)
Sin inventario, no hay gestión de riesgos posible. El punto de partida es un mapa completo de todos los sistemas, aplicaciones, infraestructuras, datos y servicios TIC, distinguiendo entre activos propios y servicios prestados por terceros. Para cada activo se determina su criticidad respecto a las funciones de negocio que soporta: si ese sistema cayera, ¿qué capacidad operativa se perdería y en cuánto tiempo? Ese análisis de impacto (BIA, Business Impact Analysis) es el cimiento del resto del programa.
Fase 2 — Evaluación de brechas (gap analysis) contra el marco DORA (semanas 3-6)
Con el inventario sobre la mesa, se coteja la situación actual contra los requisitos del reglamento y los estándares técnicos de regulación (RTS) e implementación (ITS) que lo desarrollan. Las brechas más frecuentes que encontramos en entidades medianas son: ausencia de procedimiento formal de clasificación de incidentes, contratos con proveedores TIC sin cláusulas DORA, y ausencia de pruebas de resiliencia documentadas más allá de un test de recuperación de backup. El resultado de esta fase es un inventario priorizado de acciones.
Fase 3 — Marco de gestión del riesgo TIC y política (semanas 5-12)
Se redacta o actualiza el marco de gestión del riesgo TIC de la entidad: política aprobada por el consejo, metodología de evaluación de riesgos, apetito de riesgo, roles y responsabilidades (incluyendo la figura del CISO o equivalente), y procedimientos operativos para identificación, protección, detección, respuesta y recuperación. Este paquete documental es lo que el supervisor pedirá ver primero en cualquier inspección.
Fase 4 — Remediación de contratos con terceros TIC (semanas 8-20)
La negociación de contratos con proveedores TIC es, con diferencia, la fase que más se alarga. Los grandes proveedores de nube (AWS, Azure, Google Cloud) tienen adendas DORA/NIS2 preaprobadas, pero los proveedores medianos de software core bancario, gestión de riesgos o infraestructura suelen requerir negociación directa. La entidad debe priorizar los contratos de sus proveedores TIC críticos (aquellos que soportan funciones críticas o importantes) e incorporar las cláusulas mínimas del artículo 30 de DORA: accesibilidad, integridad, seguridad, auditoría, continuidad y salida.
Fase 5 — Programa de pruebas y primer ciclo de ejercicios (semanas 12-24)
Se diseña el programa anual de pruebas de resiliencia: tests de conectividad y disponibilidad, pruebas de recuperación ante desastres (DR tests), simulacros de incidentes con el equipo de respuesta, y —para las entidades que lo requieran— planificación del primer ejercicio TLPT con un proveedor de threat intelligence acreditado. El primer ciclo de pruebas genera, además, el informe de resultados que DORA exige conservar y poner a disposición del supervisor.
Fase 6 — Registro de información y gobernanza continua (semanas 20-28)
La fase final establece el registro de información de terceros TIC en el formato exigido por las RTS (campos obligatorios, actualización periódica, trazabilidad de cambios), los indicadores de seguimiento del programa, el plan de formación del órgano de dirección en materia de riesgo TIC, y el calendario de revisiones anuales. A partir de aquí, DORA es un ciclo continuo, no un proyecto con fecha de fin.
Los cinco errores que más retrasan el cumplimiento
Trabajando con entidades que llegaron a enero de 2025 sin programa formal, hemos identificado los bloqueos que más tiempo consumen:
- Tratar DORA como un proyecto de TI. El reglamento atribuye responsabilidad directa al consejo. Sin patrocinio ejecutivo real, el proyecto se queda en el nivel técnico y nunca llega a aprobarse la política.
- Empezar por la documentación en vez de por el inventario. Redactar políticas sin saber qué sistemas existen produce documentos que no reflejan la realidad y que el supervisor descarta.
- Subestimar el volumen de contratos a renegociar. Una entidad mediana con 80-120 proveedores TIC puede tener 30-40 contratos que necesitan adenda. El proceso legal lleva meses.
- Confundir ISO 27001 con cumplimiento DORA. ISO 27001 es compatible y facilita el trabajo, pero no cubre los requisitos específicos de DORA: clasificación de incidentes con los criterios de las ESAs, TLPT, registro de terceros o notificación en plazos concretos.
- No tener en cuenta las normas técnicas de desarrollo. Las RTS e ITS publicadas por la EBA, EIOPA y ESMA en 2024 concretan muchos requisitos que el texto del reglamento deja abiertos. Sin leerlas, el cumplimiento queda incompleto.
DORA y NIS2: zonas de solapamiento y diferencias
Muchas entidades financieras están sujetas simultáneamente a DORA y a la Directiva NIS2 (en proceso de transposición en España mediante el Anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad, en tramitación parlamentaria a la fecha de este artículo). La relación entre ambas normas es de lex specialis: DORA prevalece sobre NIS2 para las entidades financieras en los ámbitos que regula. En la práctica, esto significa que una entidad financiera no tiene que cumplir NIS2 «por encima» de DORA en materia de gestión de riesgos TIC, pero sí debe tener claro qué supervisor controla qué.
Para las entidades que forman parte de grupos con filiales en sectores no financieros, la cuestión es más compleja: las filiales no financieras pueden estar sujetas a NIS2 mientras la matriz financiera cumple DORA. La consultoría especializada en NIS2 y DORA es clave para mapear correctamente el perímetro de cada norma en estructuras de grupo.
Plazos y estado de la supervisión en España (2025-2026)
DORA es aplicable desde el 17 de enero de 2025 sin período transitorio adicional. Sin embargo, la supervisión no se ha activado de forma homogénea desde ese día: los supervisores están en fase de revisión documental inicial y publicación de expectativas. El Banco de España publicó en enero de 2025 una comunicación interna dirigida a entidades significativas solicitando el estado de implementación. La CNMV ha iniciado cuestionarios de autoevaluación a empresas de servicios de inversión y gestoras.
El horizonte de las primeras inspecciones formales con posibilidad de sanción se sitúa, según las señales del mercado y las declaraciones públicas de los supervisores, entre el segundo semestre de 2025 y el primer semestre de 2026. Las entidades que en esa ventana no puedan presentar un programa documentado y evidencias de pruebas realizadas se exponen a requerimientos formales y, en los casos más graves, a sanciones previstas en los regímenes sancionadores sectoriales a los que DORA remite (capítulo VII, artículos 50-51). El umbral del 1 % del volumen de negocios diario medio mundial que establece DORA en su artículo 64 aplica específicamente a los proveedores TIC críticos designados por las ESAs, no a las entidades financieras, cuyas sanciones las fija cada normativa sectorial nacional.
Preguntas frecuentes
¿DORA aplica a una fintech pequeña con licencia de entidad de pago?
Sí, pero con un régimen simplificado. El artículo 16 de DORA establece un marco de gestión del riesgo TIC simplificado para microempresas y determinadas entidades de menor tamaño. Las entidades de pago y de dinero electrónico que no superen los umbrales de clasificación como entidades significativas pueden acogerse a este régimen, que reduce los requisitos documentales y de gobernanza, aunque mantiene las obligaciones de notificación de incidentes y el registro de proveedores TIC. En la práctica, incluso bajo el régimen simplificado, una fintech debe tener política TIC, procedimiento de incidentes y contratos con proveedores adaptados.
¿Qué ocurre si un proveedor TIC se niega a renegociar el contrato?
DORA no obliga al proveedor, obliga a la entidad financiera. Si un proveedor que presta servicios a una función crítica o importante se niega a incluir las cláusulas del artículo 30, la entidad tiene tres opciones: iniciar un proceso formal de sustitución, solicitar una exención temporal justificada ante el supervisor, o asumir que el contrato no cumple y documentar la situación con un plan de remediación. La primera opción es la más limpia pero la más costosa. En la práctica, la mayoría de los grandes proveedores de software financiero han publicado ya adendas DORA o están en proceso de hacerlo, ya que sus clientes se lo exigen de forma generalizada.
¿Cuánto tiempo lleva completar el programa DORA en una entidad mediana?
En entidades con entre 200 y 1.000 empleados y una infraestructura TIC moderadamente compleja (50-100 proveedores TIC, sistemas core internos y en nube), el programa completo hasta obtener un nivel de cumplimiento defendible ante el supervisor requiere entre 9 y 18 meses. Los factores que más alargan el proceso son el volumen de contratos a renegociar, la madurez previa en gestión de riesgos TIC y la capacidad del equipo interno para absorber el trabajo paralelo. Comenzar con un equipo externo especializado reduce el tiempo en un 30-40% en la fase de gap analysis y elaboración del marco documental.
¿Qué diferencia hay entre las pruebas anuales y los TLPT?
Las pruebas anuales que exige DORA a todas las entidades son ejercicios de verificación interna: tests de conectividad, pruebas de recuperación ante desastres, simulacros de incidentes. No requieren un proveedor externo específico ni validación del supervisor. Los TLPT (Threat-Led Penetration Testing) son ejercicios avanzados que simulan las tácticas, técnicas y procedimientos de actores de amenaza reales, utilizando inteligencia de amenazas actualizada. Se realizan cada tres años, con proveedores acreditados según el marco TIBER-EU, bajo la coordinación del supervisor y con acceso a los sistemas de producción. Son mucho más invasivos, costosos (entre 150.000 y 500.000 euros en entidades medianas, según el alcance) y revelan vulnerabilidades que las pruebas internas no detectan.