Data Sovereignty in Analytics: The Complete Guide
Data sovereignty is the principle that data is subject to the laws of the jurisdiction in which it is stored and of the entity that controls it. For analytics, it determines which government can compel access to your users' behavioural data — a question that storage location alone does not answer, because jurisdiction follows the operator as well as the hardware.
This guide covers what sovereignty means as distinct from residency, why the CLOUD Act makes location insufficient, what the sovereign cloud market actually offers, and how to establish sovereignty over an analytics stack.
General guidance, not legal advice. Have counsel assess your specific position. Regulatory and provider details verified as of August 2026 — this area moves quarterly, so re-check before relying on any specific claim.
What is data sovereignty?
Data sovereignty means that data is governed by the legal framework of a particular nation or bloc. Three factors determine which framework applies, and organisations routinely account for only the first.
Where the data is stored. The jurisdiction of the physical infrastructure.
Who operates the infrastructure. A provider incorporated in another country can be subject to that country's legal orders regardless of where the servers sit.
Whose data it is. Some regimes — GDPR most prominently — follow the individual rather than the infrastructure, applying to EU residents' data wherever it is processed.
Sovereignty is the intersection of all three. A dataset can satisfy one and fail the others, which is the situation most organisations are in without knowing it.
Why isn't storing data in Europe enough?
Because of the operator, not the location.
The US CLOUD Act, enacted in March 2018, allows US authorities to compel US-based service providers to produce data in their "possession, custody, or control" — regardless of whether that data sits inside or outside the United States. A US hyperscaler's Frankfurt region is physically in Germany and operationally within reach of a US legal process. That statutory language has not changed since enactment.
This is the core tension. GDPR's Chapter V restricts transfers of personal data outside the EEA; the CLOUD Act asserts extraterritorial reach over data held by US providers. An organisation can be simultaneously compliant with residency requirements and exposed to a foreign jurisdiction.
Where the transfer framework actually stands. The Schrems II judgment in 2020 invalidated Privacy Shield on essentially these grounds. Its successor, the EU–US Data Privacy Framework adopted in 2023, remains valid law — the EU General Court dismissed the Latombe annulment action on 3 September 2025, finding the Data Protection Review Court sufficiently independent and US bulk-collection limits adequate. But it is not settled: Latombe appealed on 31 October 2025 (Case C-703/25 P, pending before the Court of Justice), and noyb has signalled a further challenge. The framework has survived one round at the lower court and faces a second at the EU's highest.
The practical conclusion for analytics is unchanged by that outcome: contractual residency commitments from a US-headquartered vendor address where the data sits, not who can compel it — and an adequacy decision that has been litigated twice is a thinner foundation than an architecture that does not depend on one.
Data sovereignty, residency, and localisation
| Data residency | Data localisation | Data sovereignty | |
|---|---|---|---|
| Concerns | Where data is physically stored | A legal requirement that data stay in-country | Which law governs the data and who can compel access |
| Nature | A choice | A mandate | A consequence |
| Satisfied by | Selecting a region | Storing in-country only | Storing and operating under one jurisdiction |
| Typical failure | Foreign operator retains access | Confusing it with sovereignty | Assuming region selection is sufficient |
The one-line version: residency tells you where the data sleeps; sovereignty tells you who can wake it up.
→ Detailed comparison: Data Residency vs Data Sovereignty vs Data Localisation
What is driving sovereignty requirements now?
Four forces, converging.
Regulatory. DORA's ICT third-party risk obligations became binding on 17 January 2025 across all categories of in-scope EU financial entities: a Register of Information reported annually to competent authorities, concentration-risk assessment, and documented exit strategies. The 2026 supervisory posture is enforcement-oriented rather than remediation-oriented — and EIOPA's 2025 report found 34% of financial entities had not completed a full inventory of their ICT third-party arrangements by the application date, a gap supervisors are actively pursuing.
Geopolitical. Dependence on foreign-controlled infrastructure is increasingly treated as a strategic exposure by European governments rather than a procurement detail. Public-sector and critical-infrastructure procurement has moved fastest.
AI. Organisations training or grounding models on behavioural data need provenance they can demonstrate and rights they can defend. Data under uncertain jurisdiction is data with uncertain rights.
Commercial. Enterprise buyers increasingly pass sovereignty requirements down to their own suppliers. Sovereignty has become a sales qualification criterion, not only a compliance one.
What does the sovereign cloud market actually offer?
Three tiers, with meaningfully different guarantees.
European independent providers. OVHcloud, Scaleway, IONOS, StackIT, Aruba and others. European-incorporated, European-operated, outside CLOUD Act reach. Strongest sovereignty position; smaller service catalogues than hyperscalers.
Hyperscaler sovereign offerings. These stopped being roadmap items during 2026. AWS made its European Sovereign Cloud generally available on 15 January 2026 — an independent cloud located entirely in the EU, physically and logically separate from other AWS Regions, launching with roughly 90 services from a first region in Brandenburg, Germany, with sovereign Local Zones announced for Belgium, the Netherlands and Portugal. Microsoft has expanded Cloud for Sovereignty across private and public cloud alongside dedicated National Partner Clouds in France and Germany, and Google operates sovereign arrangements with local partners.
These introduce operational and legal separation of varying depth. Whether that separation is sufficient remains genuinely contested — commentary at the AWS launch focused precisely on whether an independently operated European entity fully removes US legal jurisdiction. Read the specific corporate architecture rather than the announcement.
On-premises. No cloud provider in the chain. Absolute sovereignty, highest operational cost. Still the only option for air-gapped and certain defence and public-sector requirements.
For analytics specifically there is a fourth route that is often overlooked: self-hosted software in infrastructure you already control. Sovereignty then depends on your own hosting decision rather than on your analytics vendor's corporate structure, which removes the vendor from the sovereignty question entirely.
How do you establish sovereignty over an analytics stack?
Six steps.
1. Map the data flow. Every place behavioural data lands: the analytics platform, the warehouse, backups, CDNs, error tracking, session recording, support tooling, and any ad or marketing destination. The map is always longer than the architecture diagram.
2. Identify the operator of each. For every destination, the operating entity's country of incorporation and ultimate parent. This is the step that produces the surprises.
3. Determine your actual requirement. Residency? Localisation? Full sovereignty? Which regulation or contract imposes it, in what words? Requirements are frequently over-stated internally and occasionally under-stated.
4. Assess the gap. Which flows fail the requirement, and by how much.
5. Choose a remediation route. Move to a sovereign provider, move on-premises, or self-host the software in infrastructure you already control.
6. Document it. Sovereignty you cannot evidence does not survive an audit. Keep the data-flow map, the operator assessment, and the deployment evidence current.
Step 1 is where most of the value is. Organisations consistently discover behavioural data flowing to destinations nobody had inventoried — which is the same finding EIOPA reported at supervisory scale.
Frequently asked questions
What is the difference between data sovereignty and data residency? Residency is where data is physically stored. Sovereignty is which legal jurisdiction governs it and who can compel access — determined by storage location, the operator's jurisdiction, and the data subject's jurisdiction together.
Is the EU–US Data Privacy Framework still valid? Yes, as of August 2026. The EU General Court dismissed the Latombe annulment action on 3 September 2025 and the 2023 adequacy decision stands. An appeal is pending before the Court of Justice (Case C-703/25 P) and a further challenge has been signalled, so it should be treated as valid but contested.
Does storing data in the EU guarantee GDPR compliance? No. It addresses the transfer restrictions in Chapter V but not lawful basis, minimisation, retention, or subject rights. It also does not by itself resolve exposure where the operator is subject to a foreign legal regime.
What is the CLOUD Act and why does it matter for European organisations? It is US legislation from 2018 permitting US authorities to compel US-based providers to produce data in their possession, custody, or control, regardless of storage location. For European organisations it means that using a US-headquartered provider's European region does not fully remove exposure to US legal process.
Is a sovereign cloud from a US hyperscaler genuinely sovereign? It depends on the specific legal and operational structure, and the question is actively contested. Some arrangements place operations under a locally incorporated, locally controlled entity; others provide technical controls without changing corporate control. Read the architecture rather than the label.
Does self-hosting give you data sovereignty? It gives you control over where the software runs and removes the vendor from the access question. Sovereignty then depends on your own hosting choice — self-hosting in a US hyperscaler's European region resolves vendor access but not operator jurisdiction.
Which regulations require data sovereignty? Few require it by that name. GDPR restricts transfers; DORA requires third-party ICT risk management and exit strategies; sectoral rules in finance, health, and the public sector impose localisation in specific jurisdictions. Sovereignty is usually the practical means of satisfying several overlapping obligations at once.
Where to go next
- Definitions: Data Residency vs Data Sovereignty vs Data Localisation
- Europe: Cloud Sovereignty in Europe
- Migration: EU Data Repatriation
- Governance: Data Governance for Product Analytics
Countly is a first-party product analytics and customer engagement platform that runs self-hosted, on-premises, or in a private cloud.
Posts that our readers love
to grow your product
is here.