How U.S. Companies Can Comply with EU Data Sovereignty Laws When Serving European Customers

U.S. companies doing business in the European Union face a compliance challenge unlike any other: two bodies of law, pulling in opposite directions, both of which apply to them simultaneously. The EU’s GDPR compliance obligations follow the data subject — any U.S. company handling EU residents’ personal data must comply with GDPR regardless of where it is headquartered. The U.S. CLOUD Act follows the provider — any U.S. company must produce data it controls upon receiving a valid U.S. government demand, regardless of where that data is stored.

The paradox is real: a U.S. company storing EU customer data is simultaneously obligated to protect it from unauthorized access under GDPR and legally compelled to disclose it under U.S. law. Standard Contractual Clauses document an intent to protect. They cannot override the CLOUD Act. This is not a gap that better contracts can close — it is a structural conflict that only architectural sovereignty can resolve.

Executive Summary

Main Idea: U.S. companies serving EU customers are subject to full GDPR obligations through its extraterritorial reach — including Articles 44–49 cross-border transfer restrictions, Article 32 technical security requirements, and post-Schrems II Transfer Impact Assessments. At the same time, U.S. law compels data disclosure, creating an irresolvable tension that contracts cannot address. Genuine data sovereignty compliance for U.S. companies means deploying architecture that separates EU customer data from U.S. legal exposure: single-tenant European deployment, customer-controlled encryption keys held outside U.S. infrastructure, and policy-enforced data residency that places EU data under European jurisdiction.

Why You Should Care: GDPR’s extraterritorial reach has teeth. DPAs have levied fines against U.S. companies with no EU establishment, and Austrian, French, and Italian DPAs have explicitly ruled that routing EU personal data through U.S.-controlled cloud infrastructure violates GDPR under Schrems II. Fines reach 4% of global annual revenue. Compliance is not optional — and the standard is higher than most U.S. legal teams realize.

Key Takeaways

1. GDPR applies to U.S. companies regardless of location. GDPR Article 3 establishes extraterritorial jurisdiction: any organization offering goods or services to EU residents, or monitoring their behavior, is subject to full GDPR obligations. No EU office does not mean no GDPR — it means a requirement to appoint an EU representative under Article 27.
2. The CLOUD Act and GDPR create a genuine legal conflict. U.S. law compels disclosure of data U.S. companies control; EU law requires them to protect EU personal data from unauthorized foreign access. SCCs satisfy GDPR’s transfer documentation requirement but cannot override U.S. legal compulsion. Architecture must resolve what contracts cannot.
3. Storing EU data on U.S.-controlled infrastructure does not satisfy post-Schrems II requirements. Transfer Impact Assessments for U.S. provider arrangements must identify CLOUD Act and FISA 702 as active risks requiring technical supplementary measures — not just contractual ones. TIAs that acknowledge risk without technical mitigation do not meet the EDPB standard.
4. Customer-controlled encryption keys are the technical resolution to the CLOUD Act paradox. When EU customer data is encrypted with keys held in European infrastructure outside U.S. control, a CLOUD Act demand yields only ciphertext the U.S. company cannot decrypt — satisfying both the CLOUD Act’s disclosure obligation and GDPR’s protection requirement simultaneously.
5. U.S. companies in regulated sectors face GDPR plus sector-specific EU obligations. U.S. SaaS providers serving EU financial services customers must address DORA. U.S. vendors serving EU covered entities under NIS 2 must pass supply chain sovereignty assessments. GDPR is the floor, not the ceiling.

GDPR’s Extraterritorial Reach: What U.S. Companies Are Actually Required to Do

The first thing many U.S. compliance teams get wrong about GDPR is scope. Article 3 applies to any organization — regardless of establishment location — that processes the personal data of EU residents in connection with offering goods or services to them, or monitoring their behavior. A U.S. SaaS company with German customers is subject to GDPR. A U.S. manufacturer with EU employee data is subject to GDPR. The test is not corporate address — it is whether EU residents’ data is being processed.

U.S. companies with no EU establishment must appoint an EU-based representative under Article 27. Beyond that structural requirement, the substance of GDPR obligations applies in full: lawful basis for processing, data subject rights, 72-hour breach notification, Data Protection Impact Assessments for high-risk processing, and the Chapter V transfer restrictions governing what happens when EU personal data reaches U.S. systems.

For most U.S. companies, the operative transfer mechanism is Standard Contractual Clauses. But post-Schrems II, SCCs alone are no longer sufficient. Organizations must conduct Transfer Impact Assessments — documented evaluations of whether U.S. surveillance law undermines the SCCs’ effectiveness for the specific transfer. For any U.S. company processing EU personal data on U.S.-controlled infrastructure, that assessment must honestly address the CLOUD Act and FISA Section 702 as active legal authorities capable of compelling data disclosure without European judicial oversight. A TIA that acknowledges this risk without identifying adequate technical supplementary measures does not satisfy Schrems II.

The CLOUD Act Paradox: Why the Legal Conflict Cannot Be Contracted Away

The CLOUD Act (2018) requires U.S. companies to respond to valid U.S. government demands for data they store or control — including data stored in European data centers. Its reach follows corporate control, not geography. A U.S. company’s Frankfurt data center is subject to CLOUD Act compulsion through its U.S. corporate structure, regardless of where the servers physically sit.

GDPR requires those same companies to protect EU personal data from exactly this kind of unauthorized foreign government access. DPAs, following Schrems II, treat U.S. government CLOUD Act access as the specific risk transfer mechanisms must address. When a U.S. company’s TIA acknowledges CLOUD Act exposure but offers only contractual mitigations — notification commitments, challenge procedures — the EDPB is clear: these are contractual supplementary measures, and they are insufficient where U.S. law makes compliance mandatory regardless of contract terms.

The resolution must come from architecture, not contracts. The only technical control the EDPB has identified as genuinely addressing CLOUD Act exposure is customer-controlled encryption with keys held entirely outside U.S. infrastructure. When the EU customer holds the encryption keys in their own European HSM, a CLOUD Act demand against the U.S. provider yields only ciphertext. The provider cannot decrypt it. The CLOUD Act demand is technically satisfied; the GDPR protection obligation is architecturally maintained. Architecture makes simultaneous compliance with both laws possible — by making it technically impossible to provide the readable content that would create the GDPR violation.

Four Compliance Requirements U.S. Companies Must Meet

Separate EU customer data from U.S. legal exposure through deployment architecture. EU personal data stored on U.S.-controlled infrastructure — even in an EU data center — remains subject to CLOUD Act compulsion through the corporate parent. The solution is single-tenant European deployment: dedicated infrastructure in an EU data center, operated by EU-based personnel with EU-based administrative access, under a contractual structure placing data under EU jurisdiction. This means choosing European cloud providers or customer-owned infrastructure for the EU deployment — not a U.S. hyperscaler’s EU region, which remains under U.S. corporate control.

Implement customer-controlled encryption with keys outside U.S. infrastructure. Customer-managed encryption (BYOK/BYOE) with keys generated and stored by the EU customer in their own European HSM — never transmitted to the U.S. provider — closes the CLOUD Act gap architecturally. The U.S. company can represent in its TIA that it lacks the technical capability to produce readable EU customer data in response to a CLOUD Act demand. This transforms the TIA conclusion from “we have contractual mitigations” (insufficient) to “we are technically incapable of complying with a decryption demand” (sufficient under EDPB guidance).

Implement policy-enforced data localization controls. Technical geofencing — infrastructure-level controls that prevent EU customer data from being replicated or processed outside designated EU regions — satisfies the EDPB’s requirement for technical rather than contractual residency controls. Contractual commitments without technical enforcement fail the post-Schrems II standard. Data must be architecturally unable to leave EU infrastructure regardless of administrative action or configuration.

Maintain audit documentation sufficient for EU DPA inquiry. GDPR Article 30 requires Records of Processing Activities. NIS 2 and DORA flow supply chain assessment requirements through to U.S. vendors serving covered EU entities. In each case the standard is demonstrable evidence — immutable audit logs, architecture documentation, key custody records, and Transfer Impact Assessments. U.S. companies that cannot produce this evidence when an EU customer’s DPA comes calling are not compliant regardless of contracts. Third-party risk management requirements mean EU customers are assessing U.S. vendors against exactly this standard before signing — not just after incidents.

Sector-Specific Obligations U.S. Companies Cannot Ignore

GDPR is the baseline, but U.S. companies serving EU customers in regulated sectors face additional sovereignty obligations on top. U.S. SaaS providers whose EU customers are financial services entities must address DORA compliance as ICT third-party providers — including Article 30’s mandate that contracts address data sovereignty, encryption key management, and exit strategies. U.S. technology companies serving EU healthcare organizations must address national health data laws beyond GDPR’s special category protections. U.S. companies serving EU government entities face national sovereignty procurement requirements that explicitly exclude U.S. provider arrangements regardless of contractual safeguards.

The NIS 2 Directive’s supply chain security mandate is particularly consequential: it requires EU-covered entities to assess the sovereignty posture of their ICT suppliers. U.S. vendors that cannot demonstrate genuine architectural sovereignty — not just GDPR compliance documentation — fail EU customer vendor assessments. Losing EU enterprise contracts because procurement concludes that a U.S. vendor’s CLOUD Act exposure creates unacceptable sovereignty risk is an increasingly common commercial consequence of inadequate architecture.

How Kiteworks Resolves the Compliance Paradox for U.S. Companies

U.S. companies serving EU customers cannot opt out of GDPR through corporate geography, resolve the CLOUD Act conflict through better contracts, or satisfy post-Schrems II TIA standards with EU data under U.S. legal control. The compliance path is architectural: EU customer data separated from U.S. legal exposure through genuine European deployment, customer-controlled encryption that makes decryption technically impossible for the U.S. provider, and technical residency controls that make geographic compliance demonstrable rather than merely promised.

U.S. companies that get this right avoid enforcement risk and gain competitive advantage in EU markets where sovereignty is increasingly a procurement requirement. Kiteworks delivers the architectural sovereignty that makes EU compliance genuine: your EU customers’ data, under their jurisdiction, encrypted with their keys, inaccessible to anyone — including U.S. authorities — without their authorization.

Kiteworks was built on the principle that data should remain under the control of whoever owns it — in their jurisdiction, encrypted with their keys, inaccessible to anyone they haven’t authorized. For U.S. companies serving EU customers, that principle translates directly into the architectural resolution of the CLOUD Act/GDPR conflict.

The Kiteworks Private Data Network deploys as a dedicated, single-tenant instance in the EU customer’s chosen European data center — the customer’s own infrastructure, a European cloud provider, or Kiteworks-hosted EU infrastructure. No shared components. 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 the EU customer holds the keys — Kiteworks cannot decrypt customer data. A CLOUD Act demand served on Kiteworks yields only ciphertext. The U.S. legal obligation is technically satisfied; the GDPR protection obligation is architecturally maintained.

Policy-enforced geofencing ensures EU customer data cannot leave designated European regions, providing the technical residency controls post-Schrems II TIAs require. Zero trust security architecture governs all access — including administrative — with every action captured in an immutable audit trail visible through the CISO Dashboard. Pre-configured compliance reporting for GDPR, NIS 2, DORA, and ISO 27001 gives EU customers the documentation they need for their own DPA inquiries and vendor assessments. All channels — email, file sharing, MFT, web forms, and APIs — governed under a single platform with consistent sovereignty controls across every data exchange.

To learn how Kiteworks helps U.S. companies achieve data sovereignty compliance for EU customer operations, 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]