The CLOUD Act vs GDPR: The Unresolved Conflict Behind Sovereign Cloud

Seven years after both laws took effect, the US CLOUD Act and the EU’s GDPR still directly contradict each other, with no formal reconciliation mechanism, and every organisation running EU personal data through a US-controlled cloud provider is operating inside that unresolved contradiction whether or not anyone has told them so.

I’ve written about residency versus sovereignty as a conceptual distinction, and about the SEAL framework that now scores it. This is the specific legal mechanism underneath both: the actual conflict between the two statutes, why it’s never been cleanly resolved, and what that means practically for an organisation trying to operate honestly within it.

What each law actually requires, and why they can’t both be satisfied

The CLOUD Act compels US-headquartered companies to produce data on request from US law enforcement, regardless of where that data is physically stored — a Frankfurt-hosted dataset, if the hosting company is American, remains reachable by a US legal order. GDPR’s Article 48 requires that transfers of personal data to a third country’s authorities happen only through a mutual legal assistance treaty or equivalent international agreement — a unilateral CLOUD Act order doesn’t meet that bar. A US provider receiving a valid CLOUD Act request and a GDPR-covered customer’s data protection obligations are, at that moment, genuinely incompatible: complying with the US order risks violating GDPR; refusing risks violating US law. Neither party in that exchange has a clean way to satisfy both.

Why the Data Privacy Framework doesn’t actually fix this

The EU-US Data Privacy Framework, adopted in 2023 as the current adequacy mechanism for commercial data transfers, addresses a different question — the ordinary, non-law-enforcement transfer of data between companies — and does not touch the CLOUD Act’s separate, unilateral law-enforcement access power at all. A company certified under the DPF can still receive a CLOUD Act order, and the DPF provides no shelter from it. The Framework also carries its own instability: it follows directly in the wake of Schrems II, which invalidated the DPF’s predecessor on substantially similar grounds, and privacy advocates and several data protection authorities have signalled that a further legal challenge remains a live possibility — meaning organisations relying on the DPF as their primary transfer mechanism are relying on a framework whose durability is itself an open question.

What this actually means for an honest risk assessment

The practical implication isn’t that every use of a US-headquartered cloud provider is unlawful — for most commercial data, the practical risk remains low and the regulatory tolerance for it, so far, has been correspondingly measured. It’s that an organisation’s honest Transfer Impact Assessment, the document GDPR effectively requires to justify a transfer, has to actually acknowledge the CLOUD Act exposure rather than treating an EU hosting region or a DPF certification as if either one resolved it — because neither does, and a Transfer Impact Assessment that asserts otherwise is documenting a legal position the European judiciary has already shown willingness to reject once.

For data genuinely sensitive enough that this exposure matters — the same category that justifies the sovereignty rigour I’ve written about generally — the only architectural answer that actually closes the gap is control, not contract: EU-controlled infrastructure, EU-controlled encryption keys, and a provider whose own legal chain doesn’t run back to a US parent’s CLOUD Act exposure. Contractual language, however carefully drafted, cannot override a US company’s statutory obligation to comply with a valid US legal order.

What an honest assessment actually found

A Cyprus-based investment firm’s Transfer Impact Assessment, drafted several years earlier, asserted that EU-region hosting and Standard Contractual Clauses together satisfied the firm’s GDPR transfer obligations for client data processed on a major US cloud platform. A fresh legal review, prompted by an institutional client’s own due-diligence question, found the assessment had never actually addressed the CLOUD Act exposure at all — it had been drafted before the firm’s compliance team had fully internalised that residency and sovereignty were different questions. The honest revised assessment didn’t necessarily require migrating providers immediately, but it did require acknowledging the exposure explicitly, pricing it into the firm’s risk register, and setting a genuine timeline for closing it rather than continuing to assert a position the assessment itself couldn’t actually support.

Assessing whether a specific data flow’s actual CLOUD Act exposure has been honestly acknowledged in its Transfer Impact Assessment — rather than assumed away by hosting region or DPF certification alone — is exactly the kind of legal-architecture review a technology control assessment is built to support.

None of this requires panic or an immediate migration for every organisation reading it. It requires an honest assessment, on paper, that actually names the exposure — which most current Transfer Impact Assessments, written before this conflict was as widely understood as it now is, simply don’t.

This is the specific legal mechanism underneath the broader distinction covered in residency versus sovereignty.

Revisiting an existing Transfer Impact Assessment against this specific question is usually a matter of days, not months — the harder part is deciding what to do once the honest gap is actually visible on paper.