The moment DORA entered into application on 17 January 2025, a particular species of vendor pitch intensified: "You need multi-cloud to be DORA-compliant." The implication was clear and commercially convenient — buy more cloud, from more providers, and your concentration risk problem goes away.
It does not. And the regulation does not say it should.
DORA's treatment of ICT concentration risk is considerably more sophisticated than "spread your workloads across three hyperscalers." Financial entities that respond to Articles 28 and 29 with reflexive multi-cloud strategies risk spending enormous sums on operational complexity that does not reduce risk — and may actually increase it. The question regulators are asking is not "how many cloud providers do you use?" It is "do you understand your dependencies, and can you survive the failure or exit of any single one?"
Those are very different questions. They demand very different answers.
What DORA Actually Says About Concentration Risk
Let us start with the text. Article 28(1) requires financial entities to manage ICT third-party risk "as an integral component of their ICT risk management framework." Article 28(3) mandates a register of information covering all contractual arrangements on the use of ICT services provided by third-party service providers. Article 29 specifically addresses ICT concentration risk, requiring financial entities to take into account whether concluding a contractual arrangement would lead to dependencies on ICT third-party service providers that are "not easily substitutable."
The critical phrase is "not easily substitutable." The regulation is concerned with lock-in and exit capability, not with counting providers. A financial entity running entirely on AWS but maintaining a tested, credible exit plan to migrate to an alternative provider within a defined timeframe is, from a regulatory perspective, in a stronger position than one running across AWS, Azure, and GCP with tangled interdependencies and no coherent exit strategy for any of them.
Article 28(8) reinforces this by requiring contractual provisions that ensure exit strategies can be executed "without disruption to business activities" and "without detriment to the continuity and quality of services." The focus is on substitutability and resilience — the ability to move, not the current state of distribution.
The Regulatory Technical Standards further specify that financial entities must assess concentration risk at the entity level, the group level, and from a systemic perspective. This means evaluating not just your own dependencies but understanding whether the wider financial sector's reliance on the same provider creates systemic vulnerability. A mid-sized bank running entirely on a provider that also hosts 60% of the European banking sector's payment processing has a different concentration profile than the same bank using a niche provider serving a handful of financial institutions.
The Multi-Cloud Myth: More Clouds Does Not Equal Less Risk
Here is the uncomfortable truth that multi-cloud evangelists rarely discuss: operating across multiple cloud providers introduces failure modes that do not exist in a single-cloud architecture.
Consider the operational reality. Each major cloud provider has its own identity and access management model, its own networking paradigm, its own approach to encryption at rest and in transit, its own monitoring and logging architecture. Running workloads across AWS, Azure, and GCP means maintaining expertise in three distinct security models, three sets of compliance controls, three monitoring pipelines, and three incident response playbooks.
The security team that was already stretched thin managing one cloud environment now has three attack surfaces to monitor, three sets of API credentials to rotate, three configuration drift patterns to detect. The probability of a misconfiguration — the leading cause of cloud security incidents — does not decrease with more providers. It increases, roughly linearly, with each additional environment.
Then there is the data consistency problem. Financial services applications that span multiple clouds require cross-cloud data synchronisation, which introduces latency, consistency challenges, and new categories of failure. A payment processing system that needs to maintain consistent state across two cloud providers is architecturally more fragile, not less, than one that maintains state within a single provider's ecosystem.
The networking complexity alone is substantial. Cross-cloud connectivity typically relies on either public internet paths (introducing availability and security concerns) or dedicated interconnects (introducing cost and management overhead). Every cross-cloud network path is a potential failure point that would not exist in a single-provider architecture.
None of this means multi-cloud is never appropriate. It means that multi-cloud is a tradeoff, not a pure improvement. And DORA does not require you to make that tradeoff blindly.
When Diversification Makes Sense
Concentration risk diversification is genuinely valuable in specific, identifiable scenarios. The key is performing critical path analysis rather than applying a blanket diversification strategy.
Genuinely critical, non-substitutable services. If your core banking platform runs on a single cloud provider and that provider's failure would halt all banking operations, the concentration risk is real and material. But the answer is not necessarily "also run on Azure." It might be "ensure the provider's contractual SLA includes meaningful financial penalties, maintain a tested migration runbook, and architect the application for portability."
Sector-systemic concentration. If your primary cloud provider also hosts the critical infrastructure of your payment processor, your SWIFT connectivity partner, and your primary market data feed, a provider-level failure creates correlated failures across your entire value chain. In this case, diversifying your own workload reduces sector-systemic correlation.
Regulatory jurisdiction constraints. Some data residency requirements may genuinely necessitate using providers with infrastructure in specific EU member states where your primary provider lacks presence. This is geographic diversification driven by legal necessity, not risk theology.
Service-specific best-of-breed. Using one provider for general compute and storage while using a specialised provider for specific capabilities — high-performance computing, specialised AI inference, sovereign cloud requirements — is pragmatic diversification. It maps different services to different providers based on capability fit, not abstract risk distribution.
In each case, the diversification decision is specific, justified, and bounded. It is not "we must be multi-cloud because DORA says so." It is "we have analysed our critical dependencies and identified a specific concentration that warrants mitigation through provider diversification."
When Single-Cloud With Exit Planning Is Smarter
For many financial entities, the most cost-effective and operationally sound response to DORA concentration risk requirements is to remain on a single primary cloud provider while building and maintaining a credible exit capability.
The cost-benefit analysis is straightforward. Operating a genuinely multi-cloud architecture — not just running a few test workloads on a second provider, but maintaining production-grade operations across multiple environments — typically costs 40-60% more than a single-cloud approach. That premium buys infrastructure duplication, additional staffing or training, cross-cloud networking, and the operational overhead of maintaining parity across environments.
That same budget, invested in exit capability, buys something more valuable: the ability to migrate if and when migration becomes necessary, without the ongoing cost of operating in parallel.
A credible exit strategy under DORA Article 28(8) requires several components. First, application architecture that avoids deep provider lock-in. This means containerised workloads, infrastructure-as-code that can be adapted to alternative providers, and abstraction layers over provider-specific services where feasible. You do not need to maintain parallel deployments. You need to ensure your applications can be redeployed on alternative infrastructure within a defined timeframe.
Second, data portability. Your data export capabilities, backup formats, and migration tooling must be tested and documented. Can you extract all customer data, all transaction records, all audit logs in a provider-neutral format? Have you tested restoration of that data on alternative infrastructure?
Third, contractual protections. DORA Article 28(7) and (8) require specific contractual provisions around data access, return, and deletion. Your contracts should guarantee data portability assistance, transition periods, and continued service during migration.
Fourth, regular testing. An exit plan that has never been tested is not a plan — it is a hope. Annual or semi-annual exit drills, even partial ones, demonstrate to supervisors that your exit capability is genuine.
The Register of Information Requirement
Article 28(3) requires financial entities to maintain a register of information in relation to all contractual arrangements on the use of ICT services provided by third-party service providers. This register is not a spreadsheet of vendor names. It is a dependency map.
The register must identify which business functions depend on which ICT services, which ICT services are provided by which third-party providers, and which of those arrangements involve sub-outsourcing. It must capture the criticality classification of each arrangement and enable the financial entity to identify where concentration risk exists.
Building this register properly is the foundation of any credible concentration risk strategy. Without it, you cannot know where your concentration actually lies. Many financial entities discover, during the register-building exercise, that their concentration risk is not where they expected. The obvious cloud provider dependency is visible, but the less obvious dependencies — a single provider for certificate management, a single DNS provider, a shared monitoring platform, the same Container registry service across all environments — often represent more acute concentration risks because they are less visible and less likely to have exit plans.
A well-structured register also enables the systemic analysis that supervisors increasingly expect. When the European Supervisory Authorities designate Critical ICT Third-Party Providers under DORA Article 31, financial entities need to rapidly assess their exposure to those designated providers. An asset registry that maps services to providers to business functions makes that assessment possible within hours rather than weeks.
Tools like FortisEU's asset registry and vendor risk management module are designed specifically for this mapping exercise — connecting ICT assets to vendor relationships to business-critical functions in a single queryable structure.
Building a Credible Exit Strategy Without Building a Second Infrastructure
The practical challenge is clear: DORA requires exit capability, but maintaining a fully operational second infrastructure is prohibitively expensive for most financial entities. The solution lies in what might be called "exit readiness" — a spectrum of preparation that falls between "we have a slide deck" and "we run everything in two places."
At minimum, exit readiness means architectural portability. Your applications run in containers, your infrastructure is defined in code, and your data stores use standard formats or have tested export procedures. This costs relatively little to maintain and provides the foundation for any migration.
The next level is tested portability. Periodically — annually or semi-annually — you execute a partial migration exercise. Deploy your containerised applications on alternative infrastructure. Restore a data snapshot on a different database service. Run your integration tests against the alternative deployment. Document what worked, what broke, and what would need to be resolved in a real migration scenario. This is your evidence for supervisors.
The highest level, short of full parallel operation, is warm standby for critical paths only. Your most critical service — perhaps your customer-facing portal or your payment processing pipeline — has a tested deployment on alternative infrastructure that can be activated within hours. Non-critical services have migration runbooks but not standing deployments.
Each level costs more than the previous one. But each level costs dramatically less than full multi-cloud operation. And each level provides genuine, demonstrable exit capability that satisfies DORA's requirements.
ESA Expectations: What Supervisors Actually Look For
European Supervisory Authority guidance on ICT concentration risk assessment, published alongside the DORA Regulatory Technical Standards, tells us what supervisors will evaluate during examinations.
Supervisors expect financial entities to demonstrate that they have identified their ICT dependencies, assessed substitutability, classified criticality, and developed proportionate mitigation strategies. "Proportionate" is the operative word. A Tier 1 systemically important bank running core banking on a single provider that also serves 40% of the sector's payment infrastructure faces legitimate supervisory scrutiny. A mid-sized asset manager using a single cloud provider for portfolio management and reporting, where the provider serves a modest share of the sector, faces different expectations.
What supervisors do not expect — and the Regulatory Technical Standards do not require — is that every financial entity operates a multi-cloud architecture. They expect evidence of conscious, documented decision-making. Why did you choose your current provider? What alternatives exist? Under what circumstances would you migrate? How long would migration take? What business continuity arrangements bridge the transition period? What contractual provisions protect your interests?
These are answerable questions that do not require writing cheques to a second cloud provider. They require analysis, planning, testing, and documentation. A comprehensive DORA preparation approach addresses all of them.
The supervisory approach to third-party oversight is evolving, but the direction is clear: substance over checkbox. A financial entity that presents a thoughtful, tested, documented single-cloud strategy with genuine exit capability will satisfy supervisory expectations more convincingly than one that presents a chaotic multi-cloud deployment with no coherent exit plan for any of its providers.
Key Takeaways
DORA does not mandate multi-cloud. Articles 28 and 29 require concentration risk assessment, substitutability analysis, and exit capability. They do not prescribe provider diversification as the mandatory response.
Multi-cloud introduces complexity costs that offset concentration benefits. Three security models, three monitoring pipelines, three incident response procedures, and cross-cloud data consistency challenges create operational risk that may exceed the concentration risk being mitigated.
The register of information is the foundation. Without a comprehensive mapping of ICT services to providers to business functions, concentration risk assessment is guesswork. Build the register first. The risk picture it reveals will be more nuanced than "we use too much AWS."
Exit capability matters more than current distribution. A tested, documented, contractually protected ability to migrate is more valuable — and far less expensive — than maintaining parallel production environments.
Proportionality applies. Supervisors expect concentration risk responses proportionate to the entity's size, complexity, and the criticality of the services involved. Not every financial entity needs the same approach.
Test your exit plan. An untested exit strategy is not a strategy. Periodic, partial migration exercises generate the evidence supervisors want and reveal the gaps that matter before they become crises.