Prevent CLOUD Act Risks: Secure European Data Architecturally
How to Prevent US Government Access to European Data: An Architectural Approach to the CLOUD Act Problem
European organisations that process sensitive data through US-headquartered cloud platforms face a structural compliance problem that neither contract law nor data residency can resolve.
The Clarifying Lawful Overseas Use of Data (CLOUD) Act of 2018 requires US companies to produce data stored anywhere in the world upon receiving a valid US government demand — regardless of where that data resides or what data privacy agreements say.
For organisations subject to GDPR, NIS2, and DORA, this creates a direct conflict between the platforms they rely on and the legal obligations they carry.
Executive Summary
Main Idea: The US CLOUD Act creates an irreconcilable conflict between US provider legal obligations and European data sovereignty law. Remedies like standard contractual clauses, EU data centre deployment, and others do not eliminate this exposure because the CLOUD Act follows provider control, not data location. Customer-controlled encryption keys — held by the European organisation, not the provider — is the only architectural measure that renders US government demands technically unexecutable against the actual data content.
Why You Should Care: GDPR Article 48 prohibits transferring personal data to non-EU authorities solely on the basis of a foreign court or administrative order. An organisation processing data through a US platform subject to CLOUD Act jurisdiction may be in ongoing structural breach — not because of a specific incident, but because of the architecture itself. NIS2 and DORA add third-party ICT supply chain risk management obligations that compound this exposure for critical sectors and financial services.
5 Key Takeaways
- The CLOUD Act follows provider control, not data location. Storing data in a Frankfurt or Amsterdam data centre operated by a US company does not place that data under German or Dutch jurisdiction. US law enforcement can compel the provider to produce it regardless of physical storage location.
- Standard Contractual Clauses and Data Processing Agreements cannot override US legal compulsion. The CLOUD Act requires providers to comply with valid US government demands even when doing so conflicts with foreign law. SCCs and DPAs are contractual instruments with no legal force against US judicial or administrative orders directed at the provider.
- The EU-US Data Privacy Framework does not resolve CLOUD Act exposure. The DPF addresses personal data transfer rules for certified US companies but does not prevent US authorities from issuing CLOUD Act demands. FISA Section 702, reauthorised with expanded scope in April 2024, remains a distinct and unresolved concern under European data protection law.
- Transfer Impact Assessments conducted honestly will identify CLOUD Act risk as unmitigated without technical measures. The EDPB’s Schrems II recommendations explicitly identify customer-controlled encryption keys retained in the EEA as the primary technical supplementary measure capable of addressing US surveillance law exposure.
- Customer-managed encryption makes CLOUD Act demands technically unexecutable against data content. When the European organisation — not the US provider — holds encryption keys in jurisdiction-controlled HSM integration, the provider cannot produce readable data even when legally compelled. The architecture resolves what contracts cannot.
Why the CLOUD Act Creates a Structural Problem for European Organisations
The critical distinction is between data location and data control. Most European organisations that have moved to US cloud platforms have done so with “our data is in the EU” as a comfort measure. That comfort is largely unfounded.
How the CLOUD Act Operates and Why EU Data Centres Do Not Provide Protection
The CLOUD Act requires US companies to preserve, backup, and disclose electronic communications and records in their possession, custody, or control when served with a valid legal demand — regardless of storage location. The operative criterion is control, not geography. A US cloud provider operating a data centre in Frankfurt is still a US company with control of the data it stores there. When the US Department of Justice or FBI issues a demand, the Frankfurt location is legally irrelevant.
The problem is compounded by the fact that CLOUD Act demands frequently carry non-disclosure orders — the US provider may be legally prohibited from informing the European customer whose data is being accessed. An organisation may be in ongoing breach of GDPR Article 48, which prohibits handing over personal data to non-EU authorities absent an international agreement, without ever being aware a demand has occurred. The CLOUD Act is not such an agreement.
Why Contractual Protections Cannot Close the Gap
The CLOUD Act explicitly provides that US providers must comply with valid demands even when doing so conflicts with foreign law. A provider’s contractual commitment to challenge a demand or notify the customer is subordinate to its US legal obligations. This is not theoretical. The CJEU’s Schrems II ruling invalidated the EU-US Privacy Shield on precisely this basis — that US law gave authorities access to EU personal data in ways incompatible with GDPR, and EU citizens lacked effective judicial redress. The Court confirmed that standard contractual clauses could not be relied upon where US law undermined their effectiveness, and that supplementary technical measures were required.
A Complete Checklist of GDPR Compliance
How GDPR’s Transfer Framework Intersects with CLOUD Act Exposure
GDPR Chapter V — Articles 44-49 — governs international transfers of personal data. For European organisations using US platforms, understanding this framework is not optional. Whether using a US cloud provider constitutes an ongoing international transfer, and on what legal basis, has direct implications for regulatory exposure under GDPR compliance.
Articles 44-49, Schrems II, and What Transfer Impact Assessments Must Address
Organisations relying on Article 46 SCCs must, following Schrems II, conduct Transfer Impact Assessments evaluating whether US law impinges on the SCCs’ effectiveness for their specific transfers. The EDPB’s Recommendations 01/2020 set out this process in detail. Critically, the EDPB identified strong encryption before data transmission — where decryption keys are retained solely under EEA control — as the technical supplementary measure capable of addressing US surveillance law exposure. Standard cloud encryption, where the provider manages keys as part of its service, does not meet this standard: the provider retains technical access to plaintext data and remains subject to CLOUD Act demands for it.
Why the EU-US Data Privacy Framework Does Not Resolve the Problem
The DPF, adopted by the European Commission in July 2023, allows certified US companies to receive EU personal data without separate SCCs. It does not prevent US authorities from issuing CLOUD Act or FISA Section 702 demands to certified companies. FISA Section 702 was reauthorised in April 2024 with expanded scope. The European Parliament warned in May 2023 that the DPF “fails to create essential equivalence.” The EDPB’s November 2024 review report called for re-evaluation within three years. In early 2025, the Trump administration removed three of five members of the US Privacy and Civil Liberties Oversight Board — the body overseeing DPF intelligence commitments — leaving it without a quorum. The DPF’s two predecessors, Safe Harbour and Privacy Shield, were both invalidated by the CJEU. Organisations treating DPF certification as their primary CLOUD Act mitigation are building on demonstrably fragile foundations.
NIS2 and DORA Compound the Exposure
GDPR is not the only framework creating obligations relevant to CLOUD Act exposure. For organisations in critical infrastructure and financial services, NIS2 and DORA add specific third-party risk management requirements that US provider dependency directly implicates.
NIS2 Supply Chain Security and DORA ICT Third-Party Risk
NIS2, applicable from October 2024, requires essential and important entities to assess ICT supply chain security — including their providers’ exposure to non-EU government access demands under Article 21. An organisation that has not evaluated whether its US cloud provider’s CLOUD Act exposure constitutes a supply chain risk is potentially non-compliant with NIS2 risk management obligations, regardless of whether an actual demand has occurred. Fines reach €10 million or 2% of global annual turnover for essential entities.
DORA, applicable from January 2025, requires financial entities to assess concentration risk associated with ICT provider reliance, evaluate confidentiality commitments, and maintain documented exit strategies for critical ICT relationships. The CLOUD Act creates a specific concentration risk that DORA requires financial entities to evaluate and address. The ECB’s July 2025 Guide on outsourcing cloud services reinforces this, emphasising risk-based assessment of cloud providers’ legal exposure for ECB-supervised banks.
The Architectural Solution: Customer-Managed Encryption
The EDPB’s guidance defines the requirement precisely: the US provider must never have access to the unencrypted data or the encryption keys. This is an architectural requirement, not a contractual one. Satisfying it requires deploying platforms where data sovereignty compliance is built into the encryption layer itself — with keys under European customer control, stored in HSMs within the customer’s own jurisdiction.
How Customer-Managed Encryption Addresses CLOUD Act Exposure
Customer-managed encryption works on a straightforward principle: data is encrypted before it reaches the US provider’s infrastructure, using keys the customer generates and stores independently. When a US authority serves a CLOUD Act demand, the provider can produce the encrypted data — but not the readable content, because it does not hold the keys. The demand is technically unexecutable against the actual information. For GDPR purposes, this architecture directly satisfies the EDPB’s supplementary measure requirement. The data exporter — the European organisation — retains sole control of decryption keys within the EEA. The data importer — the US provider — processes only ciphertext. This is the specific configuration the EDPB identified as capable of addressing US surveillance law exposure.
Jurisdiction-Specific Key Deployment for Multi-Country Operations
For organisations operating across Germany, France, the Netherlands, and the UK, customer-managed encryption supports jurisdiction-specific key deployment. German organisations deploy HSMs in Germany, satisfying GDPR requirements and §203 StGB criminal confidentiality obligations. French organisations control keys in France, maintaining professional secrecy under the Code de la Santé Publique. Dutch organisations hold keys in the Netherlands, addressing AP enforcement expectations. UK organisations deploy within the UK, satisfying ICO guidance on transfer supplementary measures. This architecture does not require abandoning US cloud platforms — it requires ensuring the encryption layer sits under European control before data reaches US infrastructure.
Building the Documentation Case for Regulators
Deploying the right architecture is necessary but not sufficient. Data protection authorities, NIS2 supervisory bodies, and DORA competent authorities expect documented evidence. For organisations that have addressed CLOUD Act exposure through customer-managed encryption, the documentation follows a clear structure.
Transfer Impact Assessment Evidence and Ongoing Compliance
A Schrems II-compliant Transfer Impact Assessment for US provider relationships should document: the relevant US laws (CLOUD Act, FISA 702); an assessment of how they impinge on SCCs; the technical supplementary measures adopted; the basis for concluding those measures achieve essentially equivalent protection; and a monitoring commitment covering DPF adequacy decision changes. Supporting evidence includes architecture diagrams, key management procedures, HSM deployment records, and audit logs demonstrating access controls are operational. For NIS2 and DORA, add supply chain risk assessments addressing provider CLOUD Act exposure, concentration risk evaluations, exit strategies, and RBAC matrices showing who can decrypt what.
How Kiteworks Enables European Organisations to Address CLOUD Act Exposure Architecturally
The CLOUD Act problem is real, structural, and cannot be contracted away. European organisations processing sensitive data through US platforms without customer-managed encryption keys carry a compliance gap that honest Transfer Impact Assessments will identify, that GDPR supervisory authorities are increasingly willing to act on, and that NIS2 and DORA third-party risk frameworks require to be addressed. The architectural solution the EDPB has endorsed is available today. It requires ensuring the encryption layer sits where it needs to: under European control, before data reaches US infrastructure.
Kiteworks provides European organisations with a Private Data Network that directly addresses CLOUD Act exposure through customer-managed encryption. Encryption keys remain under the European customer’s exclusive control, held in HSMs deployed within the customer’s jurisdiction. When Kiteworks processes data, it processes ciphertext — making plaintext technically inaccessible to US government demands directed at Kiteworks.
The platform supports jurisdiction-specific deployment — German organisations control keys in Germany, French organisations in France, Dutch organisations in the Netherlands, UK organisations within the UK — satisfying the EDPB’s Schrems II supplementary measure requirements and providing the documented evidence base that Transfer Impact Assessments require. Kiteworks integrates Kiteworks secure email, Kiteworks secure file sharing, secure MFT, and Kiteworks secure data forms within a unified architecture — meaning customer-managed encryption applies consistently across all data exchange channels.
To learn more about how Kiteworks supports European organisations in addressing CLOUD Act exposure, schedule a custom demo today.
Frequently Asked Questions
The US CLOUD Act applies based on provider control, not data localization. A US company operating an EU data centre retains possession and control of the data it stores there. When US authorities issue a CLOUD Act demand, the provider must comply regardless of physical storage location. EU data centre location does not place data under EU jurisdiction if the operator is a US company subject to US legal obligations.
Standard contractual clauses are instruments between the data exporter and importer. The CLOUD Act requires US providers to comply with valid US government demands even when doing so conflicts with foreign law or contractual obligations. The EDPB confirmed in its Schrems II recommendations that contractual supplementary measures alone cannot address US surveillance law exposure — technical measures, specifically customer-controlled encryption keys retained in the EEA, are required.
No. The DPF governs personal data transfer rules for certified US companies but does not prevent US authorities from issuing CLOUD Act or FISA Section 702 demands. FISA Section 702, identified in Schrems II as the primary obstacle to essentially equivalent protection, was reauthorised in April 2024. The DPF also faces ongoing legal challenges and political instability. Organisations relying solely on DPF certification for CLOUD Act mitigation carry unresolved data compliance risk.
A compliant TIA should document the relevant US laws (CLOUD Act, FISA 702), assessment of how they impinge on SCCs, the technical supplementary measure adopted (customer-managed encryption with EEA-controlled keys), evidence that the provider cannot access unencrypted data, and a monitoring commitment. Supporting technical evidence includes architecture diagrams, key management procedures, HSM deployment records, and audit logs demonstrating access controls are operational.
NIS2 requires essential and important entities to assess ICT supply chain security risks, including providers’ exposure to non-EU government access demands. DORA requires financial entities to evaluate concentration risk and confidentiality obligations for critical ICT third-party providers. Both require documented risk assessments addressing CLOUD Act exposure. Using a US provider without technical controls may constitute an unmitigated supply chain risk management gap under NIS2 Article 21 or an undocumented ICT third-party risk under DORA.
Additional Resources