Estrategia de salida DORA: Del contrato al plan probado
Por Arturo Navarro · 27 de octubre de 2026
La mayoría de las entidades tiene un contrato con cláusula de terminación y un documento titulado "plan de salida". Pocas pueden responder a la pregunta que importa: si el proveedor TIC que soporta una función crítica desaparece mañana, ¿en cuánto tiempo, con qué datos y hacia dónde se migra? El artículo 28(8) de DORA no pide el documento: pide la capacidad.
Qué exige el artículo 28(8)
DORA (Digital Operational Resilience Act) es el Reglamento (UE) 2022/2554 sobre la resiliencia operativa digital del sector financiero. Obliga a bancos, aseguradoras y empresas de inversión de la UE a resistir las perturbaciones y amenazas TIC, responder a ellas y recuperarse. Se aplica desde el 17 de enero de 2025.Leer más → DORA (Reglamento (UE) 2022/2554) obliga en el artículo 28(8) a establecer estrategias de salida para los servicios TIC que soportan funciones críticas o importantes. Tres rasgos del texto marcan el listón:- Escenarios, no solo terminación. La estrategia debe contemplar el fallo del proveedor, el deterioro de la calidad del servicio, las interrupciones de negocio por una prestación inadecuada o fallida y la terminación del contrato en los supuestos del artículo 28(7).
- Salir sin romper nada. La entidad debe poder abandonar el acuerdo sin interrumpir su actividad, sin incumplir sus obligaciones regulatorias y sin perjuicio para la continuidad y calidad del servicio a sus clientes.
- Planes completos, documentados, probados y revisados. El texto exige identificar soluciones alternativas, preparar planes de transición que permitan retirar las funciones y los datos contratados y transferirlos de forma segura e íntegra a otro proveedor o reintegrarlos, y disponer de medidas de contingencia.
El alcance es deliberado: aplica a funciones críticas o importantes. Para el resto de proveedores, la proporcionalidad decide cuánto esfuerzo merece.
El contrato es la mitad de la salida
Una estrategia de salida sin palanca contractual es una intención. El artículo 30 fija las cláusulas que la sostienen, y tres importan especialmente aquí:
| Cláusula | Qué asegura |
|---|---|
| Art. 30(2)(d) | Acceso, recuperación y devolución de los datos personales y no personales en un formato fácilmente accesible, si el proveedor quiebra, cesa su actividad o termina el contrato. |
| Art. 30(2)(h) | Derechos de terminación y plazos mínimos de preaviso. |
| Art. 30(3)(f) | Para funciones críticas o importantes, estrategias de salida y un periodo transitorio adecuado y obligatorio, durante el cual el proveedor sigue prestando el servicio y la entidad migra a otro proveedor o a una solución interna. |
Los supuestos de terminación del artículo 28(7) completan el cuadro: incumplimiento grave del proveedor, circunstancias detectadas en la supervisión del riesgo que puedan alterar la prestación, debilidades acreditadas en su gestión del riesgo TIC y la imposibilidad de que la autoridad competente supervise de forma efectiva a la entidad. La salida no es solo la vía de escape ante un fallo: es el derecho que la supervisión espera que exista.
La política contractual baja el requisito a cada acuerdo
Las normas de desarrollo del artículo 28(10) están en el Reglamento Delegado (UE) 2024/1773, sobre el contenido de la política relativa a los acuerdos contractuales para servicios TIC que soportan funciones críticas o importantes. Su artículo 10 exige que la política prevea un plan de salida documentado por cada acuerdo contractual, con revisión y pruebas periódicas, que cubra interrupciones persistentes, prestación deficiente del servicio y terminación inesperada, y que sea realista y viable, con un calendario compatible con los términos de salida y terminación del contrato.
Dos consecuencias prácticas. Primera: el plan es por acuerdo, no un documento genérico de la entidad. Segunda: el calendario del plan y el preaviso contractual deben cuadrar; un plan que necesita doce meses frente a un contrato con tres de preaviso falla sobre el papel antes de fallar en la práctica.
Por qué la mayoría de los planes no sobrevive a una prueba
Un plan de salida suele fallar en el mismo sitio: asume que lo difícil es la decisión, y lo difícil es la ejecución.
- Datos sin portabilidad. El contrato promete la devolución, pero nadie ha extraído un volcado completo en el formato pactado ni lo ha cargado en otro sistema.
- Dependencias invisibles. El proveedor está integrado en identidad, redes, monitorización y flujos de datos que el plan no inventaría. El registro de información es el punto de partida: lo que no está mapeado ahí no entrará en el plan.
- Alternativa nominal. El plan cita un segundo proveedor que nunca se ha evaluado ni dimensionado, o una reintegración interna sin capacidad ni plantilla.
- Plan sin prueba. El artículo 28(8) exige planes suficientemente probados. Una lectura conjunta del plan por TI, compliance y negocio no es una prueba.
Cómo se construye un plan que se puede ejecutar
Un plan útil se parece más a un runbook que a una política:
- Un plan por función crítica y proveedor, derivado del registro, con el servicio, los datos y las interdependencias identificados.
- Alternativa evaluada: segundo proveedor, cambio de modalidad o reintegración, con su coste, plazo y requisitos regulatorios, y una decisión explícita sobre cuál es la primera opción.
- Datos portables por diseño: formatos abiertos, exportación probada y claves o secretos bajo control de la entidad, no del proveedor.
- Periodo transitorio dimensionado con el contrato, y un calendario de migración con hitos y responsables.
- Prueba periódica: del ejercicio de mesa a la extracción real de datos y la restauración en el destino. Lo que no se ha ejercitado es una hipótesis.
- Revisión por disparador: cambio de proveedor, de subcontratistas o de la criticidad de la función reabre el plan, no solo el calendario anual.
La portabilidad se decide en el diseño, no en la salida
Las entidades que salen bien de un proveedor son las que desacoplaron identidad, acceso y datos desde el principio. Un servicio cuyo acceso se gobierna por identidad y política propias, y no por la red del proveedor, cambia de alojamiento sin rehacer la seguridad. Es la lógica de los servicios sin puertos expuestos.
Conclusión: La salida se demuestra, no se declara
La estrategia de salida es la parte del marco de terceros que cuesta más porque obliga a admitir una dependencia y a ensayar su fin. El artículo 28(8) y el artículo 10 del Reglamento Delegado 2024/1773 convergen en lo mismo: un plan por acuerdo, realista, con calendario compatible con el contrato y probado. La entidad que lo trata como un runbook ejecutable convierte el riesgo de concentración en una decisión; la que lo trata como un documento descubre su plan de salida el día que lo necesita.
Si necesitas saber en qué punto está tu marco de terceros TIC, BlueUP trabaja la resiliencia operativa DORA como arquitectura, no como papeleo. Empieza por medir tu madurez con la Calculadora DORA, repasa el marco en la guía práctica de DORA o plantea tu caso.
¿Qué proveedor TIC no podrías sustituir hoy?
Revisamos contigo un proveedor de una función crítica: qué datos y dependencias lo atan, qué dice el contrato sobre la salida y qué faltaría para ejecutar el plan.
Lecturas relacionadas
- Registro de información DORA: Pocos pasan a la primera — El inventario de terceros del que parte cada plan de salida.
- DORA 2026: Guía práctica para entidades financieras — El marco completo de gestión del riesgo de terceros.
- DORA para fintech e insurtech: Checklist de 90 días — Dónde encaja la salida en un plan de 90 días.
- TLPT bajo DORA: Qué exige el primer ciclo en España — Otra prueba que se ejecuta, no se documenta.