If Your Critical ICT Provider Fails Tomorrow, What Stops — and for How Long?
At a glance
The issue is no longer only the provider.
The issue is whether the institution can evidence continuity.
Board AskConfirm whether the institution can evidence continuity and exit capability for ICT services supporting critical or important functions.
Situation
Assume the following situation.
A critical ICT third-party provider becomes unavailable. It supports a platform, data service, cloud environment, workflow engine, reporting layer or AI-enabled process used by the institution. Within hours, the question is no longer whether the provider has a contractual obligation to restore service.
The question is what stops inside the bank.
Which critical or important functions are affected? Which client, risk, operational or decision chains depend on the provider? What is the tested recovery time? Can the service be substituted, exited or restored within the institution's tolerance?
The issue is no longer only the provider.
The issue is whether the institution can evidence continuity.
Management Summary
DORA makes ICT third-party risk a board-level, evidenced discipline. Financial entities remain responsible for compliance even when ICT services are provided by third parties; DORA also requires ICT third-party risk management, a register of information and exit strategies for ICT services supporting critical or important functions.
The European Supervisory Authorities published the first list of 19 designated critical ICT third-party providers under DORA on 18 November 2025. The designation process used data from Registers of Information and a criticality assessment covering systemic importance, support for critical or important functions and substitutability.
A strong answer is not "we have an exit policy". A strong answer shows which services stop, which recovery objective applies, which dependencies converge, which exit path has been tested and who can decide to restrict, substitute, exit or continue the arrangement.
Management Report Panel
Answer Quality Calibration
The RAG status calibrates the quality of the answer. It does not judge the institution.
Who Should Answer
- Procurement may own the contract.
- Technology may own the platform.
- The business owns the impact.
- The board needs to see the chain.
Evidence the Board Should Request
- 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
Warning Signals
- “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.”
None of these statements is necessarily wrong. They are simply not sufficient evidence for board-level reliance.
Path to Green
- Dependencies visible
- Criticality classified
- Concentration understood
- Recovery measured
- Exit enabled
- Residual risk governed
GREEN is not a contract status.
GREEN is a tested continuity status.
Suggested Next Question
Which critical or important function would create the greatest disruption if its ICT provider failed tomorrow — and can we evidence the tested recovery path?
Selected Source Base
- 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.
Expert commentary — 7 min read
ICT third-party resilience is often discussed through contracts, outsourcing registers and provider oversight. Those elements matter. But they do not answer the board's most practical question.
What stops — and for how long?
That question is deliberately operational. It translates DORA from regulatory text into board-level management reality. A critical ICT provider can support a cloud environment, workflow engine, reporting layer, cybersecurity capability, data service, market-data feed, document platform or AI-enabled process. The provider may not be visible to clients. The dependency may still be critical.
DORA makes the responsibility point explicit. Financial entities using ICT services remain responsible for compliance with their obligations, and ICT third-party risk must be managed as part of the ICT risk management framework. DORA also requires financial entities to maintain and update a register of information covering all contractual arrangements on the use of ICT services provided by ICT third-party service providers.
Visibility
This makes visibility the first discipline.
A board cannot oversee a dependency it cannot see. A bank cannot govern a provider chain it has not mapped. And it cannot answer "how long" without a tested recovery objective linked to a specific critical or important function.
Concentration
The second discipline is concentration.
DORA requires financial entities to consider concentration risk when entering into arrangements for ICT services supporting critical or important functions, including whether a provider is not easily substitutable or whether multiple arrangements create dependencies on the same or closely connected providers.
That matters because diversification can be misleading.
Two providers may appear independent at contract level but converge at cloud, data centre, network, identity, DNS, software, subcontracting or operational-support layers. A board-grade answer therefore does not stop at "we have more than one provider". It asks whether the failure modes are genuinely independent.
Exit capability
The third discipline is exit capability.
DORA requires exit strategies for ICT services supporting critical or important functions; those exit plans must be comprehensive, documented, sufficiently tested and periodically reviewed. DORA also requires written contractual arrangements that allocate rights and obligations, including provisions relevant to access, recovery, return of data, termination and exit.
This is where weak answers often sound plausible.
And direct oversight of a critical provider does not replace the institution's own third-party risk management. The ECB's Supervisory Priorities 2026–28 state that DORA-related requirements, particularly ICT third-party risk and incident response management, must be implemented consistently and swiftly; they also state that the DORA oversight framework for critical third-party providers complements, but does not substitute, sound third-party risk management.
The practical board question is therefore not whether the provider is strong.
It is whether the institution is resilient to provider failure.
That requires a different answer structure. The board should see a dependency map, a criticality view, a concentration assessment, a recovery objective, a tested exit path, contractual evidence and a dashboard of residual risk. It should also see where substitution is not realistic. In those cases, resilience must come from continuity arrangements, contingency planning, contractual protection, monitoring and formal residual-risk acceptance.
The goal is not to eliminate every dependency.
That would be unrealistic.
The goal is to know which dependencies matter, what breaks when they fail, how long recovery takes, who owns the response and what evidence supports the answer.
A supervised provider is not the same as a resilient institution.
Resilience starts when the board can ask the question — and receive an answer that is mapped, tested and governable.