Compliance · Data jurisdiction

The CLOUD Act Explained: How a US Law Reaches Data Stored Anywhere

The CLOUD Act is short, technical, and quietly one of the most consequential laws for anyone choosing where to host data. It rarely produces a dramatic headline, yet it sits behind every serious conversation about data sovereignty, every European procurement clause about “third-country law,” and every claim that a Canadian or EU data centre keeps data out of foreign reach. This explainer covers what the law actually says, what it does and does not do, and why it reframes data residency as a question of provider ownership. None of it is legal advice.

What is the CLOUD Act?

The CLOUD Act — the Clarifying Lawful Overseas Use of Data Act — was signed into US law in March 2018, tucked into an omnibus spending bill. Legally, it amended the Stored Communications Act, the 1986 law governing US law-enforcement access to electronic data, adding a provision clarifying that US legal process applies to data in a provider’s possession, custody, or control regardless of whether it sits inside or outside the United States.

It exists because of a single case. In a 2013 investigation, the FBI served a warrant for emails a suspect had stored on Microsoft’s servers in Dublin; Microsoft refused, arguing the Stored Communications Act did not reach data held abroad, and an appeals court agreed. The dispute reached the Supreme Court as United States v. Microsoft, but Congress passed the CLOUD Act before a ruling, explicitly granting the reach Microsoft had contested and rendering the case moot. The law was, in effect, Congress closing the gap the courts had opened.

What does the CLOUD Act actually do?

It does two main things, plus a safety valve. The first is extraterritorial reach: US authorities can compel a covered provider to produce data it controls no matter where that data is stored, which eliminates physical location as a defence. The second is executive agreements — a framework letting the US sign bilateral deals with trusted governments so each side’s law enforcement can send direct, targeted requests to providers in the other country, bypassing the slow mutual legal assistance treaty process.

The safety valve is the comity mechanism. A provider can file a motion to quash or modify an order if complying would conflict with a qualifying foreign government’s law, and a court then performs a “comity analysis” weighing the specificity of the request, where the data originated, and the competing national interests. The single sentence that captures the whole law is this: it shifts jurisdiction from where the data sits to who controls it. Once you internalise that, every downstream consequence follows.

Who is subject to the CLOUD Act?

This is where many people underestimate its scope. The law applies to any provider of electronic communications or remote computing services that operates or has a legal presence in the United States — not just companies headquartered there, but any firm with sufficient US contacts, and crucially their foreign subsidiaries. A European subsidiary of a US company does not escape the reach simply by being incorporated abroad.

In practice that means the major cloud and communications providers — the large American hyperscalers and platform companies — are all squarely covered, as are their regional arms. The test is not the flag on the building or the country in the billing address; it is whether the entity that controls the data is reachable by US legal process. If the company answering your support tickets ultimately rolls up to a US parent, the CLOUD Act applies to your data through that parent, wherever the servers happen to live.

Executive agreements: the UK, Australia, and the EU gap

The executive-agreement framework is the law’s second engine, and its rollout has been deliberate. The first agreement, between the US and the United Kingdom, came into force in October 2022, creating a government-to-government channel for direct requests in serious-crime cases. Australia followed as the second partner. These agreements remove the local blocking laws that would otherwise stop a provider from responding, and they come with guardrails: requests must be targeted rather than bulk, limited to serious crime, subject to independent review, and barred from intentionally targeting US persons.

The conspicuous absence is the European Union, which has no such agreement with the US. That gap is not a technicality — it is the heart of the legal tension, because without an agreement there is no streamlined, lawful channel reconciling a US demand with EU law. The EU’s own e-evidence package, applying across member states from August 2026, addresses cross-border evidence within Europe but does not resolve the conflict with US compulsion. For now, EU data sits in the hardest position of all.

The conflict with GDPR and foreign law

The clash with European law is direct and unresolved. GDPR Article 48 states that a foreign court order is not, by itself, a lawful basis to transfer personal data out of the EU — disclosure must rest on an international agreement such as a mutual legal assistance treaty. The CLOUD Act bypasses exactly that channel. So a US provider served with a CLOUD Act order for EU data faces an impossible choice: comply and breach GDPR, risking fines up to four percent of global turnover, or refuse and risk US contempt sanctions. There is no option that satisfies both regimes.

This conflict is precisely what the Court of Justice cited in the 2020 Schrems II ruling, which invalidated the EU-US Privacy Shield on the grounds that US access laws did not give EU data adequate protection — a decision our Schrems II explainer covers in full. A second, quieter conflict compounds it: gag orders under the Stored Communications Act often bar the provider from telling the customer their data was disclosed at all, which collides with GDPR’s transparency rights. And the CLOUD Act is only the floor — national-security tools like FISA Section 702 reach further still, with even fewer safeguards.

What the CLOUD Act does not do

It is worth being precise about the limits, because the law is sometimes described as blanket surveillance, which it is not. The CLOUD Act authorises targeted legal process for specific investigations, not bulk collection; executive-agreement requests must be case-specific and tied to serious crime. The US Justice Department argues the law only removes conflicts of law rather than granting access the government could not otherwise obtain, and providers still respond under defined legal triggers, not open-ended demands.

The reassurance has limits, though, and they cut the other way for compliance. Transparency reports suggest US authorities actually obtain enterprise content stored in Europe rarely — one major provider reported a few hundred enterprise requests in a half-year — but rarity is a red herring. For a regulator, what matters is not the per-request probability but the structural risk: a single enforcement action over an unlawful transfer can cost four percent of turnover, and the transparency numbers undercount because gag-ordered and classified requests never appear. Low frequency does not equal low risk.

# 18 U.S.C. 2713 — the sentence that does the work:
“…data within the provider’s possession, custody, or control,
 regardless of whether located within or outside the United States.”
 
# Are you exposed? Walk the questions, not the marketing:
Is the provider (or its PARENT) US-incorporated or US-present?  -> exposed
Is your jurisdiction covered by a CLOUD Act agreement?          -> EU: no
Who holds the encryption keys — you, or the provider?           -> decisive
Where do backups, logs, and admin access actually resolve?      -> audit all
# A Canadian/EU data centre under a US parent does NOT remove exposure.

Residency is not protection: the real exposure

Here is the consequence that matters most when you choose where to host. Because the law follows the provider rather than the server, putting your data in a Canadian or European data centre gives you no protection from the CLOUD Act if the provider operating that data centre is US-owned or US-controlled. Data residency — the physical location of storage — and the reach of US law are simply different things, and conflating them is the most common and costly mistake organisations make.

This is the same residency-versus-sovereignty distinction that governs any cross-border hosting decision, explored in our data residency explainer and applied practically in choosing a Canadian host. The reframing is simple but uncomfortable: the question is no longer “is my data stored in my country” but “can anyone reachable by a foreign legal order compel its disclosure.” Once you ask it that way, a glossy in-region data-centre badge stops being reassuring on its own, and you start looking at ownership, control of administrators, and custody of keys.

How do you reduce CLOUD Act exposure?

Mitigation runs along a spectrum from structural to contractual, and the structural options are the only ones that truly close the gap. The strongest is to use a provider with no US nexus at all — a Canadian-owned or European-owned operator, or self-hosted open-source software on infrastructure you control — because a provider not subject to US jurisdiction cannot be compelled under the Act. Short of that, encryption changes the calculus: client-side end-to-end encryption, or application-level encryption with keys held in your own key-management system, means a compelled provider can only produce ciphertext it cannot decrypt.

Contractual and procedural measures help at the margins but cannot override a statute. A clause committing a provider to challenge foreign orders, or to notify you where legally permitted, is worth having, yet it does not change the fact that US law compels disclosure and gag orders may forbid notice. The practical posture for sensitive data is layered: prefer a non-US-controlled provider, hold your own keys, scrutinise sovereign-cloud claims down to who controls the administrators and infrastructure, and track which executive agreements cover your jurisdiction. Marketing that promises an “in-region boundary” without addressing ownership is not addressing the CLOUD Act at all, and a buyer who cannot say who controls the administrators and the keys has not yet answered the only question the law actually turns on.

What it means for choosing where your data lives

For most senders and operators the CLOUD Act is not a reason to panic, but it is a reason to choose deliberately. If your data is non-sensitive and you have no sector or contractual residency obligation, a US-controlled provider may be perfectly acceptable — the reach exists, but so do bigger risks you already accept. The calculation changes when you hold regulated personal data, operate under European or sector rules, or serve customers who demand sovereignty in their contracts; there, the provider’s jurisdiction becomes a first-order decision rather than a footnote.

The clean way through is to match the provider to the sensitivity of the data. Keep ordinary workloads wherever they run best, and place the data that genuinely needs jurisdictional protection with a provider outside US control, behind keys you hold. A Toronto-based, Canadian-operated option such as our dedicated servers in Toronto keeps both the data and the controlling entity in Canada, which is the combination — not residency alone — that actually answers the CLOUD Act. The related HIPAA and PCI-DSS hosting guides cover the sector regimes that often sit alongside this decision.