En una frase. El Capítulo V de DORA obliga a las entidades financieras a gestionar el riesgo de sus proveedores TIC mediante contratos con cláusulas mínimas obligatorias (art. 30), estrategias de salida, vigilancia de la concentración de proveedores cloud y sujeción de los proveedores críticos a la supervisión directa de las Autoridades Europeas de Supervisión.
La gestión del riesgo de DORA proveedores TIC es, en la práctica, el corazón del reglamento. El sector financiero ha externalizado su columna vertebral tecnológica a un puñado de hiperescalares y proveedores de software bancario, y DORA responde imponiendo control contractual, planes de salida y, por primera vez, supervisión pública directa sobre esos terceros. Esta guía explica qué exige el Capítulo V, cómo redactar contratos conformes y por qué afecta también a los proveedores que venden a la banca.
Puntos clave
- El Capítulo V de DORA regula la gestión del riesgo de terceros TIC (arts. 28 a 44).
- El art. 30 fija las cláusulas contractuales mínimas obligatorias, reforzadas para funciones esenciales o importantes.
- Toda función crítica externalizada exige una estrategia de salida documentada y verosímil.
- La concentración en pocos proveedores cloud es un riesgo sistémico que DORA obliga a evaluar.
- Los proveedores críticos (CTPP) quedan bajo supervisión directa de un Supervisor Principal de las ESA.
1. El marco: por qué DORA regula a los terceros
El Reglamento (UE) 2022/2554 parte de que la resiliencia de una entidad financiera es tan fuerte como su eslabón tecnológico más débil, y ese eslabón suele estar fuera de sus muros. El Capítulo V establece principios (art. 28), evaluación previa a la contratación, contenido contractual (art. 30) y un régimen de vigilancia de los proveedores críticos.
La entidad sigue siendo plenamente responsable del cumplimiento aunque externalice: DORA prohíbe expresamente la transferencia de responsabilidad al proveedor. Esta lógica es la misma que impone el art. 28 del RGPD al responsable frente a sus encargados.
2. Las cláusulas contractuales del art. 30
El art. 30 distingue un núcleo aplicable a todo contrato TIC y un conjunto reforzado para los que sostienen funciones esenciales o importantes. Entre las cláusulas exigibles:
| Materia | Contenido mínimo |
|---|---|
| Descripción del servicio | Funciones, niveles de servicio (SLA), ubicaciones de tratamiento |
| Acceso y auditoría | Derechos de acceso, inspección y auditoría de la entidad y del supervisor |
| Seguridad | Medidas, disponibilidad, integridad, confidencialidad de los datos |
| Subcontratación | Condiciones para subcontratar funciones críticas |
| Asistencia ante incidentes | Cooperación del proveedor sin coste adicional |
| Terminación | Derechos de rescisión y estrategia de salida |
| Formación y ejercicios | Participación en programas de concienciación y pruebas |
En la práctica, redactar estas cláusulas se parece a construir un buen contrato de encargado del tratamiento: identificar al tercero, delimitar la función, garantizar auditoría y controlar la cadena.
3. Estrategias de salida y concentración
DORA no se conforma con un buen contrato de entrada: exige una estrategia de salida realista para las funciones esenciales, de modo que la entidad pueda migrar a otro proveedor o internalizar el servicio sin colapsar. Un plan de salida que sea papel mojado —porque migrar de un hiperescalar es inviable en semanas— no cumple el estándar.
El segundo foco es la concentración. Cuando media docena de bancos dependen del mismo proveedor cloud para funciones críticas, el fallo de ese proveedor es un riesgo sistémico. La entidad debe evaluar su exposición a la concentración, incluida la geográfica, algo que conecta con las transferencias internacionales de datos cuando el proveedor trata datos fuera de la UE.
4. Supervisión directa de proveedores críticos (CTPP)
La gran novedad: las ESA pueden designar a determinados proveedores como terceros TIC críticos (CTPP) y someterlos a la vigilancia de un Supervisor Principal (Lead Overseer). Este puede formular recomendaciones, exigir información e incluso sancionar al proveedor con multas coercitivas. Es la primera vez que un supervisor financiero europeo puede dirigirse directamente a un proveedor tecnológico que no es una entidad financiera.
La designación de CTPP se basa en criterios de impacto sistémico, sustituibilidad y número de entidades financieras que dependen del proveedor. La Autoridad Bancaria Europea (EBA) coordina con ESMA y EIOPA la elaboración de la lista de proveedores críticos. Para las entidades, esto tiene una consecuencia práctica: parte del control de su proveedor crítico lo ejerce ya el supervisor, pero la entidad no queda liberada de su propia diligencia contractual.
5. Qué implica para los SaaS que venden a la banca
Aquí está el efecto colateral relevante para el ecosistema español: un SaaS que presta servicios a entidades financieras se convierte en objeto del escrutinio DORA de sus clientes. Deberá aceptar cláusulas del art. 30, someterse a auditorías y figurar en el registro de información DORA de cada cliente. Si además cae dentro del ámbito de NIS2, acumulará dos regímenes de ciberseguridad. Elegir o construir un software de cumplimiento DORA que gestione contratos, subcontratistas y evidencias reduce esa fricción comercial.
En la práctica, los proveedores tecnológicos que quieran seguir vendiendo a la banca han tenido que preparar un “paquete DORA” para sus clientes: adenda contractual con las cláusulas del art. 30, política de subcontratación transparente, plan de continuidad y salida, y evidencias de auditoría reutilizables. Anticiparse a esa exigencia se ha convertido en un argumento comercial: el proveedor que llega con la documentación resuelta acorta el ciclo de venta frente al que obliga a su cliente financiero a negociar cada garantía desde cero.
6. Errores frecuentes en la gestión del riesgo de terceros
Tres fallos se repiten en las revisiones supervisoras. El primero es confundir criticidad del proveedor con tamaño del contrato: un servicio barato puede sostener una función esencial, y su clasificación depende de la función, no del importe. El segundo es la estrategia de salida ficticia: planes que asumen una migración en semanas cuando la dependencia técnica real haría inviable el cambio en menos de un año. El tercero es la ceguera ante la cuarta parte: la entidad controla a su proveedor directo, pero ignora a quién subcontrata este, de modo que el riesgo real queda fuera del radar. Corregir estos tres puntos concentra buena parte del valor del Capítulo V.
Véase también: pruebas de resiliencia DORA (TLPT).
FAQ
¿DORA obliga a renegociar todos los contratos con proveedores TIC?
En la práctica, sí para las funciones esenciales o importantes: los contratos vigentes deben adaptarse a las cláusulas mínimas del art. 30. Las entidades han tenido que revisar sus acuerdos cloud y de software crítico para incorporar derechos de auditoría, cooperación ante incidentes y estrategias de salida.
¿Qué es un proveedor TIC crítico (CTPP) y quién lo designa?
Es un proveedor cuya caída tendría impacto sistémico en el sector financiero. Lo designan las ESA (EBA, ESMA y EIOPA) mediante criterios de criticidad y concentración, y queda sujeto a la supervisión directa de un Supervisor Principal, con potestad para exigir medidas y aplicar multas coercitivas.
¿Un proveedor cloud fuera de la UE puede prestar servicios críticos bajo DORA?
Puede, pero con condiciones. Los proveedores críticos que operen en la UE deben, en su caso, establecer una filial en la Unión, y la entidad financiera debe evaluar el riesgo derivado de la ubicación del tratamiento, incluidas las implicaciones de transferencia internacional de datos del RGPD.
¿La responsabilidad se traslada al proveedor si el contrato lo prevé?
No. DORA mantiene a la entidad financiera plenamente responsable del cumplimiento de sus obligaciones regulatorias con independencia de la externalización. El contrato reparte tareas, no exime de responsabilidad frente al supervisor.