“The cloud” is not a magic dimension where data floats free of jurisdiction. The cloud is a data center. The data center is in a building. The building is in a country. And that country’s government has opinions — backed by law and enforcement power — about what happens to data within its borders. Where your data physically lives determines who can compel access to it, what privacy protections apply, and which regulations you’re subject to. You don’t get to opt out of a country’s laws by hosting your website on their soil.
The TLDR
Data sovereignty means a nation’s laws and governance apply to data stored within its borders. Data residency means data must stay within specific geographic boundaries. Data localization means data must be stored domestically and cannot be transferred abroad. These are three different concepts that people conflate constantly. The GDPR restricts data transfers outside the EU/EEA unless specific safeguards are in place — Schrems II killed Privacy Shield and made those transfers much harder. The U.S. CLOUD Act lets American law enforcement compel data from U.S. companies even when the data is stored overseas. China, Russia, and an increasing number of nations require data localization. The result is a patchwork of conflicting laws where compliance with one country’s requirements may violate another’s.
The Reality
In 2020, the Court of Justice of the European Union dropped the Schrems II decision and blew a hole in transatlantic data flows that still hasn’t fully healed. Max Schrems, an Austrian privacy activist, challenged Facebook’s transfer of EU personal data to U.S. servers, arguing that U.S. surveillance laws (specifically Section 702 of FISA and Executive Order 12333) made it impossible for EU citizens’ data to be adequately protected on American soil.
The court agreed. Privacy Shield — the framework governing EU-U.S. data transfers — was invalidated overnight. Thousands of companies that relied on Privacy Shield suddenly had no legal basis for transferring data across the Atlantic. The fallout is still playing out. The EU-U.S. Data Privacy Framework (DPF), adopted in 2023 as the successor, is widely expected to face its own legal challenge. Schrems himself has called it “lipstick on a pig.”
Meanwhile, the U.S. CLOUD Act (Clarifying Lawful Overseas Use of Data Act), passed in 2018, says the opposite: U.S. law enforcement can compel U.S.-based companies to produce data regardless of where that data is physically stored. Your company is headquartered in California but stores European customer data in a Frankfurt data center? The FBI can still serve a warrant. This creates a direct conflict with GDPR, which prohibits disclosing EU personal data to foreign law enforcement without a valid legal mechanism.
How It Works
Data Sovereignty vs Residency vs Localization
These terms get thrown around interchangeably, but they mean different things:
Data sovereignty — The principle that data is subject to the laws of the country where it’s located. This isn’t a regulation you opt into; it’s a fact of jurisdiction. Store data in Germany, and German law applies. Store it in Singapore, and Singaporean law applies. This is true regardless of where your company is based, where your customers are, or what your privacy policy says.
Data residency — A contractual or policy requirement to store data in a specific location. When you select “EU (Frankfurt)” as your AWS region, you’re making a data residency decision. Some regulations mandate it; sometimes it’s a business choice for latency or customer confidence.
Data localization — A legal mandate that certain data cannot leave the country. This is the strictest form — not just “store it here” but “it cannot cross the border, electronically or physically.” An increasing number of nations are implementing localization requirements.
GDPR Cross-Border Transfers
GDPR Chapter V (Articles 44-49) governs international data transfers. Personal data of EU/EEA residents cannot be transferred to a third country unless one of these mechanisms applies:
Adequacy decisions — The European Commission determines that a country provides an “essentially equivalent” level of data protection. Countries with adequacy include Japan, South Korea, the UK (post-Brexit), Canada (for commercial organizations), and now the U.S. under the Data Privacy Framework. Adequacy makes transfers seamless — no additional safeguards needed.
Standard Contractual Clauses (SCCs) — Pre-approved contract templates issued by the European Commission. Both parties sign the SCCs, agreeing to specific data protection obligations. Post-Schrems II, organizations must also conduct a Transfer Impact Assessment (TIA) to evaluate whether the recipient country’s laws undermine the SCCs’ protections. If they do — as Schrems II argued about U.S. surveillance law — you need supplementary measures (encryption, pseudonymization) or you can’t transfer.
Binding Corporate Rules (BCRs) — Internal data transfer rules approved by EU data protection authorities. Complex, expensive, and primarily used by large multinationals. Not practical for most organizations.
Derogations — Narrow exceptions for specific situations: explicit consent, contract necessity, important public interest, legal claims, vital interests, or transfers from public registers. These are meant to be exceptional, not routine.
The European Data Protection Board (EDPB) issues guidance on implementing these mechanisms, and their recommendations are increasingly strict.
The U.S. CLOUD Act
The CLOUD Act resolved a legal question that had been brewing since Microsoft fought a U.S. warrant for emails stored in Ireland (the “Microsoft Ireland” case). The Act clarified that U.S.-headquartered companies must comply with U.S. legal process for data they control, regardless of where it’s physically stored.
For peons outside the U.S., this means: if your data is held by an American company — Google, Microsoft, Amazon, Apple — the U.S. government can potentially access it through legal process, even if the data is stored in a European data center. The CLOUD Act does include a comity analysis (courts can consider conflicts with foreign law), but the default is compliance with U.S. demands.
This creates the impossible compliance position: GDPR says don’t disclose to foreign governments without proper legal mechanisms. The CLOUD Act says disclose to U.S. law enforcement regardless of location. Companies caught in the middle must choose which law to violate.
China’s Data Localization Regime
China operates three overlapping frameworks:
The Cybersecurity Law (CSL, 2017) requires “critical information infrastructure operators” to store personal information and important data within China. Cross-border transfers require a security assessment by the Cyberspace Administration of China (CAC).
The Data Security Law (DSL, 2021) classifies data by its importance to national security and establishes cross-border transfer restrictions based on classification level.
The Personal Information Protection Law (PIPL, 2021) — China’s GDPR equivalent — requires security assessments, standard contracts, or certification for transferring personal information abroad. For data processors handling personal information of more than one million individuals, a CAC security assessment is mandatory.
The practical effect: operating in China means keeping Chinese data in China and asking permission before moving it anywhere else.
Russia’s Federal Law 242-FZ
Since 2015, Russia has required that personal data of Russian citizens be stored on servers physically located in Russia. The law was the basis for blocking LinkedIn (2016) when the company refused to relocate Russian data to Russian servers. Other companies (Google, Apple, etc.) have largely complied by establishing local data storage to maintain market access.
Other Emerging Regimes
Data localization is trending globally. India’s Digital Personal Data Protection Act (2023) grants the government power to restrict transfers to specific countries. Brazil’s LGPD mirrors GDPR’s transfer restrictions. Vietnam, Indonesia, Nigeria, and Turkey all have data localization requirements of varying strictness. The trend is toward more restrictions, not fewer.
How It Gets Exploited
Jurisdiction Shopping
Threat actors — and some legitimate businesses — deliberately store data in jurisdictions with weak privacy laws, limited law enforcement cooperation, or no mutual legal assistance treaties. Bulletproof hosting providers in countries with lax regulation have been facilitating cybercrime infrastructure for decades. The data is “sovereign” to a country that won’t compel its disclosure.
Government-Compelled Access
Sovereignty cuts both ways. Authoritarian regimes use localization requirements to ensure they can access data about their citizens. China’s CSL and PIPL aren’t just about data protection — they’re about ensuring the government can inspect, audit, and access data within its borders. Russia’s 242-FZ serves a similar surveillance function. MITRE ATT&CK T1114 (Email Collection) and similar techniques are enhanced when data is required to reside within a jurisdiction’s reach.
Conflicting Obligations as Attack Surface
When compliance with one country’s laws requires violating another’s, organizations face impossible decisions that sometimes result in doing nothing — which means data goes unprotected while lawyers argue. The compliance gap becomes a security gap. Attackers don’t wait for legal frameworks to harmonize.
What You Can Do
Know where your data lives. Not metaphorically — specifically. Which cloud regions? Which data centers? Which countries’ laws apply? If you can’t answer this for your most sensitive data, you have a problem that starts before sovereignty even enters the conversation.
Choose cloud regions deliberately. Region selection isn’t just about latency. An EU organization storing customer data in a U.S. region is creating a sovereignty problem that no amount of SCCs will fully resolve. NIST’s Privacy Framework provides structured guidance for mapping data flows and identifying jurisdictional requirements.
Encrypt with your own keys. If you control the encryption keys, government-compelled access to the raw storage doesn’t yield readable data. This doesn’t make you immune to legal process (courts can compel key disclosure), but it adds a layer of control. BYOK (Bring Your Own Key) and HYOK (Hold Your Own Key) offerings from major cloud providers exist specifically for this scenario.
Conduct Transfer Impact Assessments. If you’re transferring data out of the EU/EEA, the TIA is legally required post-Schrems II. Even if you’re not subject to GDPR, the TIA methodology — evaluating the destination country’s surveillance laws, judicial safeguards, and enforcement mechanisms — is a sound practice for anyone moving data across borders.
Plan for regulatory divergence. The patchwork is getting more complex, not simpler. Build your architecture to accommodate data residency requirements from the start. Multi-region storage with configurable data flows is easier to implement during design than to retrofit after a regulator comes knocking.
Engage legal counsel early. Data sovereignty is a legal problem with technical implications, not the other way around. Your lawyers need to understand your architecture, and your architects need to understand the legal constraints. If these two groups aren’t in the same room regularly, you’re rolling the dice on compliance.