Desde el 17 de enero de 2025, el Reglamento (UE) 2022/2554 (conocido como DORA, Digital Operational Resilience Act) es de aplicación directa en toda la Unión Europea. No necesita transposición nacional. No tiene el problema de España con el BOE que tiene NIS2. Aplica ya, sin margen de interpretación, a un perímetro muy concreto de entidades del sector financiero.
Y sin embargo, muchas de esas entidades, y especialmente sus proveedores tecnológicos, no tienen claro qué les obliga DORA exactamente, en qué se diferencia de NIS2 y cuándo tienen que cumplir los dos a la vez.
Quién está obligado por DORA
El artículo 2 de DORA define su ámbito de aplicación con una lista cerrada. Están dentro:
- Entidades de crédito (bancos y cajas).
- Entidades de pago y dinero electrónico.
- Empresas de servicios de inversión.
- Gestoras de fondos de inversión alternativa y UCITS.
- Empresas de seguros y reaseguros.
- Fondos de pensiones de empleo.
- Proveedores de servicios de criptoactivos (con la entrada en vigor de MiCA).
- Infraestructuras de mercado: cámaras de compensación, depositarios centrales, plataformas de negociación.
- Proveedores externos críticos de TIC que presten servicios a las entidades anteriores.
Este último punto es el que más sorprende a las empresas tecnológicas. Un proveedor de software, cloud o ciberseguridad que tenga como clientes a entidades financieras puede verse designado como proveedor TIC crítico por las autoridades europeas de supervisión (EBA, ESMA, EIOPA), lo que activa obligaciones directas sobre él, no solo sobre su cliente financiero.
Qué exige DORA: los cinco pilares
El reglamento estructura sus obligaciones en cinco áreas que las entidades deben tener operativas:
- Gestión del riesgo TIC: marco documentado con identificación, protección, detección, respuesta y recuperación. No basta con tenerlo escrito, tiene que ser revisable y estar bajo supervisión del órgano de dirección, que asume responsabilidad personal.
- Notificación de incidentes en tres fases: inicial en 4 horas para incidentes graves, intermedia en 72 horas e informe final en un mes. La autoridad competente en España es el Banco de España, la CNMV o la DGSFP según el tipo de entidad.
- Pruebas de resiliencia operativa digital: test básicos anuales para todas las entidades y pruebas avanzadas de penetración basadas en inteligencia de amenazas (TLPT) cada tres años para las entidades significativas.
- Gestión del riesgo de terceros TIC: inventario de proveedores, clasificación por criticidad, cláusulas contractuales obligatorias del artículo 30, estrategia de salida documentada y supervisión continua. Es, en la práctica, la parte más costosa de implementar.
- Intercambio de información sobre amenazas: participación voluntaria en acuerdos de inteligencia sobre ciberamenazas entre entidades del sector.
DORA vs NIS2: la regla de la lex specialis
La relación entre DORA y NIS2 está resuelta en el propio texto de la Directiva NIS2 (considerando 14 y artículo 4): cuando una entidad del sector financiero ya está sujeta a DORA, los requisitos de DORA prevalecen sobre los equivalentes de NIS2 para esa entidad. DORA es lex specialis.
Esto no significa que NIS2 desaparezca completamente del mapa para el sector financiero. Hay obligaciones de NIS2, como la notificación a autoridades de ciberseguridad nacionales (INCIBE-CERT, CCN-CERT), que no tienen equivalente exacto en DORA y que pueden seguir aplicando en paralelo. El árbol de decisión correcto no es “DORA o NIS2” sino “DORA primero, NIS2 para lo que DORA no cubre”.
Para los proveedores TIC que sirven al sector financiero pero no son entidades financieras ellas mismas, la situación es distinta: pueden caer bajo NIS2 (si son proveedores de servicios digitales o infraestructuras críticas) y además quedar sujetos a las obligaciones contractuales que DORA impone a sus clientes financieros. La doble exposición es real.
Las cláusulas contractuales del artículo 30: el punto de fricción
El artículo 30 de DORA establece el contenido mínimo que deben incluir los contratos entre entidades financieras y sus proveedores TIC. La lista es detallada: descripción completa de los servicios, indicadores de calidad y rendimiento, ubicación de los datos y sus posibles ubicaciones alternativas, condiciones de disponibilidad, autenticidad e integridad, derechos de acceso y auditoría, procedimientos de resolución de incidentes, requisitos de continuidad del servicio y estrategia de salida.
Muchos contratos existentes con proveedores cloud o SaaS no cumplen este estándar. La revisión y renegociación contractual es uno de los principales cuellos de botella en los programas de adaptación a DORA que se están ejecutando ahora mismo.
La intersección con el RGPD
DORA no es una norma de protección de datos, pero toca inevitablemente el RGPD en varios puntos. Los sistemas TIC que gestionan datos de clientes de entidades financieras son también tratamientos de datos personales. Un incidente de seguridad que active la notificación DORA puede simultáneamente activar la notificación de brecha de datos a la AEPD en 72 horas. Los contratos con proveedores TIC que traten datos personales necesitan tanto las cláusulas del artículo 30 de DORA como el contrato de encargo del artículo 28 del RGPD.
Gestionar esas dos capas con documentación separada para cada reglamento es lo que acaba generando incoherencias en las auditorías. Lo más eficiente es un único marco contractual que satisfaga los requisitos de ambos.
Para una visión completa del panorama regulatorio europeo que afecta a tu empresa, consulta nuestra guía sobre cumplimiento del AI Act en España, donde explicamos cómo se integra DORA con el resto del marco normativo digital.
Fuentes: Reglamento (UE) 2022/2554 (DORA), artículos 2, 17, 19, 24, 26 y 30; Directiva (UE) 2022/2555 (NIS2), artículo 4 y considerando 14; Reglamento (UE) 2016/679 (RGPD), artículo 28.
