Can I Use a U.S.-Based Cloud Provider If My Data Must Remain Within the EU?
The short answer is: conditionally. A U.S.-based cloud provider with EU data centres is not automatically disqualified from hosting EU-resident data — but compliant use requires more than choosing a Frankfurt or Dublin server region. Most organisations that believe they have resolved this question through geographic selection have not. They have changed the address of their data without changing its legal exposure.
This post addresses three questions: whether U.S. providers can be used at all, which data categories carry the strictest sovereignty restrictions, and what safeguards are required to make any arrangement genuinely compliant.
Executive Summary
Main Idea: U.S.-based cloud providers can legally host EU-resident data only where specific technical and legal safeguards are in place — safeguards that go beyond EU server selection to address the structural problem that U.S. law applies to U.S. companies regardless of where their servers are located. The U.S. CLOUD Act and FISA Section 702 create government access exposure that the EU-US Data Privacy Framework does not eliminate and Standard Contractual Clauses alone cannot address. The required solution is architectural: customer-controlled encryption with keys outside the provider’s infrastructure, making the provider technically incapable of producing readable EU data regardless of legal compulsion.
Why You Should Care: EU data protection authorities have issued enforcement decisions ruling that certain U.S. cloud provider arrangements violate GDPR regardless of server location. The NIS 2 Directive, DORA, and sector-specific national laws impose additional sovereignty obligations with penalties reaching 4% of global revenue. Organisations that have not reviewed their U.S. provider arrangements against post-Schrems II standards are carrying active enforcement exposure.
Key Takeaways
- EU server location does not equal EU jurisdiction. A U.S. provider’s Frankfurt data centre remains subject to U.S. legal demands through the provider’s corporate structure. Geography changes where data sits; it does not change which government can compel access to it.
- The EU-US Data Privacy Framework does not repeal the CLOUD Act. The DPF provides a transfer mechanism for personal data under GDPR — it does not remove U.S. surveillance law obligations from U.S. providers. CLOUD Act demands remain valid regardless of DPF participation.
- Some data categories face restrictions that effectively prohibit U.S. provider use without architectural sovereignty controls. Health data under national health data laws, financial data under DORA, classified government data, and certain categories of personal data identified as high-risk under GDPR Article 9 all carry restrictions that generic U.S. provider SCC arrangements cannot adequately address.
- Compliant use of a U.S. provider requires specific technical safeguards, not just legal documentation. Post-Schrems II, the EDPB has identified customer-controlled encryption with keys outside the provider’s infrastructure as the required technical supplementary measure. Contractual commitments are insufficient where U.S. law mandates provider compliance regardless of contract terms.
- The architectural alternative is single-tenant European deployment with customer-managed encryption. This resolves the CLOUD Act problem structurally: the provider cannot produce readable data because it never possessed the keys — making simultaneous compliance with U.S. legal obligations and EU data protection requirements technically possible.
A Complete Checklist of GDPR Compliance
The Core Problem: Jurisdiction Follows the Corporation, Not the Server
The assumption underlying most “EU data centre” arrangements is that physical data location determines legal jurisdiction. It does not. The US CLOUD Act (2018) requires U.S. companies to produce data they control in response to valid government demands regardless of where it is stored. A demand served on a U.S. provider’s headquarters compels production of data from its EU servers. The provider’s server address is irrelevant; its corporate nationality is what triggers U.S. legal reach. FISA Section 702 extends this to communications data under national security authorities. Neither instrument requires EU-compatible judicial oversight or customer notification.
This is not a theoretical risk. Austrian, French, and Italian data protection authorities have issued enforcement decisions concluding that certain U.S. cloud arrangements violate GDPR specifically because CLOUD Act exposure was not adequately addressed by the safeguards in place.
What the EU-US Data Privacy Framework Does — and Doesn’t — Resolve
Many organisations assume the EU-US Data Privacy Framework, adopted in 2023, resolved the Schrems II problem. It did not. The DPF provides a transfer adequacy mechanism under GDPR Article 45 — a legal basis for transferring EU personal data to certified U.S. companies. What it does not do is repeal the US CLOUD Act. U.S. providers certified under the DPF remain legally obligated to comply with valid CLOUD Act demands. The DPF answers whether there is a lawful basis for the transfer; it does not answer whether a U.S. government demand could compel the provider to produce EU data.
The DPF also faces active legal challenges from NOYB — the organisation that brought down Privacy Shield in 2020. Organisations whose compliance posture rests entirely on DPF certification carry the same invalidation risk that erased Privacy Shield arrangements. Customer-controlled encryption provides protection that survives any transfer mechanism’s legal status, because the data is never practically accessible to the provider regardless of which framework governs the transfer.
Which Data Types Face the Strictest Sovereignty Restrictions
Not all data carries equal sovereignty risk. Five categories trigger the most restrictive requirements under EU and national frameworks.
Special category personal data (GDPR Article 9). Health, biometric, genetic, and other sensitive categories require a specific legal basis beyond standard GDPR grounds, and transfers must satisfy both Chapter V and the Article 9 basis simultaneously — a dual requirement that generic SCC arrangements often fail to address.
Health and patient data. National health data laws impose restrictions beyond GDPR. France requires health data to be processed on French-sovereignty infrastructure. Germany imposes equivalent patient data protections. Several national frameworks effectively prohibit U.S.-headquartered providers for health data without infrastructure-level sovereignty controls, regardless of SCC arrangements.
Financial services data. DORA (operational since January 2025) requires financial entities and their ICT providers to include contractual provisions covering data localisation, key management, and exit strategies. EBA outsourcing guidelines require documented sovereignty assessments. EU financial entities using U.S. cloud providers without adequate key management arrangements are currently non-compliant.
Government and defence-adjacent data. Classified data, defence contractor data, and data subject to national public sector cloud policies frequently cannot legally be processed on U.S.-headquartered infrastructure under any transfer mechanism. Most EU member states have explicit restrictions on government data processing through non-European providers.
Critical infrastructure operational data. NIS 2 Article 21 requires operators of essential services — energy, transport, healthcare, water, financial and digital infrastructure — to assess cloud provider sovereignty posture as part of mandatory supply chain security obligations. The acceptable threshold for CLOUD Act exposure in these contexts is significantly higher than for general commercial data.
Required Technical and Legal Safeguards
For organisations that determine a U.S. provider arrangement can be made compliant, four safeguards are required.
Transfer Impact Assessment with honest CLOUD Act evaluation. A TIA whose conclusion is grounded in technical controls, not contractual commitments. A TIA that acknowledges CLOUD Act risk but relies on notification procedures as mitigation does not meet the post-Schrems II standard — the assessment must conclude that a valid demand would not result in readable EU data being produced, and that conclusion must be architecturally grounded.
Customer-controlled encryption with keys outside the provider’s infrastructure. The EDPB’s Recommendations 01/2020 identify this as the required technical supplementary measure: customer-generated keys held in HSMs under the EU customer’s exclusive control, never held by the U.S. provider. Without this, any TIA acknowledging CLOUD Act exposure cannot validly conclude that the transfer is adequately protected.
Infrastructure-level data residency enforcement. Contractual data localisation clauses are contractual supplementary measures. Policy-enforced geofencing that prevents data from leaving designated EU regions regardless of configuration is a technical one. Post-Schrems II, the distinction matters for DPA enforcement assessment.
Immutable audit trails and ongoing accountability documentation. GDPR’s accountability principle requires ongoing demonstration of compliance. Immutable audit logs, key management records, and regularly reviewed TIAs are the minimum standard. For DORA and NIS 2, this documentation must be available to regulators on request.
How Kiteworks Delivers Compliant EU Data Sovereignty
The Kiteworks Private Data Network addresses the structural problem directly. Single-tenant deployment in the EU customer’s chosen location — on-premises, European private cloud, or Kiteworks-hosted EU infrastructure — places data under European jurisdiction rather than U.S. corporate control. Customer-managed encryption (BYOK/BYOE) with FIPS 140-3 Level 1 validated encryption means Kiteworks never holds customer keys: a CLOUD Act demand yields only ciphertext. The TIA conclusion is architecturally grounded — Kiteworks is technically incapable of producing readable data, not merely contractually committed to protecting it. Policy-enforced geofencing implements data residency at the infrastructure level across all channels — email, file sharing, MFT, web forms, and APIs. The CISO Dashboard provides immutable audit trails across every data movement. Pre-configured compliance reporting for GDPR, NIS 2, DORA, and ISO 27001 supports ongoing accountability and regulatory inquiry response across the data categories with the most restrictive sovereignty requirements.
To discuss your organisation’s specific data sovereignty requirements and how Kiteworks addresses them, schedule a custom demo today.
Frequently Asked Questions
No. Selecting an EU data centre region changes where data is physically stored; it does not change which government can legally demand access to it. The US CLOUD Act applies to U.S.-headquartered providers regardless of server location — a valid demand compels production of data from EU servers through the provider’s corporate structure. Meeting EU data sovereignty compliance requirements for U.S. provider arrangements requires customer-controlled encryption with keys outside the provider’s infrastructure, not EU region selection.
No. The DPF provides a transfer adequacy mechanism under GDPR Article 45 — a legal basis for transferring EU personal data to certified U.S. companies. It does not repeal or limit the US CLOUD Act. U.S. providers certified under the DPF remain legally required to comply with valid CLOUD Act demands. The DPF addresses the transfer mechanism question; it does not address whether a U.S. government demand could compel the provider to produce EU data. The DPF also faces active legal challenges and could be invalidated, as Privacy Shield was in 2020 — making architectural sovereignty controls a more durable protection than DPF reliance alone.
Five categories carry the most restrictive requirements: GDPR Article 9 special category personal data; patient and health data under national frameworks (France, Germany, and others); financial services data under DORA and EBA outsourcing guidelines; government and defence-adjacent data under national public sector cloud policies; and critical infrastructure operational data under NIS 2 supply chain security requirements. For government and health data specifically, U.S. provider use may be effectively prohibited without infrastructure-level sovereignty controls, regardless of transfer mechanism or contractual arrangement.
Post-Schrems II, the minimum required safeguards are: a Transfer Impact Assessment honestly evaluating US CLOUD Act and FISA 702 exposure with a conclusion grounded in technical controls; customer-controlled encryption with keys held exclusively outside the provider’s infrastructure (the EDPB’s required technical supplementary measure); infrastructure-level data residency enforcement rather than contractual data localisation commitments; and immutable audit trails supporting ongoing GDPR accountability obligations. Organisations that have only contractual safeguards in place — standard contractual clauses, DPAs, notification commitments — without the architectural layer have not met the post-Schrems II standard, regardless of documentation completeness.
For certain data categories and organisational profiles, yes. Government data subject to national sovereignty policies, health data under stringent national frameworks, and data classified under security legislation may effectively require European-controlled infrastructure regardless of what technical safeguards a U.S. provider offers. For these organisations, single-tenant deployment on European infrastructure — through a European cloud provider, on-premises, or through a platform like Kiteworks deployed on EU-controlled infrastructure — is the appropriate solution. The architectural controls Kiteworks provides (customer-managed encryption, single-tenant deployment, policy-enforced geofencing) are available across all deployment models, including fully European ones that remove U.S. corporate control entirely.
Additional Resources