Meta description: Sovereign cloud is evolving beyond data residency. Explore the legal, operational, cryptographic, resilience and exit controls banks should assess before moving regulated workloads to cloud environments.

Executive summary

For years, regulated cloud discussions began with one question: Where is the data stored?

That question remains essential, but it is no longer sufficient. The European Commission’s Cloud Sovereignty Framework evaluates services through 48 criteria across eight categories: strategic; legal and jurisdictional; data and AI; operational; supply chain; technological; security and compliance; and environmental sustainability.

Sovereignty is therefore better understood as a control model encompassing location, jurisdiction, operators, encryption, resilience, dependencies and exit readiness.

AWS European Sovereign Cloud: a new operating model

The AWS European Sovereign Cloud became generally available on 14 January 2026, with its first region in Brandenburg, Germany. AWS describes it as physically and logically separate from its existing regions, with multiple availability zones and the ability to operate if external connectivity is interrupted.

AWS states that customer-created content and metadata remain within the EU, supported by dedicated identity, billing, certificate-authority and DNS arrangements. Operations are currently performed by EU residents located in the EU, with a transition towards operation exclusively by EU citizens located in the EU. The infrastructure is backed by an announced €7.8 billion investment.

These are provider claims and contractual or architectural commitments that customers should validate against their specific regulatory obligations. The broader significance is that sovereign cloud is moving beyond regional hosting towards separate governance, operations and technical control planes.

Sovereignty exists on a spectrum

Control pattern	Authoritative example	What it can address	What a bank must still verify
Regional cloud with additional data-boundary controls	Google Cloud’s KSA Data Boundary option for Dammam	Local processing controls and access justification	Service-level residency, support access, metadata and recovery locations
Local sovereign-partner model	CNTXT-operated sovereign controls for Google Cloud Dammam	Local support, externally managed keys and additional operating controls	Allocation of responsibility between global provider and local partner
Independent sovereign cloud environment	AWS European Sovereign Cloud	Separate infrastructure, identity, operations and EU governance	Remaining supply-chain dependencies, service availability and exit design
Private or disconnected environment	Customer-controlled deployment pattern	Maximum infrastructure and connectivity control	Upgrade capability, specialist skills, security operations and long-term cost

No single pattern is universally preferable. The appropriate model depends on workload materiality, legal requirements, operational risk and the level of independence required.

The following infographic illustrates why residency is only one layer of the decision.

Data residency is one layer of sovereignty; effective control also depends on jurisdiction, operators, keys, auditability, resilience and exit readiness.

What regulators expect from banks

The ECB’s final cloud-outsourcing guide, published in July 2025, does not introduce requirements beyond the EU’s Digital Operational Resilience Act. Instead, it clarifies supervisory expectations and recommends a risk-based, proportionate approach to cloud outsourcing, highlighting dependency, IT-security and concentration concerns.spa+1

GCC frameworks express similar accountability principles. Qatar Central Bank’s Cloud Computing Regulation entered into force on 15 April 2024 and requires cloud governance, provider due diligence, cloud-arrangement registers, audit rights, business-continuity integration and documented exit planning. It also states that personally identifiable and financial information must be processed within Qatar and that QCB approval is required before entering a cloud arrangement.

The Central Bank of the UAE’s in-force outsourcing standards make bank board’s responsible for outsourced activities and explicitly address operational, compliance, vendor lock-in, business-continuity and concentration risks. They also require data protection, supervisory access and Central Bank non-objection before outsourcing material arrangements.

Seven controls every bank should document

1. Legal jurisdiction: Which entity contracts for and operates the service?
2. Data and metadata residency: Where are production data, logs, backups and configuration records stored?
3. Operator access: Who can administer the environment, and from which jurisdictions?
4. Encryption-key control: Who generates, stores, authorizes and audits key access?
5. Assurance: Can the bank and regulator obtain sufficient audit evidence?
6. Operational resilience: Can critical functions continue during regional, provider or connectivity disruption?
7. Exit and portability: Can workloads and data be transferred within an acceptable timeframe?

These controls reflect the multi-dimensional approach of the European Commission and the governance, continuity, audit and exit obligations present in QCB and CBUAE frameworks.

AI makes the boundary more complex

With generative AI, institutions must trace more than the location of a database. Prompts, embeddings, model outputs, telemetry, safety logs and fine-tuning data may follow different processing paths. Cloud and AI approval should therefore include a documented end-to-end data-flow assessment.