“EU data residency” and “data sovereignty” are sold as if they were the same product. They are not. Conflating them leads procurement teams to accept residency claims as if they answered the sovereignty question, which they do not. This guide separates the two, explains what each is actually worth in a procurement assessment, and outlines when you need one, the other, or both.
The plain definitions
Data residency is a physical statement: the personal data is stored, and possibly processed, on infrastructure located within a defined geographic region. EU data residency means the data is on servers physically located in the EU/EEA.
Data sovereignty is a legal statement: the personal data is subject only to the laws of a defined jurisdiction. EU data sovereignty means the data is subject only to EU/EEA legal authority — no third-country government can compel its disclosure through a legal process recognised by the processor.
The two are correlated. EU-only data centres make EU sovereignty easier to achieve. But residency is necessary, not sufficient. A US-controlled vendor with EU-only data centres can be compelled to produce that data under the US CLOUD Act, regardless of the physical server location. The data is resident in the EU but not sovereign to the EU.
What residency actually protects against
Residency answers a narrow but real set of concerns.
It protects against latency-driven processing problems: data does not have to travel transatlantic for routine reads and writes, which improves application performance and reduces accidental aggregation in a third country.
It protects against certain sectoral compliance requirements that specify physical location, such as some French health data hosting rules (HDS), certain German public-sector procurement rules, and several other Member State sectoral regimes.
It supports — but does not guarantee — GDPR Chapter V transfer compliance. If all production data and all sub-processor processing happens within the EU, there is no Chapter V transfer to assess. This is meaningful, because Chapter V is one of the most heavily documented compliance areas.
It signals vendor maturity. A vendor that offers genuine EU-only data residency has built operational infrastructure to support it — separate environments, deployment automation, data isolation. That investment is a positive signal about the vendor’s overall data protection posture.
It supports customer-facing statements. “Your data stays in the EU” is a marketing claim that customers value, and being able to make it truthfully has commercial value.
What residency does not protect against is third-country government access via the vendor’s corporate parent or controlling entity. If the legal entity that operates the residency-compliant infrastructure is itself subject to extraterritorial legal compulsion — most notably the US CLOUD Act, but also similar provisions in Chinese, Russian, and several other regimes — the residency promise can be defeated by legal process.
What sovereignty actually protects against
Sovereignty is the harder property. It requires that the controlling legal entity is itself subject only to the desired jurisdiction’s legal authority. For EU sovereignty, the operating entity must be incorporated in the EU/EEA, controlled by EU/EEA entities, and not subject to extraterritorial legal compulsion from third countries.
True sovereignty is rare among large SaaS vendors because of how global SaaS companies are structured. Many vendors that advertise European operations are subsidiaries of US, UK, or Asian parent companies. The subsidiary may be EU-incorporated, but the parent’s legal exposure can reach down into the subsidiary’s data if the parent has effective control.
The architectures that come closest to genuine sovereignty are:
Single-entity EU vendors. Companies whose entire corporate group is EU-incorporated and EU-owned. Examples in the EU Stacks directory include Hetzner (Germany), Scaleway (France), Infomaniak (Switzerland for sovereignty-equivalent purposes), Mailbox.org and Tuta (Germany), and several others. These vendors have no third-country parent that could compel disclosure.
Vendor-side cryptographic isolation. Systems where the vendor mathematically cannot access customer data in plaintext — true end-to-end encryption with customer-held keys. Proton Mail, Tuta, Tresorit, and CryptPad fit this pattern for parts of their offering. The vendor’s legal jurisdiction matters less if the vendor genuinely cannot produce the plaintext.
Sovereign cloud overlays. Frameworks like the French SecNumCloud certification (issued by ANSSI) impose ownership, governance, and operational requirements that effectively immunise the certified service from extraterritorial reach. The EU’s forthcoming EUCS scheme is the broader European version. These are still maturing in 2026 — the high-assurance tier of EUCS in particular has been the subject of significant industry debate.
When you need residency, sovereignty, or both
Procurement teams should distinguish the two clearly when scoping requirements.
Residency is sufficient when: the personal data is low-sensitivity, the vendor has demonstrated strong access controls and audit logging, the sectoral rules apply only to physical location, and the buyer’s TIA accepts the residual risk of third-country government access for the specific data category in question.
Sovereignty is required when: the personal data is special category under GDPR Art. 9 (health, biometrics, political views, etc.); the sectoral rules explicitly require it (some French health data scenarios, German public-sector tenders for sensitive applications); the buyer’s organisation is itself a public-sector body subject to national sovereign cloud rules; the data is subject to attorney-client privilege, professional secrecy, or similar; or the buyer is operating in a sector with elevated geopolitical risk where third-country government access is a real threat.
For most commercial SaaS use cases, residency is the operational floor and sovereignty is a strong preference rather than a strict requirement. For sensitive use cases, sovereignty becomes a hard requirement and residency is just one input.
How to verify each in a vendor evaluation
Verifying residency is relatively easy. Ask for the specific data centres and cloud regions used. Confirm that the contract binds the vendor to maintaining that residency. Check the sub-processor list for any sub-processor that would receive personal data outside the residency region. Confirm the absence of cross-region replication outside the residency boundary.
Verifying sovereignty is harder. Look at the corporate structure — the legal entity processing the data, its corporate parents up to ultimate beneficial ownership, and the legal jurisdictions of each. Look at the published transparency reports for evidence of how the vendor has handled past government access requests. Look at the encryption architecture — whether the vendor’s operational access to customer data is genuinely impossible or merely policy-restricted. Look at certifications that specifically address sovereignty, such as SecNumCloud or the BSI C5 cloud-security framework’s stronger control areas.
For both, document the answers in the procurement record. A defensible position is one where you have asked the questions, recorded the answers, and made an informed decision. An indefensible position is one where you accepted “EU data residency” on a marketing page as the answer to a sovereignty question.
A note on the EU sovereign cloud landscape
The European cloud sovereignty conversation has shifted substantially since 2022. Several distinct initiatives now overlap in the market.
The EU Cybersecurity Certification Scheme for Cloud Services (EUCS), being developed under the Cybersecurity Act, will eventually provide a unified European certification framework. The exact requirements for its highest assurance tier — particularly around ownership and headquarters — have been the subject of significant industry debate.
National schemes — France’s SecNumCloud, Germany’s BSI C5 framework — continue to evolve. SecNumCloud’s 3.2 revision in particular has produced a small but growing list of certified providers including some larger French cloud companies.
Hyperscaler sovereign overlays — Microsoft’s EU Data Boundary, AWS European Sovereign Cloud, Google’s Sovereign Controls offerings — are positioned as residency-plus-controls bundles. They are credible residency improvements but do not, on their own, defeat the underlying CLOUD Act exposure of the parent company. They are useful tools in some procurement contexts; they are not equivalent to genuine EU-sovereign vendors.
Native European hyperscaler alternatives — OVHcloud, Scaleway, IONOS, Hetzner — offer genuine EU sovereignty at the infrastructure layer. The trade-off versus the hyperscalers is typically in service breadth and ecosystem integration rather than in compliance posture.
What to write in the procurement record
When you finish a vendor evaluation, write down the answers to four questions. Where, physically, is the data stored? Which legal entities control that storage and the related processing operations? What is the legal jurisdiction of those entities? What is the residual third-country exposure, and have you accepted it for the data category in question?
A procurement record that answers these four questions explicitly is defensible. A procurement record that conflates residency and sovereignty is not. The single most common cause of post-hoc compliance trouble is treating “EU data residency” as if it answered both questions.
The EU Stacks directory tries to make this comparison straightforward at the vendor level. Each profile records headquarters country, server regions, US ownership status, CLOUD Act exposure classification, and Schrems II risk level. Those are the data points that turn a marketing claim into a verifiable position.