EU Data Sovereignty Requirements: What GDPR Demands vs. What Sovereignty Actually Requires
Ask most compliance teams what EU data sovereignty requires and they’ll point to GDPR. Ask their legal counsel what Schrems II requires and they’ll describe Transfer Impact Assessments and Standard Contractual Clauses. Ask their CISO what happens when a U.S. government subpoena lands at their cloud provider’s headquarters, and the room goes quiet.
The confusion is understandable. “Data residency,” “data localization,” and “data sovereignty” are used interchangeably in most enterprise conversations — but they are legally and architecturally distinct. An organization can satisfy every GDPR data residency obligation on paper while remaining structurally exposed to foreign government access. Understanding where GDPR’s requirements end and where genuine data sovereignty begins is not an academic distinction. It is the compliance gap that Data Protection Authorities are now actively enforcing.
Executive Summary
Main Idea: GDPR establishes data residency and transfer requirements for EU personal data — but GDPR compliance and data sovereignty are not synonymous. Data residency tells you where data must be stored. Data sovereignty determines who controls access to it and under which legal jurisdiction. For organizations using U.S.-headquartered cloud infrastructure, GDPR-compliant data residency in a Frankfurt data center provides geographic compliance while leaving data legally accessible to U.S. government demands under the CLOUD Act — a structural exposure that Standard Contractual Clauses cannot remedy. True data sovereignty compliance requires architectural controls — customer-controlled encryption keys, single-tenant European deployment, policy-enforced geofencing — that make unauthorized access technically impossible, not merely contractually prohibited.
Why You Should Care: Austrian, French, and Italian DPAs have already ruled that certain U.S. cloud arrangements violate GDPR. GDPR fines reach 4% of global annual revenue. The NIS 2 Directive adds management criminal liability. The Kiteworks 2026 Data Security and Compliance Risk Report found that 33% of organizations experienced a sovereignty-related incident in the past 12 months, despite 44% describing themselves as well-informed. Organizations that conflate residency with sovereignty are not compliant — they are exposed.
Key Takeaways
- Data residency, localization, and sovereignty are legally distinct. Residency governs where data is physically stored. Localization requires it to stay within the country of collection. Sovereignty governs who controls access and under which legal jurisdiction. Satisfying one does not automatically satisfy the others.
- GDPR establishes residency requirements but not full sovereignty. Articles 44–49 restrict cross-border transfers — but compliance does not prevent a U.S. CLOUD Act demand from reaching data stored by a U.S.-headquartered provider in an EU data center. Location is not jurisdiction.
- Schrems II reframed residency as insufficient. By requiring Transfer Impact Assessments and identifying customer-controlled encryption as the required supplementary measure, the CJEU established that geographic location cannot substitute for jurisdictional control.
- Architectural sovereignty closes what contracts cannot. Standard Contractual Clauses bind parties but cannot override a U.S. government legal demand. Customer-controlled encryption keys held outside the provider’s infrastructure make the provider technically incapable of producing readable data regardless of what legal demand it receives.
- NIS 2 and DORA extend sovereignty obligations beyond GDPR. The NIS 2 Directive and DORA impose supply chain sovereignty assessments, incident reporting, and management liability that compound on top of GDPR. Organizations in regulated sectors face all three frameworks simultaneously.
Defining the Terms: What Residency, Localization, and Sovereignty Actually Mean
Data residency refers to the physical geographic location where data is stored and processed. A data residency requirement means: this data must be stored on servers within this jurisdiction. GDPR creates de facto residency requirements through its transfer restrictions — by limiting where personal data can flow, it pressures organizations to keep data within the EU. But residency is a question of location, not control. Data can be physically resident in Germany while remaining legally accessible to a foreign government simultaneously.
Data localization is a stricter version of residency: the requirement that data not only be stored locally but remain within the country where it was collected. Some national regulations and sector-specific rules within the EU impose localization requirements on top of GDPR’s baseline — particularly for healthcare data, financial transactions, and public sector records.
Data sovereignty is the broadest concept. It refers to the principle that data is governed by the laws of the jurisdiction where it resides — and that the controlling organization has genuine legal and technical control over who can access it. Sovereignty is not satisfied by choosing an EU data center. A U.S. provider operating a Frankfurt data center is not a sovereign European infrastructure choice; it is a European address with U.S. legal exposure.
The practical consequence: an organization can check every GDPR data residency box — EU data centers, documented transfer mechanisms, compliant subprocessors — and still fail to achieve data sovereignty if the provider is U.S.-headquartered and holds the encryption keys.
A Complete Checklist of GDPR Compliance
What GDPR Actually Requires for Data Residency and Transfers
GDPR does not contain a blanket requirement that EU personal data be stored within the EU. Chapter V (Articles 44–49) restricts when EU personal data may be transferred outside the EU/EEA — through adequacy decisions, Standard Contractual Clauses, Binding Corporate Rules, or other approved mechanisms. In practice, Chapter V creates strong residency pressure: if no valid transfer mechanism exists for a given destination, the data must stay in the EU.
For most organizations using U.S. cloud providers, SCCs are the operative mechanism — supplemented, since Schrems II, by Transfer Impact Assessments evaluating whether U.S. law undermines those SCCs’ effectiveness. GDPR Article 32’s requirement for “appropriate technical and organisational measures” is, post-Schrems II, interpreted by DPAs to require demonstrable technical controls proportionate to the identified risk. The EDPB’s Recommendations 01/2020 named customer-controlled encryption with keys held exclusively within the EEA as the technical measure capable of addressing CLOUD Act-compelled access. This is where GDPR residency requirements and sovereignty architecture converge: genuine Article 32 compliance for U.S. provider transfers requires the same customer-key-control architecture that sovereignty demands.
The CLOUD Act Gap: Why Residency Is Not Sovereignty
The U.S. CLOUD Act requires U.S. companies to produce data they control upon receiving a valid U.S. government demand, regardless of where that data is physically stored. A U.S. provider operating a Frankfurt data center is not a European organization — it is a U.S. organization with European real estate. The demand requires no European court order, does not notify the data controller or data subject, and the provider must comply regardless of its contract with the European customer. Standard Contractual Clauses document what the provider intends to do; they cannot change what U.S. law compels it to do.
The EU-US Data Privacy Framework (2023) provides a transfer mechanism but does not repeal the CLOUD Act. It adjusts oversight around U.S. intelligence surveillance; it does not prevent CLOUD Act demands from reaching provider-controlled data. Privacy advocates are already pursuing legal challenges. Building permanent compliance infrastructure on DPF reliance means accepting ongoing legal uncertainty.
The only control that closes this gap is architectural: customer-managed encryption with keys held entirely outside the provider’s infrastructure. When the provider cannot access the keys, a CLOUD Act demand yields only ciphertext — legally obtained but unreadable. The provider becomes technically incapable of complying with a decryption demand regardless of legal compulsion. Architecture defeats what contracts cannot prevent. This is precisely what the EDPB means by a “technical supplementary measure” sufficient to address CLOUD Act exposure — and it is the standard EU DPAs are now applying in enforcement.
The Broader EU Sovereignty Framework: NIS 2 and DORA
GDPR is the foundation, but for most organizations doing business in the EU, it is not the only sovereignty framework they operate under. Two additional EU regulations impose sovereignty obligations that compound on top of GDPR — and in some respects go further.
The NIS 2 Directive, transposed by EU member states in October 2024, covers essential sectors — energy, transport, banking, healthcare, digital infrastructure — and important sectors including manufacturing and professional services. Its sovereignty dimension is Article 21’s supply chain security mandate: covered entities must assess cybersecurity risks across their ICT supply chains, including the sovereignty posture of cloud providers. A U.S.-headquartered provider subject to CLOUD Act compulsion is a supply chain sovereignty risk that NIS 2 requires the customer to document and address. NIS 2 compliance failures carry penalties up to €10 million or 2% of global annual turnover, with direct personal liability for senior management — liability GDPR does not impose on individuals.
DORA compliance requirements, enforceable from January 2025 for EU financial services entities, go further: Article 30 explicitly requires contracts with ICT providers to address data sovereignty, encryption key management, and exit strategies. For financial services organizations, GDPR, DORA, and national banking secrecy laws create a three-layer sovereignty obligation that purely GDPR-centric compliance programs cannot satisfy.
What Genuine EU Data Sovereignty Compliance Requires in Practice
Customer-controlled encryption keys. The EDPB names this as the primary technical supplementary measure for U.S. provider transfers. Keys in the customer’s own HSM, outside the provider’s infrastructure, make CLOUD Act compelled disclosure yield only ciphertext. This one architectural control satisfies GDPR Article 32, DORA Article 30 key management requirements, and the NIS 2 supply chain sovereignty assessment — simultaneously, across all three frameworks.
Single-tenant European deployment. Dedicated infrastructure in a specified EU data center, under the customer’s operational control, provides documented data residency that satisfies GDPR Chapter V and the evidentiary standard DPAs apply in transfer impact assessment reviews. Jurisdiction follows control, not coordinates.
Policy-enforced geofencing. Geofencing controls that technically prevent data from leaving designated geographic regions — enforced at the infrastructure level, not merely in policy — is what the EDPB classifies as a “technical supplementary measure” rather than a “contractual supplementary measure.” Only the former is considered sufficient for CLOUD Act-exposed transfers.
Immutable audit trails. GDPR Article 30, NIS 2 incident reporting, and DORA ICT risk documentation all require the same foundation: tamper-evident records of every data access, transfer, and processing activity with documented geographic scope. Third-party risk management assessments must verify that vendors can produce this evidence on demand, not merely assert that they maintain it.
How Kiteworks Delivers Architectural Sovereignty for EU Compliance
The line between GDPR data residency requirements and genuine EU data sovereignty is the line between where your data sits and who actually controls access to it. An organization can store data in Frankfurt, sign Standard Contractual Clauses, and maintain a compliant Transfer Impact Assessment — and still be one CLOUD Act subpoena away from having its EU customers’ data produced to U.S. investigators without notification. That is the structural reality of using U.S.-controlled infrastructure for European data, and it is what European DPAs are now enforcing.
True EU data sovereignty requires architecture that closes what contracts cannot: customer-controlled encryption keys that make providers technically incapable of producing readable data, single-tenant European deployment that places data under European jurisdiction, and policy-enforced geofencing that makes residency a technical reality rather than a contractual statement. Kiteworks delivers that architecture. Your data, your jurisdiction, your control.
Kiteworks was designed around a single organizing principle: your data should remain under your control — in your jurisdiction, encrypted with your keys, inaccessible to anyone you haven’t authorized, including Kiteworks itself. That is what architectural sovereignty means in practice.
The Kiteworks Private Data Network consolidates every sensitive content communication channel — email, file sharing, MFT, web forms, and APIs — onto a single platform governed by unified sovereignty controls. Customer-managed encryption (BYOK/BYOE) with FIPS 140-3 Level 1 validated encryption and AES-256 at rest ensures Kiteworks cannot decrypt customer data — not by promise but by architecture. We never hold the keys. When a government demand arrives at Kiteworks, it yields only ciphertext. That is the EDPB’s required supplementary measure, delivered at the infrastructure level.
European deployment options — on-premises, private cloud with a European provider, or Kiteworks-hosted EU infrastructure — enforce data residency technically. Policy-enforced geofencing locks content within designated regions. Zero trust security controls govern access with every interaction logged in a unified immutable audit trail visible through the CISO Dashboard. Pre-configured compliance reporting for GDPR, NIS 2, DORA, and ISO 27001 provides Transfer Impact Assessment evidence, Article 30 records, and key custody documentation — sovereignty you can prove to a regulator, not just assert to a customer.
To see how Kiteworks supports data sovereignty compliance for organizations operating in the EU, schedule a custom demo today.
Frequently Asked Questions
Data residency refers to where data is physically stored — GDPR’s Chapter V transfer restrictions create de facto residency requirements by restricting where EU personal data can flow. Data sovereignty is broader: it refers to which legal jurisdiction controls access to that data and who can compel its disclosure. A U.S. provider operating an EU data center satisfies residency requirements while creating a sovereignty gap — the data is geographically in Europe but legally accessible to U.S. government demands under the US CLOUD Act. Closing that gap requires customer-controlled encryption architecture, not just an EU server address.
GDPR does not contain a blanket EU storage mandate — but its Chapter V transfer restrictions create strong practical pressure toward EU storage by limiting where personal data can lawfully flow. Since Schrems II, organizations relying on standard contractual clauses for U.S. transfers must conduct Transfer Impact Assessments documenting whether U.S. surveillance law undermines the SCCs’ effectiveness. For most U.S. provider transfers, that assessment identifies US CLOUD Act and FISA 702 exposure as risks requiring technical supplementary measures — which the EDPB specifies as customer-controlled encryption keys held within the EEA. In effect, genuine GDPR compliance for U.S. provider transfers now requires customer-managed encryption, not just an EU data center address.
The U.S. CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) requires U.S. companies to produce data they control in response to valid U.S. government demands, regardless of where that data is stored. For EU organizations, this means a U.S. provider’s Frankfurt data center does not create European jurisdictional protection — it creates European geographic location with U.S. legal exposure. Standard contractual clauses cannot override this. The only technical control that eliminates the exposure is customer-managed encryption with keys held outside the provider’s infrastructure, making the provider technically incapable of producing readable data regardless of what legal demand it receives.
GDPR governs personal data protection. The NIS 2 Directive and DORA govern operational resilience and ICT risk management, imposing sovereignty obligations beyond GDPR’s scope. NIS 2 requires covered entities to assess ICT supply chain cybersecurity risks — including cloud providers’ US CLOUD Act exposure — with penalties up to €10 million or 2% of global turnover and direct personal management liability. DORA requires financial entities to address data sovereignty and encryption key management in ICT provider contracts, enforced through EBA outsourcing guidelines and ECB supervisory expectations. Organizations in regulated sectors face all three frameworks simultaneously and cannot satisfy their obligations through GDPR compliance alone.
DPAs require evidence in four categories: architecture documentation (deployment location, infrastructure isolation, key management records showing customer-controlled keys outside provider infrastructure); transfer documentation (Transfer Impact Assessments demonstrating technical supplementary measures address US CLOUD Act exposure); immutable audit logs (records of every data access, transfer, and processing activity with geographic scope); and policy enforcement records (geofencing configuration demonstrating technical enforcement of geographic boundaries). Kiteworks provides pre-built compliance documentation packages for GDPR compliance, NIS2 compliance, DORA compliance, and national DPA requirements — the evidentiary foundation regulators request in TIA reviews and audit inquiries.
Additional Resources