Si su proveedor ICT crítico falla mañana: ¿qué se detiene — y durante cuánto tiempo?
De un vistazo
La cuestión ya no es solo el proveedor.
La cuestión es si la institución puede demostrar continuidad.
Board AskConfirmar si la institución puede demostrar continuidad y capacidad de exit para servicios ICT que soportan funciones críticas o importantes.
Situation
Supongamos la siguiente situación.
Un proveedor tercero ICT crítico deja de estar disponible. Soporta una plataforma, un servicio de datos, un entorno cloud, un workflow engine, una capa de reporting o un proceso AI-enabled utilizado por la institución. En cuestión de horas, la pregunta ya no es si el proveedor tiene una obligación contractual de restaurar el servicio.
La pregunta es qué se detiene dentro del banco.
¿Qué funciones críticas o importantes se ven afectadas? ¿Qué cadenas de clientes, riesgo, operativas o decisionales dependen del proveedor? ¿Cuál es el tiempo de recovery probado? ¿Puede el servicio ser sustituido, abandonado o restaurado dentro de la tolerancia de la institución?
La cuestión ya no es solo el proveedor.
La cuestión es si la institución puede demostrar continuidad.
Management Summary
DORA convierte el riesgo de terceros ICT en una disciplina board-level y basada en evidencia. Las entidades financieras siguen siendo responsables de la compliance incluso cuando los servicios ICT son prestados por terceros; DORA también exige gestión del riesgo de terceros ICT, un Register of Information y estrategias de exit para servicios ICT que soportan funciones críticas o importantes.
Las Autoridades Europeas de Supervisión publicaron el 18 de noviembre de 2025 la primera lista de 19 proveedores terceros ICT críticos designados bajo DORA. El proceso de designación utilizó datos de los Registers of Information y una evaluación de criticidad que cubre importancia sistémica, soporte a funciones críticas o importantes y sustituibilidad.
Una respuesta fuerte no es "we have an exit policy". Una respuesta fuerte muestra qué servicios se detienen, qué recovery objective aplica, dónde convergen las dependencias, qué exit path ha sido probado y quién puede decidir restringir, sustituir, salir o continuar el arrangement.
Management Report Panel
Calibración de la calidad de respuesta
El RAG status calibra la calidad de la respuesta. No juzga a la institución.
Quién debe responder
- Procurement puede poseer el contrato.
- Technology puede poseer la plataforma.
- El business posee el impacto.
- El board necesita ver la cadena.
Evidencias que el consejo debería solicitar
- 01Register of Information
- 02Critical Function Mapping
- 03Provider Criticality Classification
- 04Concentration Risk Assessment
- 05Fourth-Party Dependency Map
- 06RTO / RPO / MTPD View
- 07Tested Exit Strategy
- 08Contractual Exit and Transition Evidence
- 09Incident and Recovery Exercise Log
- 10Board Resilience Dashboard
Señales de alerta
- “We have an exit policy.”
- “The provider is directly overseen under DORA.”
- “This is handled by Procurement.”
- “The provider has strong SLAs.”
- “We use multiple providers.”
- “The service is not client-facing.”
- “The exit plan is documented.”
- “We could exit if necessary.”
Ninguna de estas afirmaciones es necesariamente falsa. Simplemente no constituyen evidencia suficiente para board-level reliance.
Camino hacia el verde
- Dependencias visibles
- Criticidad clasificada
- Concentración entendida
- Recovery medido
- Exit habilitado
- Riesgo residual gobernado
GREEN is not a contract status.
GREEN is a tested continuity status.
Próxima pregunta sugerida
¿Qué función crítica o importante crearía la mayor disruption si su proveedor ICT fallara mañana — y podemos demostrar el recovery path probado?
Base de fuentes seleccionada
- Regulation (EU) 2022/2554, Digital Operational Resilience Act, especially Articles 28, 29 and 30.
- European Supervisory Authorities, designation of critical ICT third-party providers under DORA, 18 November 2025.
- ESMA, official list of designated CTPPs under Article 31(9) of DORA.
- ECB Banking Supervision, Supervisory Priorities 2026–28.
- ESAs, Guide on DORA oversight activities, JC 2025 29.
- BCBS, Principles for Operational Resilience, 2021.
- FSB, Enhancing Third-Party Risk Management and Oversight, 2023.
- NIST Cybersecurity Framework 2.0.
- ISO 22301 Business Continuity Management.
Comentario de experto — 7 min de lectura
La resiliencia de terceros ICT suele discutirse mediante contratos, outsourcing registers y provider oversight. Esos elementos importan. Pero no responden a la pregunta más práctica del board.
¿Qué se detiene — y durante cuánto tiempo?
Esa pregunta es deliberadamente operativa. Traduce DORA desde el texto regulatorio a la realidad de gestión board-level. Un proveedor ICT crítico puede soportar un entorno cloud, un workflow engine, una capa de reporting, una capacidad de cybersecurity, un servicio de datos, un market-data feed, una plataforma documental o un proceso AI-enabled. El proveedor puede no ser visible para los clientes. La dependencia aun así puede ser crítica.
DORA hace explícito el punto de responsabilidad. Las entidades financieras que utilizan servicios ICT siguen siendo responsables de cumplir sus obligaciones, y el riesgo de terceros ICT debe gestionarse como parte del ICT risk management framework. DORA también exige que las entidades financieras mantengan y actualicen un Register of Information que cubra todos los arrangements contractuales sobre el uso de servicios ICT prestados por proveedores terceros ICT.
Visibilidad
Esto convierte la visibilidad en la primera disciplina.
Un board no puede supervisar una dependencia que no ve. Un banco no puede gobernar una cadena de proveedores que no ha mapeado. Y no puede responder "cuánto tiempo" sin un recovery objective probado vinculado a una función crítica o importante específica.
Concentración
La segunda disciplina es la concentración.
DORA exige que las entidades financieras consideren el riesgo de concentración al celebrar arrangements para servicios ICT que soporten funciones críticas o importantes. Esto incluye si un proveedor no es fácilmente sustituible o si múltiples arrangements crean dependencias del mismo proveedor o de proveedores estrechamente conectados.
Esto importa porque la diversificación puede ser engañosa.
Dos proveedores pueden parecer independientes a nivel contractual, pero converger en capas de cloud, data centre, network, identity, DNS, software, subcontracting u operational support. Una respuesta board-grade, por tanto, no se detiene en "we have more than one provider". Pregunta si los failure modes son genuinamente independientes.
Capacidad de exit
La tercera disciplina es la capacidad de exit.
DORA exige estrategias de exit para servicios ICT que soportan funciones críticas o importantes; esos exit plans deben ser completos, documentados, suficientemente probados y revisados periódicamente. DORA también exige arrangements contractuales escritos que asignen derechos y obligaciones, incluidas provisions relevantes para acceso, recovery, devolución de datos, termination y exit.
Aquí es donde las respuestas débiles suelen sonar plausibles.
Y la supervisión directa de un proveedor crítico no sustituye el third-party risk management propio de la institución. Las ECB Supervisory Priorities 2026–28 establecen que los requisitos relacionados con DORA, en particular ICT third-party risk e incident response management, deben implementarse de forma consistente y rápida; también establecen que el DORA oversight framework para critical third-party providers complementa, pero no sustituye, un sound third-party risk management.
La pregunta práctica del board no es, por tanto, si el proveedor es fuerte.
Es si la institución es resiliente al fallo del proveedor.
Eso requiere una estructura de respuesta diferente. El board debería ver una dependency map, una vista de criticidad, una concentration assessment, un recovery objective, un exit path probado, contractual evidence y un dashboard de riesgo residual. También debería ver dónde la substitution no es realista. En esos casos, la resiliencia debe venir de continuity arrangements, contingency planning, protección contractual, monitoring y aceptación formal del residual risk.
El objetivo no es eliminar cada dependencia.
Eso sería irrealista.
El objetivo es saber qué dependencias importan, qué se rompe cuando fallan, cuánto tarda el recovery, quién owns la respuesta y qué evidence soporta la respuesta.
Un proveedor supervisado no es lo mismo que una institución resiliente.
La resiliencia empieza cuando el board puede hacer la pregunta — y recibir una respuesta mapeada, probada y gobernable.