Data Privacy 8 min read · May 2026 · HubSecure Team

Why European Companies Should Stop Sending Client Data Through US Cloud Tools

The US CLOUD Act allows US law enforcement to compel data disclosure from US-headquartered companies — regardless of where that data is physically stored. For European companies processing regulated client data, this is a structural problem that EU standard contractual clauses do not solve.

TL;DR

When a European company chooses a cloud software provider, the primary questions are usually about functionality and price. The question of where the company is headquartered — and what legal obligations that creates for the provider — is rarely considered with the same rigour.

It should be. For companies processing regulated client data — client financial records, legal files, healthcare data, AML/KYC information — the jurisdictional status of their software providers is a compliance question, not just a commercial one.

What the CLOUD Act means for European companies

The Clarifying Lawful Overseas Use of Data Act (CLOUD Act), enacted by the US Congress in 2018, authorises US law enforcement agencies to compel US-headquartered companies to produce data stored on their servers — regardless of where those servers are physically located.

Prior to the CLOUD Act, a US law enforcement request for data stored in a European data centre would have needed to go through the Mutual Legal Assistance Treaty (MLAT) process, which is slow and involves the cooperation of European authorities. The CLOUD Act bypassed this by enabling direct orders to the US-headquartered company, without needing to go through the country where the data is stored.

The practical implication: if your client data is stored with a US-headquartered cloud provider — even in an EU data centre — US law enforcement can compel that provider to produce your clients' data without notifying you, without going through EU legal processes, and without the consent of European data protection authorities.

The CLOUD Act conflict with GDPR: GDPR Article 48 prohibits the transfer of personal data to a non-EU authority unless that transfer is authorised by an EU-US agreement or an EU member state law. A CLOUD Act order does not meet either of these conditions. This means that a US-headquartered provider complying with a CLOUD Act order for EU personal data is, in the view of many European data protection authorities, causing a GDPR violation — regardless of what the provider's terms of service say.

Which providers are affected

Any company incorporated in the United States — regardless of where its data centres are located — is subject to the CLOUD Act. This includes:

This is not an exhaustive list — it applies to essentially every major US-headquartered SaaS provider. The EU data centre option, which many providers offer as a "GDPR compliance" feature, does not remove CLOUD Act exposure. Data residency and legal jurisdiction are different things.

Why standard contractual clauses are not enough

The standard response from US-headquartered providers to GDPR compliance questions is that they offer EU Standard Contractual Clauses (SCCs) in their data processing agreements. SCCs are a mechanism for legitimising data transfers from the EU to third countries under GDPR — but they do not resolve the CLOUD Act conflict.

The CJEU's Schrems II judgment (2020) made clear that SCCs are only valid when the recipient country's legal framework does not undermine the protection they provide. For the United States, the CLOUD Act is exactly this kind of undermining legal framework: it allows the provider to be compelled to disclose data in ways that the SCCs explicitly prohibit.

SCCs require the provider to notify the data exporter of any legal orders that conflict with the SCCs and to challenge such orders where possible. But CLOUD Act orders frequently include gag provisions that prevent the provider from notifying the customer — making the SCC notification obligation effectively unenforceable.

The EDPB position: The European Data Protection Board has repeatedly stated that the existence of US surveillance laws, including the CLOUD Act, means that SCCs alone are not sufficient to legitimise transfers to US-headquartered providers without supplementary measures. The supplementary measures that adequately address CLOUD Act exposure are technically demanding and rarely implemented in practice.

The alternative: European-sovereign infrastructure

The structural solution to the CLOUD Act problem is to use a provider that is not subject to US jurisdiction. This means: headquartered in the EU (or EEA), operating infrastructure located entirely within the EU, with no US-based parent company, and no US-based subprocessors with access to unencrypted client data.

This is distinct from "EU data residency" as offered by US-headquartered providers. EU data residency addresses where data is stored. European sovereignty addresses the legal jurisdiction of the entity that controls that data — the jurisdiction that determines who can compel its disclosure.

EU data residency (US provider)

Data is stored in EU data centres. But the US-headquartered parent company retains control and remains subject to CLOUD Act orders. Storage location does not determine legal jurisdiction.

European sovereignty (EU provider)

Data is stored in EU data centres operated by an EU-headquartered company with no US parent. No CLOUD Act exposure. US law enforcement must use MLAT process, which requires EU authority cooperation.

How HubSecure handles data residency

HubSecure operates EU-hosted infrastructure with no data transfer to US systems. Client data processed through HubSecure does not flow through US-controlled systems and is not subject to CLOUD Act orders. The platform's architecture is designed for European data sovereignty from the ground up, not adapted to it after the fact.

The specific data sovereignty commitments in HubSecure's data processing agreement cover:

The competitive framing: For European regulated businesses, European data sovereignty is increasingly a client expectation, not just an internal compliance requirement. Financial services clients, healthcare providers, and legal clients who understand the CLOUD Act question are asking their service providers — and their service providers' software vendors — about CLOUD Act exposure. Being able to answer "none" is a genuine competitive advantage in procurement conversations.

What you should ask your current providers

If you are evaluating the CLOUD Act exposure of your current tool stack, these are the questions that matter:

  1. Where is this company incorporated? If the answer is the United States, CLOUD Act applies regardless of other factors.
  2. Does the company have a US-headquartered parent company? Subsidiaries of US parents may also be subject to CLOUD Act orders directed at the parent.
  3. Can the company provide written confirmation that no US-headquartered entity has access to my clients' unencrypted data? This is the technical test — if a US entity can access the data, it can be compelled to produce it.
  4. What supplementary technical measures does the company implement to mitigate CLOUD Act exposure for EU customers? Acceptable answers involve client-side encryption with keys held by the customer — not just TLS in transit.

Learn about data residency in HubSecure

Review our data residency commitments, subprocessor list, and data processing agreement — and talk to us about migrating from US-based tools.

Data residency details

Related posts

Post-Quantum Encryption: Why Your Business Data Needs It Now · NIS2 Compliance Checklist: How HubSecure Covers Every Requirement · Why Regulated Companies Need Governed AI, Not Just AI · HubSecure vs Freshworks: Service Tickets vs Governed Operations