Data Sovereignty: What It Means, Why It Matters, and How European Companies Achieve It
A practical guide to data sovereignty — what it is, how it differs from data residency and data localisation, why EU regulations demand it, and how European companies ensure sovereign control over their data.
Data Sovereignty: What It Means, Why It Matters, and How European Companies Achieve It
Data sovereignty is the principle that data is subject to the laws and governance structures of the jurisdiction where it is collected or stored. For European companies, this means ensuring that data remains under EU legal authority — not just physically located in Europe, but legally protected from foreign government access and governed by European regulations.
The concept has moved from a theoretical concern to a practical business requirement. Enterprise buyers in Europe now routinely ask vendors about data sovereignty as part of procurement. Regulations like GDPR, NIS2, and DORA create legal obligations around jurisdictional control. And high-profile legal cases — most notably the Schrems decisions — have demonstrated that physical location alone does not guarantee legal protection.
This guide covers what data sovereignty means in practice, how it differs from related concepts, why it matters for European businesses, and how to achieve it.
Data Sovereignty vs. Data Residency vs. Data Localisation
These three terms are often confused. They represent different levels of data control:
Data Residency
Data residency means data is stored in a specific geographic location. A company might require "EU data residency," meaning all data must be stored in data centres physically located within the European Union.
What it guarantees: Physical location of data storage.
What it does not guarantee: Legal protection from foreign jurisdiction. A US cloud provider operating an EU data centre still stores data in the EU, but remains subject to US law.
Data Localisation
Data localisation requires data to remain within specific national borders. Some countries mandate that certain types of data (e.g., financial records, health data, government data) cannot leave the country under any circumstances.
What it guarantees: Data never crosses national borders.
What it does not guarantee: Practical for most businesses. Strict localisation can limit cloud provider options and increase costs significantly.
Data Sovereignty
Data sovereignty ensures data is subject to the legal framework of a specific jurisdiction. It is the most comprehensive concept, encompassing both physical location and legal control.
What it guarantees: Jurisdictional authority over data, legal protection, and governance control.
What it requires: Choosing providers, infrastructure, and legal arrangements that ensure no foreign government can compel data access without following the governing jurisdiction's legal process.
| Aspect | Data Residency | Data Localisation | Data Sovereignty |
|---|---|---|---|
| Focus | Where data is stored | Preventing cross-border transfers | Legal jurisdiction over data |
| Scope | Geographic | National | Legal and jurisdictional |
| Provider restriction | Must have local data centres | Must store locally, no transfers | Must be subject to local law |
| Practical impact | Moderate | High (limits options) | Highest (requires legal analysis) |
| Common requirement | GDPR, industry standards | Specific national laws | Enterprise buyers, regulated sectors |
Why Data Sovereignty Matters
The CLOUD Act Problem
The US Clarifying Lawful Overseas Use of Data (CLOUD) Act, enacted in 2018, allows US law enforcement to compel US-headquartered companies to provide data stored on their servers, regardless of where that data is physically located. This applies to:
- AWS, Azure, Google Cloud — even when operating EU data centres
- US-headquartered SaaS providers processing EU data
- Any company incorporated in the US or with substantial US operations
For European companies storing sensitive data with US providers, this creates a fundamental tension: GDPR restricts data access by foreign governments, but the CLOUD Act may compel it.
The Schrems Legacy
The Schrems I (2015) and Schrems II (2020) decisions by the Court of Justice of the European Union (CJEU) invalidated successive EU-US data transfer frameworks — first Safe Harbor, then Privacy Shield — on the grounds that US surveillance laws did not provide adequate protection for EU personal data.
While the EU-US Data Privacy Framework (2023) provides a current legal basis for transfers, the underlying tension remains: US surveillance capabilities and legal authorities have not fundamentally changed.
Regulatory Requirements
European regulations increasingly require sovereignty considerations:
- GDPR (Articles 44-49): Restricts international data transfers and requires adequate safeguards
- NIS2 (Article 21(2)(d)): Supply chain security must consider jurisdictional risks
- DORA (Articles 28-44): ICT third-party risk management includes concentration risk and jurisdictional assessment
- National laws: Some EU member states have additional sovereignty requirements for specific sectors (e.g., health data in France, financial data in Germany)
Enterprise Buyer Requirements
European enterprise buyers increasingly evaluate data sovereignty as part of vendor assessment:
- Where is data stored and processed?
- What legal jurisdiction governs the cloud provider?
- Can foreign governments compel data access?
- Who controls encryption keys?
- What sub-processors are used and where are they incorporated?
These questions appear in security questionnaires, vendor risk assessments, and procurement requirements across industries.
Achieving Data Sovereignty in Practice
Infrastructure Choices
European sovereign cloud providers: OVHcloud, IONOS, Hetzner, Scaleway, Open Telekom Cloud, and others are incorporated in the EU and subject only to EU law.
US hyperscaler sovereign offerings: AWS European Sovereign Cloud, Google Sovereign Cloud, and Microsoft Cloud for Sovereignty provide operational separation within EU borders, EU-resident staff, and local key management — but the underlying corporate entity remains subject to US law.
Hybrid approaches: Use EU sovereign providers for sensitive data while leveraging hyperscalers for less sensitive workloads where their advanced services provide significant value.
Encryption and Key Management
Encryption is a critical sovereignty control:
- Customer-managed keys (CMK): The customer controls encryption keys, meaning even the cloud provider cannot access data
- Bring Your Own Key (BYOK): Customer generates and manages the master key used to encrypt data keys
- External Key Management (EKM): Keys are stored and managed in a customer-controlled HSM outside the cloud provider's infrastructure
- Confidential computing: Data is encrypted even during processing, using hardware-based trusted execution environments
When the customer controls encryption keys and the cloud provider cannot access data in plaintext, foreign legal compulsion becomes technically unenforceable — the provider cannot provide what it cannot access.
Legal and Contractual Measures
- Data Processing Agreements (DPAs): Include sovereignty clauses specifying governing law and jurisdictional limitations
- Standard Contractual Clauses (SCCs): Use EU-approved SCCs for any transfers outside the EU
- Transfer Impact Assessments (TIAs): Document the legal landscape of destination countries and supplementary measures
- Binding Corporate Rules (BCRs): For multinational organisations transferring data within the corporate group
- Sovereignty addenda: Additional contractual commitments from cloud providers regarding data access limitations
Organisational Measures
- Data classification: Identify which data requires sovereign treatment based on sensitivity, regulatory requirements, and business risk
- Sub-processor governance: Evaluate the jurisdictional exposure of all sub-processors in the supply chain
- Incident response: Ensure incident notification follows the governing jurisdiction's requirements (e.g., GDPR Article 33, NIS2 Article 23)
- Regular review: Sovereignty requirements evolve with legislation and case law — review arrangements annually
GAIA-X and European Cloud Standards
GAIA-X is a European initiative to create a federated, sovereign data infrastructure. Key elements:
GAIA-X Labels
GAIA-X defines trust levels through labelling:
- GAIA-X Standard: Basic compliance with transparency and interoperability requirements
- European Data Protection: Meets GDPR requirements with EU data processing
- Sovereign Data Exchange: Full sovereignty guarantees including jurisdiction, transparency, and portability
GAIA-X Principles
- Transparency: Clear disclosure of data processing locations, sub-processors, and applicable laws
- Data portability: Ability to move data between providers without lock-in
- Interoperability: Standards-based interfaces enabling multi-cloud architectures
- Self-sovereignty: Organisations retain control over their data and the rules governing its use
- Federation: Distributed infrastructure avoiding single points of control
Practical Impact
GAIA-X certification is becoming a differentiator for European cloud providers and SaaS companies. Enterprise buyers — particularly in regulated sectors — increasingly reference GAIA-X standards in procurement requirements.
Data Sovereignty by Regulation
GDPR
| Requirement | Sovereignty Implication |
|---|---|
| Article 44: Transfers subject to Chapter V | Must assess legal framework of destination country |
| Article 45: Adequacy decisions | Only transfer freely to countries with adequate protection |
| Article 46: Appropriate safeguards | SCCs, BCRs required for non-adequate countries |
| Article 49: Derogations | Limited exceptions for necessary transfers |
| Schrems II: TIA requirement | Must assess surveillance laws of destination country |
NIS2
| Requirement | Sovereignty Implication |
|---|---|
| Article 21(2)(d): Supply chain security | Evaluate jurisdictional risks of ICT providers |
| Article 21(2)(j): Cryptography policies | Encryption key management must ensure sovereignty |
| Article 23: Incident notification | Reporting obligations follow EU jurisdiction |
DORA
| Requirement | Sovereignty Implication |
|---|---|
| Article 28: ICT third-party risk policy | Must assess concentration and jurisdictional risk |
| Article 30: Key contractual provisions | Contracts must address data location and protection |
| Article 31: Sub-outsourcing conditions | Sovereignty requirements cascade through supply chain |
Common Data Sovereignty Mistakes
Confusing Location with Sovereignty
Storing data in an EU data centre operated by a US provider does not automatically achieve data sovereignty. The provider's corporate jurisdiction matters as much as the data centre location.
Ignoring Sub-Processors
Your primary cloud provider may be EU-sovereign, but if they use sub-processors subject to foreign law, your sovereignty chain is broken. Evaluate the entire supply chain.
Relying Solely on Contracts
Contractual commitments from providers are important but may not withstand foreign government legal orders. Technical measures (encryption, key management) provide stronger sovereignty guarantees than contracts alone.
Over-Engineering Sovereignty
Not all data requires sovereign treatment. Classify data by sensitivity and apply sovereignty controls proportionally. Marketing analytics data does not need the same sovereignty treatment as patient health records.
Assuming Permanent Adequacy
Adequacy decisions can be invalidated (as Schrems demonstrated). Design sovereignty architectures that are resilient to changes in the legal landscape, not dependent on specific adequacy decisions.
How Orbiq Supports Data Sovereignty
- Trust Center: Publish your data sovereignty posture — data residency, encryption, key management, and provider jurisdictions — so buyers can self-serve their due diligence
- Continuous Monitoring: Track sovereignty-relevant controls across ISO 27001, GDPR, NIS2, and DORA requirements
- Evidence Management: Centralize Transfer Impact Assessments, sub-processor documentation, and sovereignty certifications
- AI-Powered Questionnaires: Auto-respond to sovereignty-related security questionnaire questions from your documented controls
Further Reading
- Trust Center — How to publish your sovereignty posture for buyer due diligence
- Vendor Risk Assessment — How buyers evaluate sovereignty in vendor selection
- Third-Party Risk Management — Managing sovereignty risks across your supply chain
- ISMS — The management system that governs sovereignty controls
This guide is maintained by the Orbiq team. Last updated: March 2026.