Reglamento DORA: qué es, a quién afecta y cómo cumplirlo

Durante años, la resiliencia tecnológica de bancos, aseguradoras y gestoras se ha basado en buenas intenciones: políticas bien redactadas, controles “sobre el papel” y la confianza de que, si algo fallaba, ya se resolvería. El Reglamento DORA (Digital Operational Resilience Act) cambia esa lógica de raíz. A partir de su plena aplicación, el 17 de enero de 2025, ya no basta con tener un plan de continuidad archivado en una carpeta: hay que demostrar, con evidencias verificables, que ese plan funciona.

En este artículo repasamos qué es DORA, a quién obliga, cómo se estructura, qué ocurre si no se cumple y, sobre todo, cómo puede una entidad financiera adaptarse a la normativa de forma ordenada.

DORA es el Reglamento (UE) 2022/2554, publicado el 27 de diciembre de 2022 dentro del Paquete de Finanzas Digitales de la Comisión Europea. Es el primer marco regulatorio europeo diseñado específicamente para gestionar el riesgo sistémico de origen tecnológico en el sector financiero.

¿Por qué era necesario? Porque la digitalización financiera de las últimas dos décadas —banca digital, pagos instantáneos, algoritmos de trading, modelos de datos en seguros— trajo consigo una fragilidad estructural nueva:

• Concentración en pocos proveedores cloud, capaces de afectar a cientos de entidades si fallan simultáneamente.
• Externalización masiva sin control proporcional: funciones críticas gestionadas por terceros sin cláusulas de auditoría, plazos de notificación ni estrategias de salida.
• Interconexión sin visibilidad: dependencias tecnológicas entre entidades que ningún supervisor podía mapear con claridad.

Antes de DORA, cada Estado miembro regulaba estos riesgos de forma distinta, lo que generaba incertidumbre y desigualdad de exigencias. Al tratarse de un reglamento (no una directiva), DORA es de aplicación directa y uniforme en toda la UE, sin margen de transposición nacional en sus elementos esenciales.

El ámbito de aplicación es muy amplio: más de veinte categorías de entidades, entre ellas entidades de crédito, aseguradoras y reaseguradoras, empresas de servicios de inversión y gestoras de activos, infraestructuras de mercado, entidades de pago y de dinero electrónico, y proveedores de servicios de criptoactivos.

Pero DORA no exige lo mismo a todas por igual. El principio de proporcionalidad (artículo 4) ajusta las obligaciones al tamaño, la complejidad, el perfil de riesgo y el grado de dependencia tecnológica de cada entidad. Esto significa que una entidad mediana con un perfil de riesgo alto puede tener exigencias más intensas que una entidad grande con un perfil bajo. Las microempresas, además, pueden acogerse a un régimen simplificado de gestión del riesgo.

Un punto especialmente novedoso: DORA también alcanza, bajo ciertas condiciones, a proveedores tecnológicos que dan servicio a entidades financieras. Los llamados CTPP (Critical Third-Party Providers) —proveedores cuyo tamaño e interconexión los convierten en un riesgo sistémico para todo el sector— quedan sujetos a supervisión directa por un supervisor europeo, aunque no sean entidades financieras. Es la primera vez que la regulación financiera europea llega directamente a un proveedor tecnológico.

DORA se organiza en cinco bloques que conviene tener siempre presentes a la hora de planificar el cumplimiento:

1. Gestión del riesgo TIC: exige un marco formal, documentado y proporcional al perfil de riesgo, con políticas, inventario de activos, controles y mecanismos de seguimiento. La responsabilidad última recae en el órgano de dirección, que no puede delegar la supervisión ni la rendición de cuentas.
2. Gestión, clasificación y notificación de incidentes TIC: establece criterios homogéneos para decidir cuándo un incidente es “grave” y activa la obligación de notificar al supervisor en plazos estrictos (notificación inicial en 4 horas desde la clasificación, informe intermedio en 72 horas y final en un mes).
3. Pruebas de resiliencia operativa digital: todas las entidades deben realizar pruebas básicas al menos anuales; las entidades más significativas están además sujetas a los TLPT (Threat-Led Penetration Testing), pruebas de penetración basadas en inteligencia de amenazas reales, alineadas con el marco europeo TIBER-EU.
4. Gestión del riesgo de terceros proveedores TIC: el principio central es que externalizar no equivale a transferir el riesgo. Las entidades deben mantener un registro de proveedores (artículo 28), incluir cláusulas contractuales mínimas (artículo 30) y ejercer supervisión continua durante toda la vida del contrato.
5. Intercambio de información sobre amenazas: fomenta compartir inteligencia sobre ciberamenazas entre entidades para elevar la capacidad de anticipación del sector, sin sustituir las obligaciones de control interno.

DORA obliga a los Estados miembros a establecer sanciones “efectivas, proporcionadas y disuasorias”. Las infracciones se dividen en dos niveles:

• Graves: incumplimiento reiterado de la notificación de incidentes, ausencia de un marco de gestión del riesgo TIC conforme al artículo 6, incumplimiento de las pruebas de resiliencia exigidas o de las cláusulas contractuales mínimas con proveedores críticos.
• Leves: deficiencias documentales, retrasos en la notificación o incumplimientos procedimentales sin impacto operativo relevante.

Las consecuencias pueden ser administrativas (requerimientos de cese, planes de recuperación supervisados, restricciones de actividad) o económicas. Para personas jurídicas, las multas pueden llegar al 1% del volumen de negocio diario medio del ejercicio anterior por cada día de infracción, o hasta 10 millones de euros en importe fijo, aplicándose la cifra mayor. Para personas físicas responsables de la gestión, hasta 5 millones de euros.

DORA exige la publicación de las sanciones firmes, con el tipo de infracción y la identidad de la entidad sancionada. En muchos casos, el daño reputacional de esa publicidad pesa más que la propia multa.

Cumplir con DORA no es un proyecto de TI aislado, sino un ejercicio de gobierno corporativo. Estos son los pasos que marcan la diferencia entre un cumplimiento real y uno meramente cosmético:

1. Empezar por un diagnóstico de madurez

Antes de actuar, hay que saber dónde se está. Un diagnóstico de madurez evalúa el nivel de implantación efectiva de cada uno de los cinco pilares, normalmente sobre una escala de cinco niveles (desde “inicial” hasta “optimizado”). Es habitual —y normal— que una misma entidad tenga niveles muy distintos según el pilar: gobierno TIC maduro, pruebas de resiliencia en fase inicial, gestión de terceros por desarrollar. Ese diagnóstico debe repetirse al menos una vez al año.

2. Traducir el diagnóstico en una hoja de ruta

La hoja de ruta de cumplimiento convierte el diagnóstico en un plan de acción con iniciativas concretas (no genéricas), responsables con nombre y apellido, plazos coherentes con la criticidad de cada brecha, y criterios de cierre verificables. Debe organizarse en tres horizontes: inmediato (0-90 días, para las brechas de mayor riesgo regulatorio), medio plazo (3-12 meses) y largo plazo (más de 12 meses, para cambios estructurales).

3. Poner el gobierno en el centro

El órgano de dirección debe aprobar la estrategia de resiliencia, supervisar su implementación, asignar presupuesto y ser informado regularmente de incidentes y resultados de pruebas. No se trata de que el consejo sea experto técnico, sino de que comprenda el perfil de riesgo, haga las preguntas adecuadas y actúe cuando detecte insuficiencias. Un consejo que aprueba informes TIC sin cuestionamiento ni debate documentado en actas es, para cualquier supervisor, una señal de gobierno deficiente.

4. Construir (y mantener vivo) el inventario de activos TIC

No es posible gestionar lo que no se conoce. El inventario debe identificar y clasificar los activos según su criticidad, con responsable asignado, dependencias, datos tratados y controles asociados. Debe mantenerse actualizado de forma continua, no como un ejercicio puntual.

5. Blindar los contratos con proveedores

Revisar todos los contratos con proveedores TIC que soporten funciones críticas o importantes, incorporando las cláusulas mínimas del artículo 30: descripción de servicios, niveles de servicio medibles, derecho de auditoría, obligación de notificación de incidentes y estrategia de salida. La supervisión no debe terminar con la firma del contrato: hay que hacer seguimiento continuo del rendimiento, la seguridad, los cambios relevantes y la concentración de riesgo.

6. Diseñar y probar de verdad el plan de continuidad

Un plan de continuidad que nadie ha leído ni ejecutado en condiciones realistas no es un plan, es un documento. DORA convierte la prueba periódica en obligación legal. El punto de partida siempre debe ser un análisis de impacto en el negocio (BIA) que fije objetivos de tiempo de recuperación (RTO) y de punto de recuperación (RPO) por función crítica.

7. Cerrar el ciclo: auditoría, hallazgos y mejora continua

Cada prueba, auditoría o incidente debe generar hallazgos clasificados por criticidad, con planes de acción correctora asignados, plazos y verificación independiente del cierre. Un hallazgo que reaparece sin resolver en ciclos sucesivos es, para el supervisor, un indicador de gobierno deficiente mucho más grave que el propio hallazgo.