DORA:

qué exige el reglamento de resiliencia digital a la banca y la fintech de la UE

Gobernanza y normativa  |  unfantasmaenelsistema.com

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 es una directiva que cada país traspone a su manera: es un reglamento único, con el mismo texto y las mismas obligaciones para un banco en Fráncfort, una aseguradora en Madrid o una fintech en Ámsterdam. Y su ambición va más allá del sector financiero clásico: DORA también alcanza, de forma directa o indirecta, a los proveedores tecnológicos que dan servicio a ese sector.

Este artículo explica qué pide DORA en términos prácticos: a quién obliga, sus cinco pilares, qué es el registro de información de proveedores y las pruebas de penetración dirigidas por amenazas (TLPT), cómo se solapa con NIS2, y qué debería preparar un proveedor TIC que quiere seguir vendiendo a la banca. No sustituye al asesoramiento legal ni al criterio del área de cumplimiento normativo de cada entidad: el objetivo es que un equipo técnico entienda de qué está hablando su departamento legal cuando menciona DORA.

1. Por qué existe DORA

Antes de DORA, la resiliencia operativa digital del sector financiero europeo se regulaba de forma fragmentada: cada Estado miembro y cada regulador sectorial (bancario, de seguros, de mercados de valores) tenía sus propias guías sobre gestión del riesgo TIC, notificación de incidentes y externalización. Una entidad que operaba en varios países se enfrentaba a requisitos distintos para el mismo problema. DORA unifica ese marco en un único reglamento, directamente aplicable, que además reconoce algo que la regulación anterior apenas tocaba: el riesgo TIC ya no es solo el riesgo propio de la entidad, es el riesgo de toda su cadena de proveedores tecnológicos.

El detonante regulatorio es sencillo de entender: un banco puede tener una gestión del riesgo impecable y aun así caer si el proveedor cloud que aloja su core bancario, o el proveedor SaaS que procesa sus pagos, sufre una interrupción o un incidente de seguridad grave. DORA responde extendiendo la supervisión, de forma proporcionada, a esa cadena.

2. A quién obliga

El ámbito subjetivo de DORA es amplio dentro del sector financiero: entidades de crédito, entidades de pago y de dinero electrónico, empresas de servicios de inversión, proveedores de servicios de criptoactivos, centrales de valores, entidades de contrapartida central, gestoras de fondos, aseguradoras y reaseguradoras, intermediarios de seguros, agencias de calificación crediticia, proveedores de servicios de financiación participativa y varios más — con exenciones y régimen simplificado para las entidades más pequeñas.

La pieza que sorprende a quien viene del mundo TIC es la segunda categoría: los proveedores terceros de servicios TIC. DORA no regula a todo proveedor tecnológico que trabaje con un banco, pero sí impone a las entidades financieras la obligación de gestionar ese riesgo contractualmente, y crea una figura nueva, el proveedor crítico de TIC, sobre la que las autoridades europeas de supervisión (EBA, ESMA, EIOPA) pueden ejercer supervisión directa cuando su papel es sistémico para el sector — pensado inicialmente para grandes proveedores de infraestructura cloud y de datos.

3. Los cinco pilares de DORA

El reglamento se organiza en cinco bloques temáticos. No son capítulos independientes: se apoyan unos en otros y comparten la misma idea de fondo — tratar la tecnología como una función crítica del negocio, no como un centro de coste aparte.

3.1 Gestión y notificación de incidentes: los plazos

DORA armoniza algo que antes variaba por país y por regulador sectorial: la definición de incidente «grave» (major incident) y el reloj de notificación. En líneas generales, ante un incidente clasificado como grave la entidad debe enviar una notificación inicial en un plazo breve tras la clasificación, un informe intermedio con la evolución y las medidas adoptadas, y un informe final con el análisis de causa raíz una vez resuelto. Los criterios de clasificación —clientes afectados, duración, pérdida de datos, propagación geográfica, impacto reputacional, criticidad del servicio— están desarrollados en normas técnicas de regulación (RTS) que concretan el reglamento.

4. Pruebas de resiliencia: de lo básico al TLPT

El pilar de pruebas sigue un principio de proporcionalidad explícito. La mayoría de las entidades deben ejecutar anualmente un programa que incluye análisis de vulnerabilidades, evaluaciones de seguridad de red, revisiones de código fuente cuando aplique, pruebas basadas en escenario y ejercicios de continuidad. Solo las entidades que las autoridades identifiquen como significativas —por tamaño, perfil de riesgo o relevancia sistémica— quedan sujetas además a pruebas de penetración dirigidas por amenazas (TLPT, Threat-Led Penetration Testing) cada tres años.

El marco TLPT europeo se apoya en el marco TIBER-EU del BCE, que ya venían aplicando algunos bancos centrales antes de DORA. Es un ejercicio de red team completo, contra sistemas de producción, con un proveedor de threat intelligence que construye escenarios realistas y un equipo de red team acreditado que los ejecuta, todo bajo la coordinación de un gestor de pruebas (test manager) y con el conocimiento y autorización expresa de la autoridad competente. No es una auditoría de caja blanca ni un escaneo automatizado: es el ejercicio de simulación de ataque más exigente que contempla la regulación financiera europea, y por diseño incluye a los proveedores TIC críticos que sostienen las funciones críticas probadas.

5. Riesgo de terceros: el registro de información

Este es, en la práctica diaria, el pilar que más trabajo genera para los equipos de cumplimiento y de compras de TI. Cada entidad financiera debe mantener un registro de información (Register of Information) con todos sus contratos de servicios TIC — no solo los relevantes: todos — y reportarlo periódicamente al supervisor. El registro recoge, entre otros campos, la identidad del proveedor y su cadena de subcontratación, el tipo de servicio prestado, si soporta una función crítica o importante, el país donde se presta y donde se almacenan los datos, y la fecha de inicio y fin del contrato.

El análisis de riesgo de concentración es otra pieza que sorprende a quien no viene del sector financiero: un supervisor puede señalar como problema, en sí mismo, que un porcentaje demasiado alto de las entidades supervisadas dependa del mismo proveedor cloud o del mismo proveedor de un servicio crítico muy específico, aunque cada contrato individual esté bien gestionado. Es una lectura sistémica del riesgo, no solo entidad por entidad.

6. Solapamiento con NIS2

DORA y NIS2 comparten espíritu —resiliencia digital, gestión de incidentes, riesgo de cadena de suministro— pero el legislador europeo resolvió expresamente el solapamiento: allí donde DORA aplica, DORA prevalece como lex specialis sobre NIS2 para las entidades financieras, precisamente para evitar que un banco tenga que cumplir dos regímenes de notificación de incidentes distintos para el mismo hecho. Un proveedor TIC que dé servicio tanto a entidades financieras como a otros sectores esenciales puede, sin embargo, quedar sujeto a ambos marcos a la vez: a DORA por la vía contractual con sus clientes financieros, y a NIS2 de forma directa si él mismo encaja en alguna de las categorías de entidad esencial o importante del reglamento.

7. Qué prepara un proveedor TIC que quiere seguir vendiendo a la banca

Un proveedor tecnológico —desarrollo a medida, SaaS, infraestructura cloud, ciberseguridad gestionada— no firma DORA, pero cada vez más contratos con clientes del sector financiero incorporan sus cláusulas por defecto. Llegar preparado ahorra meses de negociación contractual y evita perder oportunidades frente a competidores que ya lo tienen resuelto.

• Certificaciones y evidencias reutilizables: ISO 27001 con alcance real sobre el servicio prestado, informe SOC 2 tipo II, o el Esquema Nacional de Seguridad si hay componente de sector público — reducen drásticamente el número de preguntas del cuestionario de due diligence
• Capacidad de notificación de incidentes con plazos definidos: un proceso interno documentado que permita avisar al cliente financiero dentro de la ventana que su propio contrato exige, no cuando el proveedor lo detecte por casualidad
• Transparencia sobre subcontratación: mantener actualizada y accesible la lista de subproveedores que participan en la prestación del servicio, especialmente si cambian con frecuencia
• Localización de datos clara y estable: poder indicar con precisión en qué país y en qué proveedor de infraestructura se almacenan y procesan los datos del cliente
• Colaboración en auditorías y en TLPT: aceptar contractualmente el derecho de auditoría de la entidad financiera y, si el servicio soporta una función crítica, la posibilidad de participar en un ejercicio de pruebas de penetración dirigidas por amenazas
• Plan de continuidad y de salida propio: demostrar que el proveedor también tiene forma de recuperarse de un incidente grave, y que facilita —no dificulta— que el cliente migre si algún día lo necesita

Conclusión

DORA formaliza algo que la práctica ya intuía: la resiliencia de una entidad financiera depende tanto de sus propios controles como de la solidez de cada proveedor tecnológico en su cadena. Los cinco pilares —gestión del riesgo TIC, incidentes, pruebas, terceros e intercambio de información— convierten esa intuición en obligaciones concretas, con plazos, registros y, para las entidades más relevantes, ejercicios de simulación de ataque tan exigentes como un TLPT.

Para un proveedor TIC, la lectura práctica es sencilla: cuanta más evidencia reutilizable —certificación con alcance real, proceso de notificación de incidentes con plazos, trazabilidad de subcontratación, claridad sobre dónde viven los datos— tenga preparada de antemano, menos fricción encontrará cada vez que un cliente financiero abra su cuestionario de riesgo de terceros.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)