Sovereign cloud has become one of the most discussed concepts in European financial services technology — and one of the most poorly defined. The term is used to describe everything from hyperscaler data residency commitments to fully air-gapped national infrastructure, with a great deal of variation in between. For technology leaders in regulated financial institutions, the challenge is not understanding what sovereign cloud could mean in theory but determining what their specific regulator requires in practice — and then assessing what the market actually delivers against that requirement.
The gap between the two is, in most cases, substantial.
What Regulators Actually Require
The regulatory framework for cloud usage by European financial institutions has become significantly more prescriptive over the past five years. DORA, the EBA Guidelines on Outsourcing, the ECB's supervisory expectations on cloud, and BaFin's own circulars on outsourcing and IT risk management collectively define a framework that is detailed, demanding, and not always internally consistent.
The core regulatory requirements for cloud usage in regulated financial services cluster around four themes.
Data residency and sovereignty. Regulators require that data classified as sensitive — customer data, financial data, supervisory data — is processed and stored within defined geographic boundaries, and that the financial institution maintains meaningful control over who can access it. The US CLOUD Act is the specific concern that drives sovereign cloud requirements in European financial services: the possibility that US law enforcement could compel a US-headquartered cloud provider to produce data stored in European facilities, regardless of European data protection law. BaFin's expectations in this area are explicit: institutions must be able to demonstrate that their cloud provider cannot be compelled to produce data by a non-EU legal authority without the institution's knowledge and ability to contest.
Operational resilience and exit capability. DORA requires that financial entities maintain the ability to exit a cloud arrangement and either migrate to an alternative provider or bring the service back in-house within a defined timeframe. This exit capability must be documented, tested, and technically feasible — not merely a contractual right. The practical implication is that cloud architectures must be designed from the outset to be portable, and that lock-in to proprietary cloud services that would be technically difficult or prohibitively expensive to migrate away from must be limited for critical functions.
Audit and inspection rights. Regulators require that financial institutions and their supervisors have the right to audit the cloud provider's facilities, processes and controls — and that this right is exercised, not merely reserved. Major hyperscalers have developed audit frameworks that satisfy these requirements through third-party assessments and shared audit reports. Whether these frameworks satisfy individual regulators' expectations varies, and the position has evolved as regulators have gained more experience examining cloud arrangements.
Concentration risk management. The EBA's guidelines on outsourcing, and more recently DORA, require financial institutions to assess and manage the concentration risk that arises from reliance on a small number of cloud providers. An institution that has migrated the majority of its critical functions to a single hyperscaler has created a systemic dependency that regulators expect to be actively managed — including scenario planning for the failure or unavailability of that provider.
"Sovereign cloud is not a product. It is a set of regulatory requirements that different products satisfy to different degrees, in different contexts, for different regulators. Treating it as a product category leads to procurement decisions that satisfy the marketing but not the compliance requirement."
What the Market Delivers
The hyperscale cloud providers have developed sovereign cloud offerings — Microsoft Azure Sovereign, Google Distributed Cloud, AWS GovCloud and their European variants — in response to the regulatory requirements of their public sector and financial services customers. These offerings vary significantly in what they actually deliver, and the marketing language used to describe them consistently overstates the degree to which they satisfy strict regulatory requirements.
The most important distinction is between data residency and operational sovereignty. Data residency — ensuring that data is stored and processed within defined geographic boundaries — is a capability that all major hyperscalers now provide, and it is relatively straightforward to configure and verify. Operational sovereignty — ensuring that the infrastructure cannot be accessed, controlled or compelled by non-EU authorities — is considerably harder to achieve with hyperscaler infrastructure, because the underlying control plane, the management tooling, and the operational teams are typically US-based regardless of where the data sits.
The offerings that come closest to genuine operational sovereignty are those that physically separate the infrastructure under European operational control — either through a dedicated physical stack managed by a European operator (the model used by offerings like Azure operated by Gaia-X members), or through fully on-premises infrastructure managed as a cloud service (Google Distributed Cloud's model). Both approaches involve meaningful trade-offs in capability, cost and operational complexity relative to standard hyperscaler cloud.
The architecture that satisfies both regulatory requirements and operational needs for most regulated European financial institutions is a three-tier model: standard hyperscaler cloud for non-sensitive workloads and development environments; sovereign or regulated cloud for sensitive customer and financial data; and private cloud or dedicated infrastructure for the most sensitive regulatory and supervisory data. Designing this model requires clarity about which data and workloads fall into each tier — a classification exercise that is harder than it sounds and that most institutions have not completed to the standard their regulators will eventually require.
Navigating the Gap in Practice
Technology leaders responsible for cloud strategy in regulated financial institutions face a genuinely difficult navigation challenge: regulatory requirements that are demanding and sometimes ambiguous, vendor offerings that are marketed with more confidence than their actual compliance status warrants, and a supervisory environment in which the acceptable approach is still being defined through examination and guidance rather than settled regulation.
The practical approach that has worked in the institutions where I have been involved in cloud strategy development has three components.
Engage with your regulator directly and early. BaFin's approach to cloud in financial services has evolved significantly over the past five years, and its current expectations are more nuanced than the published guidance alone conveys. Institutions that have engaged directly — submitting their cloud architectures for informal assessment before committing to them — consistently get better outcomes than those that implement first and seek approval afterwards.
Classify your workloads against your regulatory obligations before choosing a cloud model. The choice of cloud model — standard, sovereign, private — should follow from a workload classification that maps each application and dataset against the regulatory obligations that apply to it. Choosing a cloud model first and then determining which workloads it can accommodate is the wrong sequence.
Build your exit capability as a first-class architecture requirement. DORA's exit capability requirement is not satisfied by a contractual exit clause. It requires a tested, documented, technically feasible migration plan for every critical cloud-hosted function. Institutions that build their cloud architectures around proprietary cloud-native services — because they are convenient and capable — are accumulating exit risk that will be expensive to manage when regulators require evidence of exit capability.
- Have you mapped your workload classification against the specific requirements of BaFin (or your relevant regulator) for data residency, operational sovereignty and audit rights?
- Have you assessed each of your cloud arrangements against the DORA exit capability requirement — not contractually, but technically?
- Have you engaged directly with your supervisor about your cloud architecture before finalising it?
- Have you assessed and documented your concentration risk across cloud providers, and defined a management approach that satisfies the EBA and DORA requirements?
- Do your cloud contracts include the mandatory provisions required by DORA Article 30 for ICT third-party service providers of critical or important functions?