Data sovereignty vs data residency has become a procurement question, and not only a legal one. Data residency tells a bank where its data is stored. Data sovereignty tells it whose law governs that data and who can act on it.

The gap became public on 10 June 2025. Under oath before a French Senate inquiry into public procurement, Microsoft France’s director of public and legal affairs was asked whether he could guarantee that French citizens’ data would never be passed to US authorities without French authorization. He said he could not guarantee it and added that this had never happened.^[1]

That answer does not make EU data residency worthless. It shows that residency settles one question — location — while a regulated bank needs answers to several more. This article sets out which legal and operational risks can remain when data stays in the EU, and what to verify with a cloud provider before signing.

Data Sovereignty vs Data Residency: What Is the Difference?

Data residency is a commitment about where data is stored and processed. Data sovereignty is the degree to which data stays under the law and control of a chosen jurisdiction. Data localization is a third concept: a legal requirement, set by a legislator or regulator, that certain data must stay within a country.

An EU data residency commitment is usually defined service by service. The service terms state which data categories stay in which regions, whether processing is covered as well as storage, and which exceptions apply. The wording of that commitment matters as much as the region’s name. For what typically stays in the EU when a bank selects an EU region with a hyperscaler, see EU Cloud Region for Banks: What Actually Stays in Europe in 2026.

Which Legal Risks Remain When Data Stays in the EU?

Three legal risks can remain after data is placed in an EU region: jurisdiction over the entities that hold or control the data, demands from foreign authorities, and conflicts between those demands and EU law.

Server location alone does not determine legal exposure

The US CLOUD Act, enacted in 2018, requires providers of electronic communication or remote computing services to preserve or disclose data within their possession, custody, or control, regardless of whether it is located inside or outside the United States.^[2] According to the US Department of Justice, the obligation applies to providers subject to US jurisdiction, which is not limited to US-headquartered or US-owned companies. Whether a court has jurisdiction over an entity, and whether a parent controls data held by a subsidiary, are fact-dependent questions.^[3]

Legal exposure therefore turns on two things: which entity holds or controls the data, and which jurisdictions can reach that entity. Neither the server’s location nor the corporate structure settles this on its own.

This is not only a question about US-headquartered providers, and it should not be overstated. OVHcloud’s US subsidiary, OVH US, states that it will comply with lawful requests from public authorities, which under the CLOUD Act could include data stored outside the United States.^[4] The OVHcloud group states that the entities serving its European customers fall under the exclusive jurisdiction of EU member states or of states covered by a European Commission adequacy decision, and that it is able to oppose non-EU requests not made under an international agreement.^[5]

Other jurisdictions can test the same structure. A Canadian production order of April 2024 required OVHcloud’s French parent and its Canadian subsidiary to produce subscriber and account data linked to servers outside Canada; in 2025, an Ontario court upheld the order, and the police sought the data directly rather than through a mutual legal assistance treaty.^[6] In a statement of 31 July 2026, OVHcloud said Canadian authorities had threatened to file charges against both entities and that it intends to contest them.^[7]

In practice, a bank should ask for a map of the entities that can access customer data, the jurisdictions each is subject to, and written commitments on how the provider challenges requests and notifies customers.

Foreign authority demands take more than one form

Law-enforcement orders under the CLOUD Act are one channel. Foreign-intelligence collection is another: under Section 702 of the US Foreign Intelligence Surveillance Act (FISA), providers are served with directives and can face substantial court-imposed penalties for failing to comply with a valid directive.^[8] In June 2026, the statutory authorisation lapsed without re-authorisation.^[9] At that time, the Brennan Center reported that certifications approved by the FISA Court in March 2026 keep the surveillance authority in force until March 2027.^[8]

For personal data sent to certified US organisations, the EU-US Data Privacy Framework provides a transfer basis. The EU General Court upheld it in September 2025, assessing it as it stood when adopted in 2023.^[10] The judgment was appealed to the Court of Justice on 31 October 2025 as Case C-703/25 P.^[11][12]

Before signing, a bank should identify every service component that sends data to a non-EU entity — including support and telemetry — and the legal basis the provider relies on for each.

EU law can conflict with those demands

EU law limits how providers may respond. Under Article 48 GDPR, a third-country court judgment or administrative decision requiring disclosure of personal data can be recognised or enforced only if it is based on an international agreement, such as a mutual legal assistance treaty; other transfer grounds under Chapter V remain available.^[13] Article 32 of the EU Data Act requires cloud providers to take technical, organisational and legal measures against third-country governmental access to non-personal data held in the EU where that access would conflict with EU or national law.^[14]

A provider exposed to both US and EU obligations can therefore face a genuine conflict of laws. The practical questions for a buyer are how the provider resolves such a conflict, which Article 32 measures apply to the specific service, and how quickly the bank is informed.

What Determines Operational Control?

Operational control is the ability of the bank, or of a provider operating under its chosen jurisdiction, to decide who can administer, change, suspend and exit the service. It depends on six factors:

Service continuity is the least visible factor until it is tested. According to ICC staffers interviewed by the Associated Press, Microsoft cancelled the email address of the International Criminal Court’s chief prosecutor after US sanctions in 2025.^[16] Microsoft says it stayed in contact with the ICC throughout the process that led to the disconnection and never ceased or suspended its services to the court. A Dutch press report said Microsoft had told the ICC to end the prosecutor’s access; Microsoft has not commented further on that report. The ICC later decided to adopt openDesk, an open-source suite from Germany’s Centre for Digital Sovereignty.^[17]

Providers have responded with contractual and architectural commitments. Microsoft announced a European Digital Resilience Commitment in April 2025, which it said would be included in its contracts with European national governments and the European Commission.^[17] AWS states that its European Sovereign Cloud, generally available since January 2026, is operated exclusively by EU residents and lets customers keep the metadata they create — such as roles, permissions, resource labels and configurations — in the EU, including in its identity, billing and usage-metering systems.^[18] For a bank, such commitments carry weight when their scope is verifiable: which customers and services they cover, whether they are in the contract, and what audit evidence supports them.

What Should a Bank Verify Beyond Data Centre Location?

A bank should verify the legal, operational and exit assumptions behind a cloud service, not only its region. The Digital Operational Resilience Act (DORA) sets the binding baseline.

DORA, applicable since 17 January 2025, keeps financial entities fully responsible for compliance when they use ICT third-party providers.^[19] Contracts must state the regions or countries where services are provided and data is processed and stored, and require advance notice of location changes. For ICT services supporting critical or important functions, contracts must also include audit rights and exit strategies with a mandatory transition period.^[19] In November 2025, the European Supervisory Authorities designated 19 critical ICT third-party providers, including AWS, Google Cloud and Microsoft, for direct EU oversight.^[20][21] That oversight does not transfer the bank’s own accountability. For a provider-evidence checklist, see DORA cloud provider requirements for banks.

Beyond the DORA minimum, the evidence that separates providers usually falls into five checks:

These checks change which service a bank buys, not only what the contract says. Our recommendation — not a regulatory requirement — is to tier workloads. Low-sensitivity workloads can run in a standard EU region with a clear residency commitment. Sensitive data warrants customer-managed keys with restrictive key permissions, and restricted, logged privileged access. Critical or important functions, where foreign legal exposure or a service suspension is unacceptable, call for an EU-controlled operating model with verified continuity and exit arrangements. For how partnership models shape these negotiations, see Cloud Partner vs. Vendor.

Public sovereignty frameworks can help structure this assessment, but they are not rules for banks. The European Commission’s Cloud Sovereignty Framework, published in October 2025, scores providers from SEAL-0 to SEAL-4 against eight objectives.^[22] The Commission uses it in its own procurement: in April 2026 it awarded four contracts to providers and consortia, under which EU institutions and bodies can procure sovereign cloud services for up to €180 million over six years, with SEAL-2 as the minimum level.^[23] The proposed Cloud and AI Development Act (CADA), published on 3 June 2026, would define four assurance levels for public sector bodies, from EU-located infrastructure at Level 1 to full software supply-chain control with no third-country interference at Level 4.^[24] CADA is still a legislative proposal, and neither scale is a mandatory standard for banks.

Is EU Data Residency Still Worth Paying For?

Yes. EU data residency is a sensible baseline for European banks. It reduces routine transfers outside the EU and supports DORA location clauses, and it can reduce latency when users and connected systems are also in Europe and the architecture avoids cross-region calls. It is not, on its own, a complete answer to jurisdiction or control.

The counter-case deserves weight: not every workload needs the highest level of control. Control requirements should follow the risk of the specific workload and be weighed against the functionality, cost and dependencies of the service that delivers them. A higher assurance level that removes a needed service or adds a new dependency is not automatically the safer choice.

What Are the Common Pitfalls in Sovereign Cloud Procurement?

The most common pitfall is accepting a “sovereign” label without checking which layer of control it covers.

Treating location as control. A region in the EU does not show which entities hold or control the data, or which authorities can reach them. Ask for the entity map and the request-handling policy.

Treating encryption as exclusivity. Encryption limits access only as far as key permissions and architecture do. Check which principals and services can use the keys and where data is decrypted for processing.

Overlooking metadata and support. Logs, identity data and support sessions often sit outside residency commitments. Ask for the exceptions in writing.

Relying on unverified commitments. Vendor sovereignty statements vary in scope. Check which contracts and services they cover and what audit evidence supports them.

What Should Banks Watch Before Their Next Cloud Contract?

Several dated developments can change the terms of a cloud decision. From 12 January 2027, the EU Data Act prohibits switching charges, which lowers the cost of exit.^[25] The Section 702 certifications approved in March 2026 were reported to run until March 2027.^[8] The outcome of the appeal in Case C-703/25 P could affect the validity of the Data Privacy Framework adequacy decision.^[11] Negotiations on CADA will show whether its assurance levels become law. For the wider market context, see EU Cloud Sovereignty: Why Businesses Are Moving Away from US Providers.

How Does ASEE Approach Data Sovereignty in Banking?

ASEE treats sovereignty as an architecture decision made per workload, not a hosting location chosen once. ASEE Cloud operates entirely within EU jurisdiction, which removes the extraterritorial exposure that residency clauses alone cannot resolve.

Our clients span 55+ countries, and across South-Eastern Europe, EU and non-EU regulatory regimes sit side by side. A card issuer in an EU member state and one in a neighbouring candidate country face different localisation rules, supervisors, and exit expectations. Designing for both has taught us that the control plane, key custody, and support model matter as much as the data centre address.

Having processed over 3 billion transactions a year across 20 monetary systems, we understand the operational requirements of regulated workloads at implementation level, not just in theory. That is why, in environments such as PCI DSS-certified managed cloud, we define key custody, logging, and privileged access per workload before migration begins.

Key Takeaways

1. Data sovereignty vs data residency is a question of jurisdiction and control: legal exposure depends on which entities hold or control the data and which authorities can reach them, not on server location alone.
2. EU data residency is a sensible baseline, but its scope depends on the service terms, including whether processing is covered and what exceptions apply to metadata, logs and support data.
3. Operational control rests on administrative access, key management, support, updates, continuity and exit, and each needs evidence rather than a label.
4. DORA keeps the bank accountable for ICT third-party risk; SEAL and the proposed CADA levels are useful vocabulary, not bank mandates.

Frequently Asked Questions

What is a sovereign cloud?

A sovereign cloud is a cloud service designed to keep data, operations and legal control under one jurisdiction, typically the EU. Providers use the term for very different levels of control, so buyers should ask which specific controls a service includes.

Does DORA require banks to use a sovereign cloud?

No. DORA does not prescribe any particular type of cloud. It sets requirements for ICT risk management, contracts and exit, and leaves the choice of provider to the bank’s own risk assessment.

Does the CLOUD Act require providers to decrypt customer data?

No. The US Department of Justice describes the CLOUD Act as encryption-neutral: it creates no new authority to compel providers to decrypt data, and it does not prevent them from assisting. Whether a provider can hand over readable data depends on who can use the keys and where data is decrypted.

Is sovereign cloud more expensive than standard public cloud?

It can be. Higher assurance levels may cost more or offer fewer services, but the difference depends on the workload and the offer, so it is best compared workload by workload.

References

[1] Sénat — Commission d’enquête sur la commande publique, audition of Microsoft France (10 June 2025)

[2] 18 U.S.C. § 2713 — Required preservation and disclosure of communications and records (CLOUD Act)

[3] US Department of Justice — CLOUD Act FAQ, questions 24–25 and 29

[4] OVH US — CLOUD Act FAQ

[5] OVHcloud — OVHcloud and data sovereignty

[6] heise online — Canadian Court: OVHcloud from France must hand over user data (2025)

[7] OVHcloud — OVHcloud Confirms Intent to Vigorously Contest Charges Related to Canadian Production Order (31 July 2026)

[8] Brennan Center for Justice — Section 702 of FISA, Explained (June 2026)

[9] Electronic Frontier Foundation — Section 702 has expired (June 2026)

[10] IAPP — European General Court dismisses Latombe challenge, upholds EU-US Data Privacy Framework (Case T-553/23)

[11] Court of Justice of the EU — Case C-703/25 P, case file

[12] EUR-Lex — Case C-703/25 P: Appeal brought on 31 October 2025 by Philippe Latombe (OJ C, C/2025/6610, 22.12.2025)

[13] EUR-Lex — Regulation (EU) 2016/679 (GDPR), Article 48

[14] EUR-Lex — Regulation (EU) 2023/2854 (Data Act), Articles 29 and 32

[15] AWS — Default key policy, AWS Key Management Service Developer Guide

[16] Associated Press — Cut off by their banks and even iced out by Alexa, sanctioned ICC staffers remain resolute

[17] The Register — Microsoft asks UK Parliament to correct record on ICC email (February 2026)

[18] Amazon — AWS Launches AWS European Sovereign Cloud (15 January 2026)

[19] EUR-Lex — Regulation (EU) 2022/2554 (DORA), Articles 28, 30 and 64

[20] European Banking Authority — ESAs designate critical ICT third-party providers under DORA (18 November 2025)

[21] TLT LLP — EU regulators designate critical ICT third-party providers under DORA

[22] European Commission — Sovereign Cloud Framework explained (June 2026)

[23] European Commission — Commission advances cloud sovereignty through strategic procurement (17 April 2026)

[24] European Commission — Cloud and AI Development Act (June 2026)

[25] Alston & Bird — EU Data Act Switching Requirements for Cloud Services (September 2025)