European banks' cloud dependency: How to get away from AWS, Microsoft, and Google if necessary

Part 3 of 7 of our DORA series: Cloud dependency is not solely a procurement issue. It determines whether a bank remains capable of acting in the event of a disruption, a contractual conflict, or a regulatory order. The exit plan according to DORA provides the obligation for this; this article translates it into a realistic architectural and operational question.

Author: acceleraid Editorial Team

DORA makes concentration visible – it does not resolve it

The European supervisory authorities have designated 19 critical ICT third-party service providers. The official list includes Amazon Web Services EMEA, Google Cloud EMEA, and Microsoft Ireland Operations. This is not a judgment on the quality of individual providers. However, it makes it clear that their services have a special relevance for parts of the financial system. The list is a transparent starting point for one's own concentration analysis. ESMA maintains the complete CTPP list.

DORA responds to this with supervision of the critical provider and responsibility at the bank. The strongest, but downstream lever is the last resort: competent authorities can suspend or terminate the use of a service. For institutions, this is not a comfortable external safety net. It is the scenario for which they must prepare a technically and organizationally resilient option for action. Exit is therefore not the end of a supplier relationship, but an integral part of resilience planning.

The market data explains why an exit is challenging

Concentration begins long before the individual bank contract. In the global public IaaS/PaaS market, AWS accounted for 29%, Microsoft 20%, and Google 13% in the third quarter of 2025 – totaling 63%. Synergy Research documents this distribution and the trend over time. The ECB's register analysis describes the banking practice side. Almost all banks have cloud contracts for critical functions; spending increased by 13.5%. At the same time, half of the total outsourcing budget is allocated to just 30 external providers. On average, contracts have four subcontractors, and 67% are passed on to external service providers. The ECB Banking Supervision Newsletter summarizes these findings. Therefore, an exit must not only move data and applications. It must also make locations, identities, interfaces, operational knowledge, and supply chains transparent.

The right question: Which dependency should be managed?

"We have two clouds" is not yet an exit strategy. What matters is which specific dependency exists and how it is resolved in the event of a disruption. Four assessment paths help with the classification:

This framework prevents two typical misconceptions. First, redundancy is not automatically portability: a replicated database is of little help if the identity model, key management, or observability only work in a proprietary service. Second, repatriation is not automatically simpler than a provider switch: the internal target needs capacity, controls, and operations teams before the trigger occurs.

The ECB identifies precisely these risk areas: provider lock-in, less predictable costs, more difficult audits, concentration of provided functions, and low visibility of sub-service providers. It explicitly recommends regularly reviewing the dependency on individual providers. The ECB's Guide on Cloud Outsourcing does not turn this into a blueprint for a specific target architecture. Rather, it requires the bank to traceably assess its own technical substitutability.

Three exit options – and their limits

First: Provider switch. This option is plausible if the application is operated with portable runtime environments, clear data formats, and documented interfaces. It requires a qualified target provider to be identified in advance. The proof is not a slide with logos, but a plan for data transfer, security controls, testing, and operations after the switch.

Second: Repatriation. A workload is migrated to the bank's own data center or a controlled private cloud environment. This can increase sovereignty and control, but shifts responsibility for capacity, patching, recovery, and skilled labor back to the bank. Repatriation is therefore a design path, not an automatic risk mitigation.

Third: Intentional diversification. Multiple execution locations can limit the risk of a single point of failure. However, they increase integration and testing efforts. Diversification only constitutes resilience if switching can actually be rehearsed for the prioritized services, data, and permissions. What such proof should look like is explained in Part 2 of our series on testing exit plans.

The Data Act strengthens the contractual position during switching: it obliges providers to reduce barriers to switching; for the transition, a maximum of 30 calendar days generally applies, and a maximum of two months for the notice period. Exceptions and limits remain. Articles 25 and 30 of the Data Act Regulation therefore replace neither an application migration nor a DORA exit runbook. However, they provide the runbook with important requirements regarding data export and interfaces.

Sovereignty means the ability to choose, not an origin label

The debate about European sovereignty is often reduced to the location of a data center. Location is relevant, but not sufficient. The US CLOUD Act obliges certain US providers to preserve, secure, or disclose data regardless of whether it is located inside or outside the US. The legislative text on Congress.gov shows why contract and jurisdiction issues belong in the risk assessment.

At the same time, a European provider is not inherently replaceable, and an international provider is not inherently unmanageable. Sovereignty arises from verifiable ability to choose: exportable data, documented interfaces, traceable subcontractor chains, audit rights, and a tested migration path. The location of a cloud belongs in this assessment, but it is no substitute for these proofs.

Switzerland: Stressed exit as a scenario

For Swiss banks, a stressed exit is explicitly part of the scenario testing: FINMA mentions, among other things, the insolvency of an important service provider or a prolonged ban by foreign governments, after which cloud providers may no longer serve Swiss companies. Tests are planned at least annually; table-top exercises are permitted. FINMA Circular 2023/1 thus puts the robust scenario in the foreground. This lesson also applies beyond Switzerland: it is not the list of providers that creates resilience, but the institution's ability to manage an outage in an orderly manner.

A practical task for the next quarter

Do not start with a cloud strategy presentation. Start with the few workloads whose outage significantly affects customer business, control functions, or reporting requirements. Classify these in the register of information and check the criteria for critical or important functions – in particular, data references and substitutability. Part 7 will delve deeper into this classification logic for core banking, CRM, data lake, and CDP.

For each prioritized workload, the architecture team, procurement, information security, and the business unit should generate a shared exit proof: target option, data export, dependencies, time and resource assumptions, testing steps, and decision triggers. This turns into a manageable backlog. The core thesis is: being able to walk away is not an event. It is a continuously maintained capability.

Overview of the DORA Series

• Part 1: DORA for Banks: What the EU regulation governs and how it works

• Part 2: The Exit Plan according to DORA: What it must contain and why it must be tested

• Part 3: Cloud dependency of European banks: How to get away from AWS, Microsoft, and Google if necessary (this article)

• Part 4: Exit Option for Customer Engagement Workloads: Securing CDP, Personalization, and Campaigns in a DORA-compliant manner

• Part 5: The DORA Register of Information: Why it is actually a data quality issue

• Part 6: AI Providers as a New Concentration Risk: What DORA means for model dependencies

• Part 7: Critical or Important? Risk levels from Core Banking to CRM, Data Lake, and CDP

Illustration: AI-generated. AI-supported content: In creating our articles, we use AI technologies and automated agents, including those from Microsoft, Google, OpenAI, Anthropic, and other providers. Topics, professional direction, and final approval remain with our team.