The US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) is short, but its reach is long. It clarified that US providers must hand over data in their “possession, custody or control” in response to a lawful US order — regardless of where in the world the data is stored. For a Belgian organisation using a US-owned cloud, that means data sitting in a Brussels or Frankfurt data centre can still be in scope of a US demand. This is the heart of the European data-sovereignty debate.
TL;DR — the conflict in 5 points
- The CLOUD Act reaches data held by US providers anywhere, including the EU.
- It applies based on the provider’s nationality, not the data’s location.
- GDPR Art. 48 says a foreign court order is not, by itself, a lawful ground to transfer EU data.
- A US provider can be caught between two laws — the source of genuine legal risk.
- EU data location is necessary but not sufficient for sovereignty; the operator’s legal exposure matters.
What the CLOUD Act actually does
It amended the Stored Communications Act in three ways. First, extraterritorial reach: US authorities can compel disclosure by US-based or US-controlled providers no matter where data is stored. Second, a comity mechanism: providers can move to quash or modify an order that conflicts with the law of a qualifying foreign government. Third, executive agreements: a framework for fast government-to-government data requests between the US and partner countries. The key takeaway for buyers is the first point — storing data “in the EU” with a US provider does not place it beyond US reach.
Why it collides with the GDPR
The GDPR was built around independent judicial oversight and explicit legal bases for moving data outside the EU. Article 48 is explicit: a judgment or decision of a third-country authority requiring a transfer or disclosure of personal data is only recognised or enforceable if it rests on an international agreement such as a mutual legal assistance treaty. In other words, a unilateral US order is not a GDPR-valid basis on its own; the provider would also need an Art. 46 safeguard or an Art. 49 derogation, neither of which fits a routine law-enforcement demand. A US provider that complies with the CLOUD Act may therefore breach the GDPR, and a provider that refuses may breach US law. That bind — not the data’s postcode — is the real risk.
Where this leaves the Schrems II world
This sits on top of the international-transfer rules. After Schrems II, transfers to the US rely on Standard Contractual Clauses plus supplementary measures, or on the EU–US Data Privacy Frameworkadequacy decision for certified importers. None of that, however, neutralises a direct CLOUD Act order: government access is precisely the concern the supplementary-measures analysis is meant to address. For sensitive or regulated data, many Belgian organisations conclude that contractual mechanisms reduce but do not eliminate the sovereignty exposure.
What “data sovereignty” really requires
Sovereignty is a spectrum, not a checkbox. Three layers matter:
| Layer | Question it answers |
|---|---|
| Data residency | Where is the data physically stored? (Necessary, not sufficient.) |
| Operational sovereignty | Who can technically access it, and from where? Can support staff outside the EU see it? |
| Legal/jurisdictional sovereignty | Which laws can compel the operator to disclose? Is the operator subject to the CLOUD Act? |
EU residency answers only the first row. True resilience against extraterritorial access depends on the second and third — which is why the conversation has shifted from “where is it stored?” to “who controls the keys, the operations and the legal entity?”.
Practical options
You do not have to abandon hyperscalers to manage this. The realistic toolkit:
- Customer-managed encryption keys held in EU-controlled key management, so the provider cannot decrypt without you (limits, not eliminates, exposure).
- Sovereign or EU-operated cloud offerings, including partner-operated “trustee” models where a European entity controls operations.
- European providers not subject to US jurisdiction for the most sensitive workloads.
- Data classification so that only genuinely sensitive or regulated data triggers the strictest controls — most workloads do not.
We unpack the choices, costs and trade-offs in sovereign cloud in Belgium. Because personal data is usually involved, read this together with GDPR obligations and your transfer-impact assessments.
General information, not legal advice. ICTLAB helps Belgian organisations classify data and architect cloud that matches their sovereignty and compliance needs — explore our cloud services or talk to our team.