Resiliencia Operativa, Dependencia de Terceros y Desvinculación Controlada
Introducción
El Artículo 28 de DORA exige a las entidades financieras que gestionen los riesgos derivados de los proveedores de servicios ICT terceros, incluidas las plataformas en la nube, los proveedores SaaS de CI/CD, los registros de artefactos y otros servicios digitales críticos.
Un requisito central, y a menudo subestimado, es la capacidad de salir de un acuerdo con un tercero sin interrumpir las operaciones críticas.
La estrategia de salida no es solo una cláusula contractual.
Es una capacidad operativa probada integrada en la arquitectura, la gobernanza y la planificación de la recuperación ante desastres.
Este artículo explica:
- Qué espera el Artículo 28 de DORA respecto a las estrategias de salida
- Cómo la capacidad de salida se conecta con DR (Disaster Recovery) y BCP (Business Continuity Planning)
- Cómo probar la preparación para la salida en entornos CI/CD y dependientes de la nube
- Qué evaluarán los auditores y reguladores
1. Por qué la estrategia de salida es un requisito central de DORA
Bajo DORA, las entidades financieras deben:
- Evitar el riesgo de concentración excesiva
- Garantizar la continuidad de las funciones críticas
- Mantener la capacidad de rescindir contratos ICT de forma segura
- Evitar que la dependencia del proveedor comprometa la resiliencia
Una estrategia de salida garantiza que:
- Un fallo del proveedor no paralice la entrega
- La rescisión de un contrato no interrumpa las operaciones
- Un incidente cibernético en un proveedor no se propague como una disrupción sistémica
La preparación para la salida es por tanto un control de resiliencia, no solo una cláusula de adquisición.
2. Estrategia de salida vs Disaster Recovery vs Business Continuity
Estos conceptos están relacionados pero son distintos:
Estrategia de salida
Desvinculación controlada de un proveedor tercero y transición a una solución alternativa.
Disaster Recovery (DR)
Restauración de sistemas y servicios tras una interrupción.
Business Continuity Planning (BCP)
Mantenimiento de las funciones empresariales críticas durante y después de las interrupciones.
Bajo el Artículo 28 de DORA, la estrategia de salida se intersecta con DR y BCP cuando:
- Un proveedor de nube deja de estar disponible
- Una plataforma CI/CD SaaS está comprometida
- Un proveedor ICT crítico falla o es sancionado
- Una rescisión de contrato requiere migración
La capacidad de salida debe por tanto estar técnicamente alineada con los mecanismos de DR y BCP.
3. Riesgo de salida en arquitecturas CI/CD y de nube
Las instituciones financieras modernas dependen de:
- SaaS de alojamiento Git (GitHub, GitLab, Bitbucket)
- Plataformas CI/CD
- Registros de artefactos
- IaaS/PaaS en la nube
- Herramientas de seguridad basadas en SaaS
- Proxies de dependencias
Cada uno representa un posible punto único de fallo.
Los escenarios de riesgo de salida incluyen:
- Pérdida de acceso al plano de control CI/CD
- Incapacidad para recuperar las configuraciones del pipeline
- Dependencia de formatos de artefactos propietarios
- Automatización de infraestructura con dependencias de proveedor
- Pérdida de registros de auditoría alojados por el proveedor
La estrategia de salida debe por tanto integrarse en:
- Diseño de arquitectura
- Portabilidad de datos
- Exportación de configuración
- Mecanismos de copia de seguridad
4. Componentes principales de una estrategia de salida conforme con DORA
Una estrategia de salida robusta incluye:
4.1 Mapeo de activos y dependencias
Las organizaciones deben identificar:
- Qué funciones críticas dependen de qué proveedores ICT
- Datos alojados externamente
- Titularidad de la configuración
- Puntos de integración
Sin este mapeo, las pruebas de salida son imposibles.
4.2 Portabilidad y exportación de datos
Las preguntas críticas incluyen:
- ¿Pueden exportarse los repositorios en formatos estándar?
- ¿Pueden recuperarse las configuraciones de CI/CD?
- ¿Son portables los historiales de artefactos?
- ¿Pueden exportarse los registros para la retención de cumplimiento?
Si los registros y el historial del pipeline no pueden exportarse, la evidencia regulatoria puede perderse durante la salida.
4.3 Preparación de la solución alternativa
La salida requiere más que la cancelación.
Las organizaciones deben evaluar:
- ¿Está pre-evaluado un proveedor alternativo?
- ¿Pueden redistribuirse los pipelines en otro lugar?
- ¿Las plantillas de Infraestructura como Código son independientes de la nube?
- ¿Las dependencias están en contenedores o son portables?
La dependencia del proveedor es un riesgo de resiliencia bajo DORA.
4.4 Cláusulas contractuales
Los contratos deben incluir:
- Cláusulas de asistencia para la salida
- Plazos de soporte a la transición
- Requisitos de entrega de datos
- Garantías de retención
- Transparencia de los subprocesadores
Los auditores revisarán si estas cláusulas son ejecutables y están alineadas con los planes operativos.
5. Pruebas de estrategia de salida en la práctica
DORA espera que las estrategias de salida sean probadas, no asumidas.
Los enfoques de prueba pueden incluir:
5.1 Ejercicios de mesa
Talleres basados en escenarios que prueban:
- Interrupción del proveedor de nube
- Compromiso del CI/CD SaaS
- Insolvencia del proveedor
- Sanciones que afectan al proveedor
El objetivo es validar los procesos de decisión y los plazos.
5.2 Simulación de migración técnica
Pruebas controladas como:
- Exportar repositorios y volver a alojarlos
- Reconstruir pipelines en un entorno secundario
- Restaurar artefactos desde copias de seguridad independientes
- Desplegar aplicaciones desde un registro alternativo
Estas pruebas revelan dependencias ocultas.
5.3 Pruebas combinadas de DR + Salida
Un enfoque maduro integra la estrategia de salida en las pruebas de DR:
Escenario de ejemplo:
«El CI/CD SaaS principal no está disponible durante 72 horas.»
Elementos de la prueba:
- ¿Pueden continuar los despliegues?
- ¿Pueden publicarse correcciones de emergencia?
- ¿Son portables las plantillas del pipeline?
- ¿Se preserva la evidencia de auditoría?
Esto transforma la estrategia de salida de teórica a operativa.
6. Evidencia de las pruebas de estrategia de salida
Desde una perspectiva de auditoría, las organizaciones deben producir:
- Documentación de la estrategia de salida
- Clasificación de riesgos del proveedor
- Registros de mapeo de dependencias
- Informes de prueba (de mesa y técnicos)
- Brechas identificadas y planes de remediación
- Aprobación de la dirección sobre la preparación para la salida
La evidencia debe mostrar:
- Las pruebas se realizaron
- Se identificaron debilidades
- Se implementaron mejoras
Las pruebas sin resultados documentados no se consideran suficientes.
7. Qué evaluarán los auditores
Los auditores verifican típicamente:
- Si los proveedores ICT críticos están identificados
- Si las estrategias de salida están definidas por proveedor crítico
- Si los planes de salida son realistas y técnicamente factibles
- Si las pruebas son periódicas y están documentadas
- Si la portabilidad de datos está validada
- Si el BCP integra escenarios de fallo de terceros
Los hallazgos de auditoría comunes incluyen:
- Planes de salida limitados a cláusulas contractuales
- Sin validación técnica
- Ningún proveedor alternativo identificado
- Falta de capacidad de exportación de CI/CD
- Ausencia de retención de registros durante la transición del proveedor
8. Patrones de fallo comunes
Las organizaciones suelen fallar porque:
- Los pipelines CI/CD son completamente gestionados por el proveedor sin proceso de exportación
- Los registros de artefactos son propietarios sin copia de seguridad
- La automatización de infraestructura depende de APIs específicas del proveedor
- Los escenarios de salida nunca se ensayan
- Las responsabilidades durante la salida no están claras
La estrategia de salida falla cuando la arquitectura no fue diseñada con la portabilidad en mente.
9. Diseño de CI/CD para la preparación de salida
Para alinearse con el Artículo 28 de DORA, las arquitecturas CI/CD deberían:
- Usar Infraestructura como Código
- Almacenar las configuraciones del pipeline en control de versiones
- Mantener copias de seguridad independientes
- Evitar dependencias de proveedor codificadas de forma rígida
- Soportar compilaciones reproducibles
- Preservar la evidencia de cumplimiento fuera de los sistemas controlados por el proveedor
La preparación para la salida debe ser un principio arquitectónico, no un ejercicio de recuperación de última hora.
Conclusión
Bajo el Artículo 28 de DORA, la estrategia de salida es un control de resiliencia vinculado a:
- Gestión de riesgos de terceros
- Continuidad operativa
- Responsabilidad regulatoria
No es suficiente afirmar que la salida es posible.
Las organizaciones deben demostrar que:
- La salida es técnicamente factible
- Las dependencias son conocidas
- Existen rutas alternativas
- Se han realizado pruebas
- La evidencia se conserva
En entornos regulados, la resiliencia incluye la capacidad de salir.
Artículos relacionados
- DORA Article 28 — Architecture
- DORA Article 28 — Auditor Checklist
- DORA Article 28 — Evidence Pack
- DORA Article 28 — CI/CD Controls Mapping
