Digital sovereignty has become one of the most discussed concepts in European technology policy and one of the least precisely defined in practice. Politicians invoke it as a strategic imperative. Cloud providers have built product lines around it. Regulators reference it in supervisory guidance. And technology leaders in regulated financial institutions are expected to make architectural and procurement decisions that reflect it — frequently without a clear, operational definition of what achieving it would actually require.
This article attempts to provide that definition. It distinguishes the different dimensions of sovereignty that the EU framework addresses, examines honestly what the major hyperscalers' sovereign cloud offerings do and do not provide, assesses the current state of the EU Cloud Certification Scheme and GAIA-X against their original ambitions, and offers practical guidance for regulated banks trying to make sovereignty-aware architectural choices in the absence of a settled regulatory framework. It draws on the experience of navigating these questions in a BaFin-regulated environment, where the interaction between cloud adoption strategy, DORA compliance, and sovereignty requirements creates a genuinely complex set of obligations to balance.
What Digital Sovereignty Actually Means: Four Distinct Dimensions
Sovereignty, in the technology context, is not a single property — it is a collection of distinct concerns that are frequently conflated. Separating them is essential to making practical architectural decisions, because the answer to "are we sovereign?" depends entirely on which dimension of sovereignty you are asking about.
Most discussions of sovereign cloud focus on data sovereignty — specifically, data residency within the EU — while giving inadequate attention to legal sovereignty. The consequence is that institutions invest in architectures that keep their data physically in Frankfurt or Amsterdam, while remaining fully exposed to the CLOUD Act through their contractual relationship with a US-headquartered provider. Data residency and legal sovereignty are not the same thing, and an architecture that achieves the former without the latter has addressed the more visible concern while leaving the more serious one unresolved.
The US CLOUD Act: The Problem That Sovereign Cloud Marketing Does Not Solve
The Clarifying Lawful Overseas Use of Data Act (CLOUD Act), enacted by the United States Congress in 2018, authorises US law enforcement and national security agencies to demand data from US-based companies — including their foreign subsidiaries and data held in foreign facilities — subject to judicial oversight and certain bilateral agreement mechanisms. The key point for European financial institutions is that this authority applies to Microsoft, Amazon, Google and their cloud subsidiaries regardless of where the data is physically stored, because those companies are US-controlled entities subject to US law.
The hyperscalers have responded to this concern with sovereign cloud architectures that attempt to address it through operational isolation: keeping data processing within EU-controlled entities, limiting the circumstances under which US-based support staff can access European customer data, and using European-controlled encryption key management. Microsoft's EU Data Boundary and Sovereign Cloud offerings, AWS's EU Sovereign Cloud, and equivalent products from Google Cloud all represent genuine engineering investment in reducing — but not eliminating — CLOUD Act exposure.
"A sovereign cloud offering from a US-headquartered provider is a risk reduction, not a risk elimination. The legal exposure created by the US CLOUD Act cannot be fully neutralised by an operational architecture built on a US-controlled entity, regardless of how that architecture is structured."
The honest assessment of sovereign cloud products from US hyperscalers is that they substantially reduce the practical probability of CLOUD Act-based data access — by limiting the circumstances under which US personnel have access to EU customer data, using EU-resident key management, and establishing contractual commitments to challenge US government requests through available legal mechanisms. They do not, and by their legal nature cannot, guarantee that EU customer data will never be subject to US government access. For most banking workloads, this residual risk is assessable and manageable. For specific categories of highly sensitive data, it may be unacceptable — and the appropriate response is either not to process that data in hyperscaler cloud environments, or to use encryption architectures in which the institution retains sole control of the keys and the cloud provider never has access to unencrypted data.
What the Hyperscalers Actually Offer — and What They Don't
GAIA-X: What It Promised and What It Delivered
When the German and French governments launched GAIA-X in 2019, the ambition was substantial: a European cloud infrastructure that would provide an alternative to US hyperscaler dependency, built on European values of data protection and openness, governed by European entities. The expectation in some quarters was that GAIA-X would produce a European hyperscale cloud capable of competing with Azure, AWS and Google Cloud on their own terms.
That expectation was not met — and was probably never realistic. The hyperscalers joined GAIA-X early, contributing resources and technical expertise while inevitably shaping its direction. The vision of a single European cloud infrastructure evolved into a more modest but more achievable goal: a framework for data exchange, data space interoperability, and certification of cloud services that operate according to European principles.
What GAIA-X has delivered, and what is genuinely useful, is a set of standards and frameworks for data spaces — the technical and governance infrastructure that enables organisations to share data with defined access controls, usage policies, and provenance information, without requiring a single centralised data broker. The GAIA-X Data Exchange Services and the Trust Framework provide specifications that European financial institutions can use to build federated data sharing arrangements with counterparties, regulators, and ecosystem partners. This is less dramatic than a European hyperscaler, but it is real, available, and in some contexts directly relevant to the data mesh and data governance challenges that regulated banks face.
For practical cloud infrastructure decisions, the honest position on GAIA-X is that it does not currently provide an alternative to the major hyperscalers for core banking workloads. It provides a certification framework (GAIA-X Trust Framework) that adds a European-values layer on top of whatever cloud infrastructure is used — including hyperscaler infrastructure — and a set of data exchange standards that are most relevant for inter-organisational data sharing scenarios.
The EU Cloud Certification Scheme: Important, Incomplete, and Imminent
The European Union Cloud Certification Scheme (EUCS), developed by ENISA under the EU Cybersecurity Act, is the most consequential piece of the European sovereignty framework for regulated financial institutions — and the one whose development has been most contentious. When finalised, EUCS will establish three assurance levels — Basic, Substantial, and High — with the High level carrying the most demanding sovereignty requirements.
The controversy has centred on whether the EUCS High level should require that cloud services be provided by EU-headquartered and EU-controlled entities — which would effectively exclude the US hyperscalers from the top certification tier — or whether it should be achievable by any provider that meets the technical and operational standards, including US-headquartered providers with EU-located infrastructure and sovereignty controls. The first position reflects the original intent of data and legal sovereignty. The second reflects the practical reality that European institutions are deeply committed to hyperscaler infrastructure and that the capability gap with European alternatives is significant.
As of the time of writing, the EUCS finalisation process has been ongoing for several years, with the High-level sovereignty requirements remaining the principal unresolved issue. The political sensitivity is real: the European Commission faces pressure from member states with large technology sectors (France, Germany) that want genuine sovereignty requirements, and from others that prioritise continuity of access to hyperscaler services. For regulated financial institutions, the practical implication is that EUCS High certification cannot yet be used as a definitive sovereignty criterion — but its eventual requirements will be the most important regulatory signal for cloud architecture decisions in the coming years.
In navigating sovereignty questions within a BaFin-regulated environment, the most operationally useful framing is not "are we sovereign?" — which invites an all-or-nothing answer — but "which specific workloads, data categories, and access scenarios create sovereignty risk, and what is our assessed and documented risk position for each?" This approach produces a manageable set of decisions rather than an intractable policy debate. Most banking data, classified honestly, does not require the strongest sovereignty protections. The data that does — specific categories of customer data, sensitive strategic information, data subject to banking secrecy — can be identified precisely and given architectural treatment proportionate to the actual risk.
The EU Cloud Sovereignty Framework v1.2.1: From Policy to Measurement
The most significant development in the EU sovereignty landscape since the article above was drafted is the European Commission's publication, on 20 October 2025, of the Cloud Sovereignty Framework (CSF) version 1.2.1, produced by the Directorate-General for Digital Services. The CSF represents precisely the shift from abstract policy to measurable engineering requirement that the earlier regulatory landscape had been pointing toward but had not yet achieved.
The CSF introduces two complementary assessment mechanisms. First, the Sovereignty Effective Assurance Level (SEAL) — a five-level scale (SEAL-0 to SEAL-4) applied to each of eight Sovereignty Objectives, used as a minimum assurance threshold: tenders that fail to achieve the required SEAL level for any objective are automatically rejected. Second, a Sovereignty Score — a weighted quantitative measure that allows contracting authorities to rank providers that meet the minimum thresholds. The framework was immediately operationalised through the EU's EUR 180 million Cloud III Dynamic Purchasing System procurement, making it the first instance of sovereignty requirements being applied as hard pass/fail criteria in a major EU cloud tender.
The eight Sovereignty Objectives are: Strategic Sovereignty (SOV-1); Legal & Jurisdictional Sovereignty (SOV-2); Data & AI Sovereignty (SOV-3); Operational Sovereignty (SOV-4); Supply Chain Sovereignty (SOV-5); Technology Sovereignty (SOV-6); Security & Compliance Sovereignty (SOV-7); and Environmental Sustainability (SOV-8). The SEAL levels range from SEAL-0 (service under exclusive non-EU control, with no meaningful EU law applicability) through SEAL-2 (EU law applicable and enforceable, but material non-EU dependencies remain) to SEAL-4 (technology and operations under complete EU control, subject only to EU law, with no critical non-EU dependencies).
While the CSF was developed for EU public procurement rather than as a direct regulatory requirement for private sector financial institutions, it represents the most rigorous and comprehensive sovereignty assessment methodology currently available — and it is the framework against which the Cloud and AI Development Act, when enacted, is expected to align. For regulated banks assessing cloud provider sovereignty, the CSF provides a structured, evidence-based methodology that is substantially more precise than any predecessor. A companion piece to this article, Deriving SEAL Ratings in Practice, addresses how regulated banks can apply the CSF assessment methodology to their own cloud arrangements.
BaFin's Position and the German Regulatory Context
BaFin has not prescribed specific sovereignty requirements for cloud usage beyond the framework established by BAIT, MaRisk and — now — DORA. Its position, consistent with the EBA's, is that institutions must assess and manage the risks of their cloud arrangements, document their risk acceptance, and maintain adequate oversight and exit capability. The specific question of CLOUD Act exposure is addressed in BaFin's cloud guidance: the supervisor expects institutions to have assessed this risk, documented their assessment, and accepted any residual risk at an appropriate governance level — it does not mandate a particular technical solution.
The German government's own cloud strategy — and the presence of T-Systems, Deutsche Telekom, and SAP as significant players in German cloud infrastructure — creates a specific domestic context that differs from some other European markets. T-Systems operates the Open Telekom Cloud and has partnership arrangements with both Google Cloud (for sovereign managed services) and Microsoft (through specific programmes). SAP's Business Technology Platform, while not a general-purpose cloud infrastructure, provides regulated enterprise workloads on European infrastructure with strong data governance characteristics. These options are worth genuine evaluation for specific workloads — particularly for institutions with existing SAP landscapes — rather than being dismissed in favour of hyperscaler-only architectures.
Sovereignty as Architecture: Practical Decision Points
Translating the sovereignty framework into architectural decisions requires working through a set of specific questions for each workload and data category. The decisions are not binary — they exist on a spectrum from "process on any cloud infrastructure, CLOUD Act exposure accepted" to "process only on infrastructure with no extraterritorial legal exposure, using institution-controlled encryption."
Data Classification for Sovereignty
The starting point is a data classification framework that includes a sovereignty dimension — not just sensitivity (confidential, internal, public) but legal exposure. Banking secrecy data, strategic M&A information, and certain categories of customer financial data warrant the strongest protections. Operational data, development and test environments, and analytics workloads built on anonymised data typically do not. The majority of bank data, classified honestly, falls into categories where CLOUD Act exposure is a documented residual risk rather than an absolute prohibition.
Encryption Architecture
For data that requires protection from CLOUD Act access, customer-managed encryption keys — where the institution, not the cloud provider, controls the encryption keys and the provider never has access to unencrypted data — provide a technically robust mitigation. This requires that key management infrastructure is maintained in a jurisdiction and legal entity not subject to US law: either on-premise, in an EU-headquartered provider's key management service, or through hardware security module arrangements that the institution controls directly. The operational overhead of customer-managed keys is real and must be planned for, but for specific sensitive data categories it is the appropriate architectural choice.
Concentration Risk as a Sovereignty Concern
DORA's concentration risk provisions — which address the systemic risk created when many financial institutions depend on the same small number of ICT providers — are, at a sectoral level, a sovereignty concern expressed in operational resilience language. An institution that has migrated comprehensively to a single hyperscaler, with deep integration into that provider's proprietary services, has not only created DORA-relevant concentration risk but has also severely constrained its technological sovereignty — its ability to exercise strategic optionality over its IT infrastructure. Multi-cloud architecture, where implemented thoughtfully rather than as a result of uncoordinated procurement decisions, is one practical response to both concerns simultaneously.
Questions for Architecture and Governance Leaders
- Has your organisation defined sovereignty operationally — distinguishing data, operational, technological and legal sovereignty — rather than treating it as a single undifferentiated concept?
- Have you completed a data classification exercise that includes a sovereignty dimension, identifying specifically which data categories require protection from CLOUD Act exposure?
- For data processed on US-headquartered cloud providers' infrastructure, has the CLOUD Act residual risk been formally assessed, documented and accepted at an appropriate governance level?
- For your most sensitive data categories, is customer-managed encryption with institution-controlled key management in place — or is the cloud provider in a position to access unencrypted data under US legal compulsion?
- Does your cloud architecture give genuine consideration to European alternatives (Open Telekom Cloud, OVHcloud, SAP BTP) for specific workloads where their sovereignty advantages outweigh the capability differential?
- Are you monitoring the EUCS finalisation process, and do you have a plan to assess and, where necessary, adapt your cloud architecture against the High-level requirements once they are confirmed?
- Does your cloud strategy address technological sovereignty — specifically, the degree to which your architecture is portable and your exit strategy is realistic — as distinct from data residency?
Conclusion: Sovereignty Is a Spectrum, Not a Binary
The framing of digital sovereignty as an all-or-nothing property — either you are sovereign or you are not — has produced more confusion than clarity in the European financial services sector. It has driven some institutions to make categorical statements about sovereign cloud that cannot survive scrutiny, and others to dismiss sovereignty as an unachievable aspiration and make no meaningful provision for it at all.
The more useful framing is that sovereignty exists on a spectrum for each dimension — data, operational, technological, legal — and that different workloads, data categories, and risk scenarios call for different positions on that spectrum. The goal is not to achieve sovereignty in the abstract but to make explicit, documented, risk-assessed decisions about where on the spectrum each significant workload sits, and to have architectural treatments proportionate to the actual risk for those workloads where the residual exposure is unacceptable.
The EU framework — EUCS when finalised, GAIA-X standards where applicable, the data space models emerging from European policy — provides a direction of travel that is coherent even if the destination is not yet fully defined. Regulated financial institutions that are building architectures today need to do so in a way that is responsive to that direction: not waiting for the framework to be finalised before making any architectural choices, but making choices that will not need to be fundamentally reversed when the framework arrives.
In a BaFin-regulated environment specifically, the supervisory expectation is not perfection — it is documented, risk-assessed, actively managed decision-making. Institutions that can demonstrate they have understood the sovereignty dimensions of their cloud arrangements, assessed the risks for each material workload, accepted residual risks at the appropriate governance level, and built architectures that give them genuine strategic optionality are in a fundamentally stronger supervisory position than those that have adopted a sovereignty narrative without the substance to support it.