How the EU Data Act and GDPR Conflict with U.S. CLOUD Act Data Access Demands — and What That Means for Sovereignty

Search for “EU Cloud Act” and you will find hundreds of results — articles, compliance guides, and vendor explainers all referencing a law that does not technically exist. The European Union has no statute by that name. What it does have is a legal architecture that directly and deliberately conflicts with the U.S. CLOUD Act on the question of who controls access to data stored in Europe: the EU Data Act (in force since January 2024, applying from September 2025), which includes explicit provisions blocking unlawful third-country government access to non-personal data; and GDPR, which has governed the same question for personal data since 2018.

The confusion around terminology matters because it obscures a more important truth: the legal conflict between European and American data access frameworks is real, structural, and unresolved — with direct consequences for every organization storing or processing data in Europe using U.S.-controlled infrastructure. Understanding the actual instruments involved is the starting point for understanding what genuine data sovereignty compliance requires.

Executive Summary

Main Idea: The U.S. CLOUD Act (2018) requires U.S. companies to produce data they control upon receiving a valid U.S. government demand, regardless of where that data is stored. The EU Data Act (applying from September 2025) requires cloud providers operating in the EU to implement technical and organizational measures that prevent unlawful non-EU government access to non-personal data stored in Europe — and to challenge access requests that conflict with EU law. GDPR’s Chapter V and post-Schrems II requirements apply the same logic to personal data. These frameworks do not merely create compliance tension — they impose directly opposing legal obligations on U.S. cloud providers operating in Europe. The resolution is architectural: customer-controlled encryption with keys outside U.S. infrastructure makes a provider technically incapable of complying with a decryption demand, satisfying both legal systems simultaneously.

Why You Should Care: The EU Data Act applies to any business offering cloud or data processing services in the EU regardless of where it is headquartered — and it began applying in September 2025. U.S. cloud providers with EU customers are now legally required to implement measures preventing unlawful U.S. government access to EU-stored data. Organizations relying on U.S.-headquartered cloud infrastructure for EU data without architectural sovereignty controls are simultaneously non-compliant with U.S. law (if they block valid CLOUD Act demands) or EU law (if they comply with them). Only architecture resolves this.

Key Takeaways

1. There is no “EU Cloud Act” — the correct instruments are the EU Data Act and GDPR. The EU Data Act’s Chapter VII addresses unlawful third-country government access to non-personal data stored in the EU. GDPR Chapter V and post-Schrems II guidance cover personal data. Together they constitute the EU’s legal counter to U.S. CLOUD Act reach — but they are distinct instruments with different scopes, data categories, and enforcement mechanisms.
2. The U.S. CLOUD Act and EU Data Act impose directly opposing obligations on U.S. providers. The CLOUD Act requires compliance with U.S. government data demands regardless of data location. The EU Data Act requires those same providers to prevent such access when it would be unlawful under EU law and to actively challenge such demands. A provider cannot simultaneously comply with both where U.S. law compels disclosure that EU law prohibits.
3. The conflict covers different data categories under different instruments. The EU Data Act’s Chapter VII covers non-personal data. GDPR Chapter V and Schrems II cover personal data. For any enterprise with both in EU infrastructure — which describes virtually every organization — both instruments apply simultaneously across the full data estate.
4. Customer-controlled encryption is the architectural resolution to both conflicts. When a U.S. provider cannot access the encryption keys for EU-stored data, it cannot produce readable content in response to a CLOUD Act demand — satisfying the technical impossibility standard — while also satisfying the EU Data Act’s requirement for technical measures preventing effective foreign government access.
5. The EU Data Act’s cloud switching provisions lower the cost of sovereign migration. By requiring providers to facilitate customer switching on two months’ notice and eliminating switching fees by January 2027, the EU Data Act has deliberately reduced the commercial barrier to migrating from U.S.-controlled cloud infrastructure to sovereign European alternatives.

What the U.S. CLOUD Act Actually Requires

The Clarifying Lawful Overseas Use of Data Act (2018) established that U.S. companies must preserve and disclose data stored anywhere in the world in response to valid U.S. legal process — including data held in European data centers. Its reach follows corporate control, not geography. A demand served on a U.S. provider’s U.S. headquarters compels production of data from its Frankfurt, Amsterdam, or Dublin servers. Storage location is irrelevant; what matters is that the provider is a U.S. entity subject to U.S. law.

The CLOUD Act includes a provider challenge mechanism: U.S. providers may seek to modify or quash a demand where the customer is not a U.S. person and compliance would create a risk of violating the laws of a qualifying foreign government. In practice, this mechanism is limited — it applies narrowly, requires affirmative legal action by the provider, and does not suspend compliance during the challenge period. It does not create meaningful protection for EU data sovereignty. European data center addresses change the geography but not the jurisdiction.

What the EU Data Act Requires — and Where It Conflicts

The EU Data Act (Regulation (EU) 2023/2854), which entered into force in January 2024 and began applying in September 2025, is primarily a data-sharing and cloud-switching regulation — but Chapter VII contains the provisions most directly relevant to sovereignty. Chapter VII requires cloud providers and data processing service providers operating in the EU to implement “technical, legal, and organisational measures” to prevent non-EU government access to non-personal data stored in the EU where such access would be unlawful under EU or member state law.

When a provider receives an access request from a third-country government — including a U.S. CLOUD Act demand — it must assess whether the request is reasoned, specific, and proportionate, and whether it conflicts with EU law or applicable international agreements. Where a conflict exists, the provider must challenge or seek modification of the order. If disclosure is unavoidable, it must provide only the minimum data necessary with protective measures applied. Providers must also publicly disclose the technical measures they have taken to prevent unlawful government access and the locations of their ICT infrastructure — creating accountability: EU customers and regulators can assess whether a provider’s sovereignty architecture is genuine or merely claimed.

The conflict with the CLOUD Act is direct. A U.S. CLOUD Act demand for non-personal data held in the EU may be precisely the scenario Chapter VII requires the provider to challenge. The provider cannot simultaneously satisfy both: complying with the CLOUD Act demand may violate the EU Data Act; challenging it to comply with the EU Data Act may expose the provider to U.S. legal consequences.

GDPR’s Role: The Personal Data Dimension

While the EU Data Act’s Chapter VII covers non-personal data, GDPR Chapter V has governed the equivalent conflict for personal data since 2018. The Schrems II ruling (2020) sharpened that governance into a direct confrontation with U.S. surveillance law: SCCs for U.S. provider transfers are only valid where data is genuinely protected from U.S. government access — requiring Transfer Impact Assessments that honestly evaluate CLOUD Act and FISA 702 exposure, and technical supplementary measures where active risk is identified. The EDPB’s Recommendations 01/2020 named customer-controlled encryption with keys outside the provider’s infrastructure as the primary adequate technical measure. Austrian, French, and Italian DPAs have issued enforcement decisions concluding that certain U.S. cloud arrangements violate GDPR — effectively ruling that CLOUD Act exposure without adequate technical mitigation constitutes a GDPR transfer violation.

The combined effect is comprehensive: personal data in EU infrastructure is protected by GDPR and Schrems II; non-personal data is protected by EU Data Act Chapter VII. For any enterprise with both — which is virtually every organization — both instruments apply simultaneously across the full data estate.

Why the Conflict Is Architecturally Irresolvable Through Contracts Alone

The standard response to this conflict has been contractual: U.S. providers sign data processing agreements promising not to disclose EU data without legal compulsion, commit to challenging overbroad demands, and offer notification procedures where permitted. These commitments are not meaningless — they create legal obligations and reputational stakes. But they do not resolve the underlying conflict, because contracts bind parties to each other; they do not override the legal obligations each party owes to sovereign governments.

When a valid CLOUD Act demand arrives, the U.S. provider’s contractual commitment to the EU customer does not change its legal obligation to the U.S. government. The provider must comply — or face U.S. legal consequences. The EU customer’s DPA then has grounds to conclude that contractual protections were insufficient under Schrems II or the EU Data Act. The gap is not contractual — it is jurisdictional.

The EU Data Act’s challenge mechanism improves on the status quo by requiring providers to actively contest unlawful demands — but it does not eliminate the tension. Challenges take time, have uncertain outcomes, and do not suspend disclosure obligations during proceedings. The structural resolution is architecture: customer-controlled encryption where the EU customer holds the keys in their own European infrastructure, and the U.S. provider never possesses decryption capability. A CLOUD Act demand yields only ciphertext — data the provider legally produces but cannot meaningfully disclose. The EU Data Act’s technical measures requirement is satisfied. GDPR’s Schrems II supplementary measure requirement is satisfied. The CLOUD Act demand is technically complied with. All simultaneously, through architecture.

What This Means for Data Sovereignty in Practice

The EU Data Act/GDPR versus CLOUD Act conflict reframes data sovereignty from a compliance checkbox into an architectural property. Sovereignty is not achieved by choosing a provider that promises to protect data — it is achieved by deploying architecture in which the provider is technically incapable of betraying that promise, because they never had the access that would make betrayal possible.

For organizations evaluating their EU data infrastructure, four practical controls follow from this. Single-tenant European deployment — dedicated infrastructure in an EU data center through a European cloud provider or customer-owned infrastructure, not a U.S. hyperscaler’s EU region — separates EU data from U.S. corporate control. Customer-controlled encryption with keys in the EU customer’s own HSM closes the CLOUD Act gap. Policy-enforced geofencing ensures data residency is a technical reality — the EU Data Act’s transparency requirements expose unenforceable geofencing claims rather than hiding them. And immutable audit trails provide the evidentiary documentation both EU Data Act and GDPR accountability obligations require.

The EU Data Act’s cloud switching provisions add a commercial dimension: two months’ notice termination rights and the elimination of switching fees by January 2027 deliberately lower the cost of migrating from U.S.-controlled infrastructure to sovereign alternatives — making the architectural sovereignty option more accessible precisely as legal consequences become more acute.

How Kiteworks Resolves the Legal Conflict Architecturally

The “EU Cloud Act” does not exist — but the legal conflict it describes is real and now fully in force. The EU Data Act’s Chapter VII and GDPR Chapter V together establish that EU-stored data — personal and non-personal — is protected from unlawful non-EU government access by instruments that directly conflict with the U.S. CLOUD Act’s disclosure requirements. U.S. cloud providers face opposing legal obligations that contracts cannot reconcile and challenge procedures can only partially mitigate.

The resolution is architectural sovereignty: customer-controlled encryption keys in European infrastructure, single-tenant EU deployment outside U.S. corporate control, and technical geofencing that makes data residency provable. Kiteworks delivers that architecture — your data, your jurisdiction, your keys — making the legal conflict technically moot for providers and genuinely protective for the organizations whose data is at stake.

Kiteworks delivers the architectural resolution that the EU Data Act and GDPR’s Schrems II requirements demand — and the CLOUD Act paradox makes necessary.

The Kiteworks Private Data Network deploys as a dedicated, single-tenant instance in the EU customer’s chosen European location — on-premises, through a European cloud provider, or Kiteworks-hosted EU infrastructure. No U.S.-located processing of EU customer data. Customer-managed encryption (BYOK/BYOE) with FIPS 140-3 Level 1 validated encryption and AES-256 at rest means Kiteworks never holds customer encryption keys. A CLOUD Act demand served on Kiteworks yields only ciphertext — technically compliant disclosure that reveals nothing readable. The EU Data Act’s technical measures requirement is met. GDPR’s Schrems II supplementary measure requirement is met. The CLOUD Act obligation is fulfilled. All simultaneously, through architecture.

Policy-enforced geofencing locks content within designated EU regions at the infrastructure level. Zero trust security controls govern all access with every interaction captured in an immutable audit trail through the CISO Dashboard. Pre-configured compliance reporting for GDPR, NIS 2, DORA, and ISO 27001 provides the regulatory evidence package when DPAs or customers ask how the CLOUD Act conflict has been resolved. All channels — email, file sharing, MFT, web forms, APIs — governed under a single platform with consistent sovereignty controls.

To see how Kiteworks resolves the EU Data Act and GDPR conflict with U.S. CLOUD Act demands, schedule a custom demo today.

Additional Resources

Blog Post
Data Sovereignty: a Best Practice or Regulatory Requirement?

• eBook
  Data Sovereignty and GDPR
• Blog Post
  Avoid These Data Sovereignty Pitfalls
• Blog Post
  Data Sovereignty Best Practices
• Blog Post
  Data Sovereignty and GDPR [Understanding Data Security]