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 simple to state but hard to achieve. The core rule: data is subject to the laws of the nation where the controlling entity sits. Not where the servers are. Not where the data was created. It is the country where the organization that controls it is based and runs.
This point matters a lot in practice. A US company storing data on servers in Amsterdam is still a US company. The US government can force it to produce that data under US law. The CLOUD Act, a 2018 statute, gave US law reach over data held abroad by US-based providers. The Amsterdam datacenter does not change this.
True data sovereignty means three things line up:
1. Legal jurisdiction. The organization that holds your data is based in a country with strong privacy laws. And that country has no cross-border data access deals with the jurisdiction you want to avoid.
2. Physical control. The servers are run by that organization. They are not handed off to a US or Chinese cloud provider (AWS, Azure, Google Cloud, Alibaba Cloud) that can be served its own legal order.
3. Cryptographic architecture. The organization cannot read your data even if ordered to produce it. End-to-end encryption means they hold only ciphertext, not keys.
Most "sovereign" cloud tools meet one or two of these, rarely all three.
Data sovereignty vs data residency vs data localization
These three terms are often mixed up, including in business buying. They are not the same:
Data residency means the physical location where data is stored. An organization with a data residency policy keeps EU customer data on EU-based servers. This is mostly about compliance. It meets GDPR rules on data transfer outside the EU. And it gives organizations a clear, contractual answer about where their data sits. It does not change which legal entity controls that data or which legal system governs it.
Data localization is the version that a government requires. Countries like Russia (Federal Law 242-FZ), China (PIPL, Data Security Law), and India (DPDP Act 2023) require that certain kinds of data about their citizens be stored and processed inside national borders. Here governments impose data residency on companies. Companies do not choose it. These rules create compliance duties for any organization that handles data from these jurisdictions.
Data sovereignty is the governance layer above both. It asks: who really controls this data in law? Which court system can force access? Which privacy law protects it? A company can meet data residency rules (all servers in Germany) and still have no data sovereignty. That happens if the controlling entity is a US parent company subject to FISA 702 or CLOUD Act orders.
What this means for organizations: data residency is needed for data sovereignty but is not enough on its own. Choosing a cloud provider based in a favorable jurisdiction matters at least as much as where its datacenters sit.
The legal threat landscape
To understand data sovereignty, you need to understand the specific laws that undermine it.
CLOUD Act (US, 2018). The Clarifying Lawful Overseas Use of Data Act lets US law enforcement issue warrants for data held abroad by US-based providers. It does not go through Mutual Legal Assistance Treaty (MLAT) steps. The MLAT process was slow and let host countries object. The CLOUD Act skips it. Any US-based cloud provider - AWS, Microsoft Azure, Google Cloud, Salesforce, Dropbox - can be forced to produce data held on European servers. The EU member state where the servers sit is not told.
FISA Section 702 (US). Section 702 of the Foreign Intelligence Surveillance Act lets the NSA collect communications of non-US persons from US-based providers without individual warrants. It works under a bulk collection framework renewed through 2026. FISA 702 works in secret. Providers cannot disclose specific requests. Any service that uses US-based infrastructure for non-US users falls under this framework.
Investigatory Powers Act (UK, 2016). The "Snooper's Charter" requires UK companies to keep the means for bulk data interception on demand. It also bans them from disclosing interception notices. After Brexit, the UK runs its own surveillance framework. It is separate from EU law but broadly similar.
GDPR (EU, 2018). The General Data Protection Regulation limits transfers of EU personal data to countries without "adequate" data protection. But GDPR mostly governs data controllers (organizations). It does not give strong protection against government access. It does not stop EU governments from issuing data access orders. And the "adequacy" framework does not fully solve the CLOUD Act conflict. The 2023 EU-US Data Privacy Framework tries to address the Schrems II court ruling that struck down the earlier Privacy Shield. But it is not clear how well it will hold up against future legal challenge.
Swiss nDSG (2023). Switzerland's revised Federal Act on Data Protection applies Swiss privacy law to any organization that processes data about Swiss residents. Its cross-border reach mirrors GDPR. More to the point for data sovereignty, Swiss domestic laws give procedural protection against foreign data requests. Swiss courts can and do review requests before production. And Swiss secrecy laws punish early disclosure.
Why jurisdiction matters more than server location
The rule is simple: legal force follows corporate structure, not datacenter geography.
Take a concrete example. Proton AG is based in Geneva, Switzerland. Its servers are also in Switzerland and Iceland. A US law enforcement agency cannot serve Proton with a CLOUD Act warrant. Proton is not a US person or US-based provider. The agency must use Swiss legal channels - MLAT with Switzerland, which involves Swiss courts and Swiss prosecutors. Switzerland's MLAT treaties require that the act in question be a crime under Swiss law too (dual criminality). This filters out many US requests that would be granted by default against a US provider.
Now compare a US company that moves its European user data to Frankfurt. It has met GDPR data residency rules. But the parent company in Seattle can still be served a CLOUD Act warrant. And the legal entity that controls the data - the US parent, not the German unit - must comply.
This is why the choice of cloud provider is a data sovereignty decision, not just a buying decision. Some organizations process sensitive data - health records, financial data, legal messages, personal mail - and want real data sovereignty. They cannot get it from US-based cloud providers, no matter where the datacenters are.
For individuals, the same choice is the email and cloud storage provider. Your Google Drive files sit in some datacenter, but a US company holds them. That company is subject to US surveillance law and CLOUD Act requests.
How to achieve data sovereignty
To get real data sovereignty, you must work at three layers at once.
Layer 1: Legal jurisdiction selection. Choose service providers, cloud platforms, and corporate structures based in jurisdictions with strong privacy laws. They should have no forced 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 fairly strong privacy laws on top of GDPR.
For organizations, this may mean reworking the legal entities that control sensitive data. The goal is a Swiss or EU unit that truly controls the data, not a pass-through for a US parent.
Layer 2: Cryptographic controls. Jurisdiction-based protection has limits. Laws change, governments reach deals, companies get bought. The only protection that survives legal force is end-to-end encryption, where the provider never holds the plaintext.
Zero-knowledge architecture means the service operator can give nothing useful to any legal request except ciphertext. Proton Mail does this for email between Proton users (and, with a password, to outside recipients too). Proton Drive does it for all stored files. Even if a court orders Proton to produce data, they can only produce encrypted blobs.
The tradeoff is in function. Zero-knowledge encryption takes away the provider's ability to offer server-side search, spam filters based on content, and AI features that need the plaintext. Organizations that choose zero-knowledge tools must accept these limits.
Layer 3: Infrastructure independence. Avoid handing sensitive workloads to giant US cloud providers. AWS, Azure, and Google Cloud are all US companies with direct exposure to FISA 702 and CLOUD Act orders. A Swiss company that runs its app on AWS EU-West infrastructure has solved the jurisdiction problem for itself. But it brought the problem back 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 gives the strongest guarantee.
Data sovereignty for individuals
For individuals, the setup is simpler than for organizations. Individuals usually need to protect personal messages, documents, and browsing data, not corporate data flows across many jurisdictions.
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 option: Swiss jurisdiction, end-to-end encryption for Proton-to-Proton messages (and with outside recipients via password), open-source clients, and a track record of 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, so Proton cannot read them. If you need more storage, self-hosted Nextcloud on European infrastructure is a good option for skilled users. For a deeper look at how these encryption models actually work, see our guide to encrypted cloud storage for developers.
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 stays under your provider's jurisdiction no matter 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. Swapping Google Search for privacy-respecting options (Brave Search, Startpage, DuckDuckGo) removes the behavioral data collection layer. Our alternatives to Google guide covers the full move, service by service, including search, calendar, and document editing.
Data sovereignty for organizations
For organizations, data sovereignty involves both technical controls and legal structure. The questions are bigger:
Cloud infrastructure. Where is your cloud provider based? What is the parent company's jurisdiction? The CLOUD Act applies to any provider with a US link, no matter where in the corporate structure your contract sits. Look at 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 work - but the switch still takes effort.
Data processing agreements (DPAs). GDPR requires DPAs with all processors. Make sure your DPAs name 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 unit of a US company does not stop the US parent from being served a CLOUD Act order.
Employee data. In most EU jurisdictions, employee data gets stronger protection than customer data. Storing HR records on a US SaaS platform (Workday, SAP SuccessFactors) creates GDPR transfer duties and sovereignty risks. Many organizations underrate them.
Incident response. If you have a breach, data sovereignty questions get sharp. A US-jurisdiction provider may have duties that make it notify US authorities before it notifies you or EU regulators. That clashes with GDPR breach notification timelines. Set out these duties in the contract in advance.
The minimum bar for organizations is threefold. First, sensitive data is processed only by providers based outside the Five Eyes and with no US parent companies. Second, end-to-end encryption or zero-knowledge architecture covers the most sensitive categories. Third, a legal review checks any cross-border data transfer against both GDPR and the national laws of the jurisdictions involved.
For the technical layer that rounds out jurisdiction choices, see our threat modeling guide for tech-aware users - it walks you through building a structured adversary model that maps your real risks to the controls that address them.
Related guides: Encrypted email in 2026, explained.
