Table of Contents
- What data sovereignty actually means
- Data sovereignty vs data residency vs data localization
- The legal threat landscape: CLOUD Act, FISA 702, and GDPR
- Why jurisdiction matters more than server location
- How to achieve data sovereignty: technical and organizational controls
- Data sovereignty for individuals
- Data sovereignty for organizations
- FAQ
What data sovereignty actually means
Data sovereignty is deceptively simple to state and surprisingly hard to achieve. The core principle: data is subject to the laws and governance frameworks of the nation where the controlling entity is located. Not where the servers are. Not where the data was created. Where the organization that controls it is incorporated and operates.
This distinction has enormous practical consequences. A US company storing data on servers in Amsterdam is still a US company. The US government can compel it to produce that data under US law — specifically, under the CLOUD Act, a 2018 statute that explicitly extended US legal reach to data held abroad by US-based providers. The Amsterdam datacenter is irrelevant to this calculation.
True data sovereignty means three things are aligned:
1. Legal jurisdiction. The organization holding your data is incorporated in a country with strong domestic privacy protections and no extraterritorial data access agreements with the jurisdiction you are trying to avoid.
2. Physical control. The servers are operated by that organization, not subcontracted to a US or Chinese cloud provider (AWS, Azure, Google Cloud, Alibaba Cloud) that can be independently served with a legal order.
3. Cryptographic architecture. The organization cannot read your data even if ordered to produce it, because end-to-end encryption means they hold only ciphertext, not keys.
Most "sovereign" cloud solutions satisfy one or two of these, rarely all three.
Data sovereignty vs data residency vs data localization
These three terms are frequently conflated, including in enterprise procurement contexts. They are distinct:
Data residency refers to the physical location of data storage. An organization with a data residency policy keeps EU customer data on EU-based servers. This is primarily a compliance posture — it satisfies GDPR requirements around data transfer outside the EU and gives organizations contractual certainty about where their data sits. It does not change which legal entity controls that data or what legal system governs it.
Data localization is the regulatory mandate version. Countries like Russia (Federal Law 242-FZ), China (PIPL, Data Security Law), and India (DPDP Act 2023) require that certain categories of data about their citizens be stored and processed within national borders. This is governments imposing data residency on companies, rather than companies voluntarily adopting it. Localization requirements create compliance obligations for any organization handling data from these jurisdictions.
Data sovereignty is the governance layer above both. It asks: who ultimately controls this data legally? Which court system can compel access? Which privacy law protects it? A company can satisfy data residency requirements (all servers in Germany) and still have no data sovereignty if the controlling entity is a US parent company subject to FISA 702 or CLOUD Act orders.
The practical implication for organizations: data residency is necessary but not sufficient for data sovereignty. Choosing a cloud provider headquartered in a favorable jurisdiction is at least as important as the location of its datacenters.
The legal threat landscape
Understanding data sovereignty requires understanding the specific legal instruments that undermine it.
CLOUD Act (US, 2018). The Clarifying Lawful Overseas Use of Data Act allows US law enforcement to issue warrants for data held abroad by US-based providers, without going through Mutual Legal Assistance Treaty (MLAT) procedures. The MLAT process was slow and gave host countries an opportunity to object; the CLOUD Act bypasses it. Any US-headquartered cloud provider — AWS, Microsoft Azure, Google Cloud, Salesforce, Dropbox — can be compelled to produce data held on European servers without notifying the EU member state where the servers sit.
FISA Section 702 (US). Section 702 of the Foreign Intelligence Surveillance Act authorizes the NSA to collect communications of non-US persons from US-based providers without individual warrants, under a bulk collection framework renewed through 2026. FISA 702 operates secretly; providers cannot disclose specific requests. Any service using US-based infrastructure for non-US users falls within this framework.
Investigatory Powers Act (UK, 2016). The "Snooper's Charter" requires UK companies to maintain capabilities for bulk data interception on demand and prohibits disclosure of interception notices. Post-Brexit, the UK operates its own surveillance framework distinct from (but broadly similar to) EU law.
GDPR (EU, 2018). The General Data Protection Regulation restricts transfers of EU personal data to countries without "adequate" data protection levels. However, GDPR primarily governs data controllers (organizations) rather than providing strong protection against government access — it does not prevent EU governments from issuing data access orders, and the "adequacy" framework does not fully resolve the CLOUD Act conflict. The 2023 EU-US Data Privacy Framework attempts to address the Schrems II court ruling that invalidated the previous Privacy Shield, but its durability under future legal challenge remains uncertain.
Swiss nDSG (2023). Switzerland's revised Federal Act on Data Protection applies Swiss privacy law to any organization processing data about Swiss residents, with extraterritorial reach mirroring GDPR. More relevantly for data sovereignty purposes, Switzerland's domestic laws provide procedural protections against foreign data requests — Swiss courts can and do review requests before production, and Swiss secrecy laws impose penalties on premature disclosure.
Why jurisdiction matters more than server location
The principle is simple: legal compulsion follows corporate structure, not datacenter geography.
Consider a concrete example. Proton AG is incorporated in Geneva, Switzerland. Its servers are also in Switzerland and Iceland. A US law enforcement agency cannot serve Proton with a CLOUD Act warrant because Proton is not a US person or US-based provider. It must use Swiss legal channels — MLAT with Switzerland, which involves Swiss courts and Swiss prosecutors. Switzerland's MLAT treaties require that the requested conduct constitute a crime under Swiss law (dual criminality), which filters out many US requests that would be automatically granted against a US provider.
Contrast this with a US company that moves its European user data to Frankfurt. It has satisfied GDPR data residency requirements. But the parent company in Seattle can still be served a CLOUD Act warrant, and the legal entity that controls the data — which is the US parent, not the German subsidiary — must comply.
This is why the choice of cloud provider is a data sovereignty decision, not just a procurement decision. Organizations that process sensitive data — health records, financial data, legal communications, personal correspondence — and want genuine data sovereignty cannot achieve it using US-headquartered cloud providers, regardless of datacenter location.
For individuals, the equivalent decision is email and cloud storage provider. Your Google Drive files, regardless of which datacenter they sit in, are held by a US company that is subject to US surveillance law and CLOUD Act requests.
How to achieve data sovereignty
Achieving meaningful data sovereignty requires operating at three layers simultaneously.
Layer 1: Legal jurisdiction selection. Choose service providers, cloud platforms, and organizational structures incorporated in jurisdictions with strong domestic privacy laws and no compulsory intelligence-sharing with Five Eyes or similar alliances. Switzerland, Iceland, and Norway are the strongest options for European organizations. Within the EU, Germany and Austria have relatively strong domestic privacy protections on top of GDPR.
For organizations, this may mean restructuring the legal entities that control sensitive data — creating a Swiss or EU subsidiary that genuinely controls data rather than acting as a pass-through for a US parent.
Layer 2: Cryptographic controls. Jurisdiction-based protection has limits. Legal processes evolve, governments reach agreements, companies get acquired. The only protection that survives legal compulsion is end-to-end encryption where the provider never holds the plaintext.
Zero-knowledge architecture means the service operator can provide nothing useful to any legal request except ciphertext. Proton Mail implements this for email between Proton users (and optionally to external recipients with a password). Proton Drive implements it for all stored files. Even if a court orders Proton to produce data, they can only produce encrypted blobs.
The tradeoff is functional: zero-knowledge encryption removes the provider's ability to offer server-side search, spam filtering based on content, and AI features that require access to plaintext. Organizations choosing zero-knowledge tools must accept these constraints.
Layer 3: Infrastructure independence. Avoid subcontracting to hyperscale US cloud providers for sensitive workloads. AWS, Azure, and Google Cloud are all US companies with direct exposure to FISA 702 and CLOUD Act orders. A Swiss company running its application on AWS EU-West infrastructure has solved the legal jurisdiction problem for itself but reintroduced it at the infrastructure layer.
Alternatives include OVHcloud (French), Hetzner (German), and Infomaniak (Swiss). These are smaller providers with different SLA profiles, which is a real operational trade-off. For sensitive workloads, self-hosted infrastructure on owned or leased hardware provides the strongest guarantee.
Data sovereignty for individuals
The practical implementation for individuals is simpler than for organizations, because individuals typically need to protect personal communications, documents, and browsing data rather than multi-jurisdiction corporate data flows.
Email. Move away from Gmail, Outlook, and Yahoo — all US companies subject to CLOUD Act and FISA 702 surveillance. Proton Mail is the most credible privacy-respecting alternative: Swiss jurisdiction, end-to-end encryption for Proton-to-Proton messages (and with external recipients via password), open-source clients, and a track record of successfully resisting foreign data requests.
Disclosure: the link below is an affiliate link. We earn a commission if you subscribe — at no extra cost to you.
Switch to Proton Mail → Proton Mail (Free plan available — Swiss jurisdiction, end-to-end encrypted)
Cloud storage. Google Drive, Dropbox, and OneDrive are all US companies. Proton Drive offers end-to-end encrypted storage under Swiss jurisdiction. Files are encrypted before upload; Proton cannot read them. For larger storage needs, self-hosted Nextcloud on European infrastructure is a viable option for technically capable users.
Store files under Swiss law → Proton Drive (Free storage, end-to-end encrypted, Swiss jurisdiction)
VPN and network traffic. A VPN does not directly solve data sovereignty — your email content remains under your provider's jurisdiction regardless of which VPN you use. But a VPN with Swiss or Scandinavian jurisdiction keeps your browsing patterns and DNS queries out of US surveillance reach. See our browser privacy guide for a technical breakdown of what a VPN actually protects.
Search and productivity. Replacing Google Search with privacy-respecting alternatives (Brave Search, Startpage, DuckDuckGo) removes the behavioral data collection layer. Our alternatives to Google guide covers the full service-by-service migration, including search, calendar, and document editing.
Data sovereignty for organizations
For organizations, data sovereignty involves both technical controls and legal structure. The questions are larger:
Cloud infrastructure. Where is your cloud provider headquartered? What is the parent company's jurisdiction? The CLOUD Act applies to any provider with US nexus, regardless of where in the corporate structure your contract sits. Evaluate OVHcloud, Hetzner, Scaleway, and Infomaniak as alternatives to AWS/Azure/GCP for sensitive workloads.
SaaS tools. Most enterprise SaaS runs on US infrastructure and is operated by US companies. Slack, Salesforce, Zoom, Notion, and GitHub are all subject to US legal process. European alternatives exist for many categories — Element (Matrix-based) for secure messaging, Nextcloud for document collaboration — but adoption friction is real.
Data processing agreements (DPAs). GDPR requires DPAs with all processors. Ensure your DPAs specify not just data residency (where servers are) but the legal entity that controls processing and the jurisdiction that governs the agreement. A DPA with an EU subsidiary of a US company does not prevent the US parent from being served a CLOUD Act order.
Employee data. In most EU jurisdictions, employee data is subject to stronger protections than customer data. Storing HR records on a US SaaS platform (Workday, SAP SuccessFactors) creates GDPR transfer compliance obligations and sovereignty risks that many organizations underestimate.
Incident response. If you experience a breach, data sovereignty questions become acute. A US-jurisdiction provider may have incident response obligations that require them to notify US authorities before notifying you or EU regulators, creating conflicts with GDPR breach notification timelines. Clarify these obligations contractually in advance.
The organizational minimum bar for data sovereignty is: sensitive data processed only by providers incorporated outside the Five Eyes and without US parent companies; end-to-end encryption or zero-knowledge architecture for the most sensitive categories; and legal review of any cross-border data transfer against both GDPR and the national laws of involved jurisdictions.
For the technical layer that complements jurisdictional choices, see our threat modeling guide for tech-aware users — it walks through building a structured adversary model that maps your actual risks to the controls that address them.
