Cloud Act vs. GDPR: The Risk for EU Businesses

Any European company running applications on AWS, Microsoft Azure, or Google Cloud today is operating under two legal systems — and they contradict each other. The US Cloud Act compels American providers to hand over data to US authorities. The GDPR prohibits exactly that. Ignoring this conflict means accepting real legal risk. This article explains why standard compliance measures aren't enough and which technical decisions actually make a difference.

What the Cloud Act actually requires

The Clarifying Lawful Overseas Use of Data Act, or Cloud Act, was passed in the United States in 2018. The law allows US authorities to request data stored by American companies, regardless of where that data physically resides. A server in Frankfurt, Amsterdam, or Dublin offers no protection against such access — because data residency is not data sovereignty.

This is not a theoretical threat. US law enforcement agencies like the FBI can use court orders to request data directly from providers like Microsoft or Amazon — without going through international mutual legal assistance treaties. The Cloud Act has accelerated and formalized this process.

US companies have little room to maneuver. They can challenge orders when there is a clear conflict with the law of the country where the data is stored, but that is a lengthy legal process, and the default outcome is compliance with the US authority's request.

What the GDPR says about this

The General Data Protection Regulation, in Articles 44 ff., governs the conditions under which personal data may be transferred to third countries. A third country must offer an adequate level of protection, or a valid mechanism must be in place to substitute for that level of protection.

For the United States, this was the Privacy Shield for years. Then came Schrems II.

Schrems II and the end of the Privacy Shield

In July 2020, the European Court of Justice invalidated the Privacy Shield. The reasoning was unambiguous: US surveillance laws, including Section 702 FISA and Executive Order 12333, enable mass surveillance against which EU citizens have no effective legal recourse. This eliminated the legal basis for data transfers to the United States.

Standard Contractual Clauses (SCCs) can still be used since then, but only if it is verified on a case-by-case basis that the recipient can actually comply with the agreed-upon safeguards. For US providers subject to the Cloud Act, that is precisely what is called into question.

The Trans-Atlantic Data Privacy Framework. Better, but not bulletproof

In 2023, the Trans-Atlantic Data Privacy Framework (TADPF) came into force — the new agreement between the EU and the United States. It brings improvements: an ombudsman mechanism is intended to give EU citizens legal recourse against US surveillance, and certain data access practices have been restricted.

Whether this is sufficient remains disputed among legal experts. Max Schrems and noyb have already announced plans to challenge the agreement. "Schrems III" is considered likely. Anyone building their infrastructure on the TADPF is building on a foundation that could crumble again.

Cloud Act vs. GDPR. The conflict in practice

The core problem can be reduced to a single sentence: A US cloud provider cannot defy the Cloud Act without breaking the law, and it cannot fully comply with the GDPR as long as the Cloud Act applies.

If a US authority makes a lawful request for data that an EU company has stored with AWS, AWS has no legally safe option. Handing over the data potentially violates the GDPR. Refusing violates US law. The provider is caught in the middle — and in practice, home-country law usually wins.

For the EU company, this means: data can flow to US authorities without the company being notified, without its involvement, and without a European court having been involved. That constitutes a GDPR violation — regardless of whether the provider has a data center in Germany.

The potential consequences are concrete:

• Fines under Art. 83 GDPR of up to 4% of annual global turnover
• Orders to cease data processing issued by data protection authorities
• Civil claims from affected individuals
• Reputational damage, particularly in regulated industries such as healthcare, law, or financial services

What encryption can and cannot do

Technically proficient teams often reach for client-side encryption as a solution. The idea: if data is stored encrypted with a US provider and the keys remain exclusively with the European company, the provider can only hand over unreadable ciphertext in response to authority requests.

That is not a bad approach, but it has limits.

What encryption protects: File contents, database contents, messages — provided key management is properly implemented and the keys never leave the company's own systems.

What encryption does not protect: Metadata. Who communicated with whom and when, which IP addresses were involved, what file sizes were transferred, which services were used. All of this can be of interest to authorities and often remains unencrypted. Access logs, usage statistics, configuration data — likewise frequently stored in plaintext.

Furthermore, encryption only shifts the problem technically. Legally, the assessment remains possible that using a provider subject to the Cloud Act itself constitutes a risk decision — regardless of whether the provider could deliver readable data in an actual case.

Why European cloud providers stand on different legal ground

The Cloud Act applies to US persons and US companies. A European cloud provider with no US subsidiary and no US parent company is simply not subject to this law. This is not a marketing argument. It is a legal reality.

A company like lowcloud, which operates as a European provider exclusively on European infrastructure and has no structural ties to US legal entities, can legitimately say: we cannot receive Cloud Act requests because the law does not apply to us. For a practical look at which self-hosted EU alternatives are production-ready today, see our guide.

This does not, of course, exclude the possibility that European authorities may request data under European law — but then the GDPR's protective mechanisms apply, there are legal recourse guarantees, and the process is transparent and contestable for the affected company.

For companies working in regulated sectors — healthcare, public administration, legal services, financial services — this distinction is not optional. It is a compliance requirement. The EU's new Cloud Sovereignty Framework now provides a formal, verifiable standard for these requirements, NIS2 adds concrete technical obligations that DevOps teams must implement, and the EU AI Act introduces deployer obligations for anyone running AI workloads.

What this means for your infrastructure decisions

The legal situation cannot be resolved through contract design alone — and the structural risk is compounded by cloud vendor lock-in that makes switching providers difficult even when the legal case is clear. Of course, Data Processing Agreements (DPAs), Standard Contractual Clauses, and Transfer Impact Assessments are sensible and necessary. But they are not enough when the infrastructure itself is structurally vulnerable to Cloud Act access.

A few concrete questions that teams should ask when making infrastructure decisions:

• Is the provider or its parent company a US entity?
• Does the provider have offices or employees in the United States?
• Is the infrastructure located exclusively in the EU?
• Where are encryption keys managed?
• Who has technical access to metadata and logs?

If any of these questions reveals a connection to the United States, the Cloud Act risk is real and should be evaluated legally — not just once, but continuously, as the legal landscape continues to evolve.

Kubernetes on European infrastructure. Without Cloud Act risk

lowcloud is a Kubernetes DaaS platform operated exclusively in Europe and fully subject to European law. No US parent company, no Cloud Act exposure, no structural dependencies on US hyperscalers.

For teams that want to run their applications cloud-natively without being caught between two legal systems, this is not a complicated decision. The platform handles Kubernetes operations, takes care of scaling, monitoring, and updates — and does so on infrastructure that is clean from a data protection perspective.