CLOUD Act vs. GDPR: The Conflict About Data Access Explained

If your company must comply with the GDPR, you also need to understand the U.S. CLOUD Act. Passed in 2018, it lets U.S. authorities demand data from U.S.-based providers, even when that data is stored in the EU.

This directly contradicts GDPR Article 48, which states that foreign authorities require an international agreement to access EU data. For EU businesses using U.S. cloud providers, this creates a real compliance dilemma: following one law can mean breaking the other.

The situation is further complicated by U.S. hyperscalers marketing their EU offerings as “GDPR-compliant” or “sovereign cloud.” In reality, U.S. jurisdiction still applies, no matter where the servers are. That gap between marketing and law is driving Europe’s push for true digital sovereignty.

This guide breaks down:

• What the CLOUD Act is and how it works
• How it collides with GDPR rules
• What this means for your cloud strategy, vendor choices, and data sovereignty

What is the U.S. CLOUD Act?

The CLOUD Act (Clarifying Lawful Overseas Use of Data Act) is a U.S. federal law from 2018. It updated the Stored Communications Act and gives U.S. authorities the power to demand data from U.S.-based service providers, even if that data is stored outside the United States.

Source: https://cyberinsider.com/cloud-act/

Why was it introduced? Background and legal classification of the U.S. CLOUD Act

The CLOUD Act grew out of the 1986 Electronic Communications Privacy Act (ECPA) and its Stored Communications Act (SCA). Those laws were written for a pre-cloud era and didn’t make clear whether U.S. legal orders could reach data stored abroad.

This became a major issue in the ‘Microsoft Ireland’ case:

• In 2013, U.S. prosecutors requested via an SCA warrant emails stored in Microsoft’s Dublin data center
• Microsoft refused, arguing that the SCA only applied within U.S. borders
• In 2016, a U.S. appeals court agreed with Microsoft, ruling the government could not force the disclosure of data stored overseas

To resolve the “Microsoft Ireland” problem, Congress passed the CLOUD Act on March 23, 2018 (as part of the Consolidated Appropriations Act, 2018). Legally, it amends Title 18 of the U.S. Code and expands the Stored Communications Act in three key ways:

• Extraterritorial reach: U.S. authorities can demand data from U.S. providers, no matter where the data is stored
• “Comity” process: A legal mechanism that lets providers challenge disclosure orders if they conflict with foreign laws
• Executive agreements: A framework for direct, government-to-government agreements that make cross-border data requests faster and more predictable.

Bottom line: The CLOUD Act shifts jurisdiction from where the data sits to who controls it. It also adds a second path in the form of executive agreements, so governments can bypass slow mutual legal assistance treaties.

Key provisions of the CLOUD Act

The CLOUD Act is built on two main pillars and a limited safety mechanism (“comity” challenges):

• Extraterritorial SCA orders to U.S. providers: The Act clarifies that U.S. warrants, subpoenas, and court orders under the Stored Communications Act can force U.S.-based providers to hand over data in their possession, custody, or control, no matter where it’s stored. In short: jurisdiction follows the provider, not the server.

• Executive Agreements for direct, cross-border requests: The Act allows the U.S. to set up bilateral agreements with trusted foreign governments. These agreements let law enforcement in both countries make direct, case-specific requests to communications service providers—without going through the slower MLAT (Mutual Legal Assistance Treaty) process. These agreements don’t expand U.S. jurisdiction over foreign providers. Instead, they remove conflicts and streamline access to evidence. Requests under executive agreements must be specific, subject to independent review, limited to serious crimes, and compliant with human-rights standards.

  Quick explainer: An MLAT is the traditional way governments share evidence across borders in criminal cases. Instead of police emailing a provider directly, Country A sends a request to Country B’s central authority. Country B then uses its own courts and laws to obtain the evidence and returns it through the same official channel.

• Comity challenges and how providers can contest: Providers can challenge or request modification of U.S. orders if following them would break foreign law, especially when the conflict is with a country covered by an executive agreement. Outside those cases, common-law comity still applies: courts weigh factors like how specific the request is, where the data originated, whether alternatives exist, and the national interests at stake.

What this means for global cloud operations:

Source: https://gartsolutions.com/digital-sovereignty-of-europe-choosing-the-eu-cloud-provider/

How Executive Agreements work under the U.S. CLOUD Act

Executive agreements are bilateral deals between the U.S. and a foreign government. They let law enforcement on both sides send direct, targeted orders to providers in the partner country:

• They remove local “blocking laws” that would normally prevent providers from replying
• They don’t create new powers—companies still respond under the issuing country’s law
• The purpose: faster, clearer access to electronic evidence in serious crime cases

How they work in practice:

1. A foreign authority issues a legal order (like a warrant or court order) under its own law.
2. That order goes directly to the provider in the partner country.
3. Thanks to the executive agreement, legal barriers are lifted so the provider can respond.

Scope and limits:

• Only for serious crimes
• No bulk collection, requests must be specific
• Independent oversight is required
• No targeting of U.S. persons (and vice versa for partners)
• Agreements are reviewed by the U.S. Congress and usually renewed every 5 years
• Encryption-neutral: they don’t mandate backdoors

As of August 2025, the USA has executive agreements with:

• United Kingdom: The U.S.–U.K. Data Access Agreement has been in force since October 3, 2022
• Australia: The U.S.–Australia CLOUD Act Agreement has been in force since January 31, 2024

Executive agreements make cross-border investigations faster and more predictable than the old MLAT process. But they don’t fix every issue, especially around encryption and GDPR transfer rules. For companies, they are best seen as a streamlined channel for legitimate law-enforcement requests.

Comparative analysis: CLOUD Act vs. GDPR

Article 48 of the GDPR states that EU data can’t be handed over to a non-EU authority just because that authority issues a court or administrative order. Normally, there must be an international agreement (like an MLAT).

By contrast, the CLOUD Act explicitly allows U.S. authorities to demand U.S. providers to hand over data, no matter where it’s stored, and that includes in the EU.

Because the CLOUD Act follows who controls the data (the provider), hosting data in the EU doesn’t shield it if a U.S. provider can access it.

This creates a bind for EU organizations:

• Comply with a U.S. order and risk violating GDPR
• Refuse a U.S. order and risk U.S. sanctions

That’s why mechanisms like MLATs, comity challenges, or architectures that limit provider access are critical.

Privacy Shield vs. CLOUD Act

EU–US transfer frameworks—Privacy Shield and its successor, the EU–US Data Privacy Framework—regulate commercial data transfers between companies. They do not change US lawful-access rules such as the CLOUD Act.

Even if companies rely on the Data Privacy Framework or Privacy Shield for transfers, the CLOUD Act still applies. Any US law enforcement request should be handled through proper legal channels and backed by technical safeguards.

How the conflict between the Cloud Act and GDPR fuels European data sovereignty moves

Both laws are legitimate, but they pull in different directions. The CLOUD Act ensures law enforcement access to evidence. GDPR protects fundamental rights and control of personal data.

For EU businesses, “compliance by design” now means treating provider control as a top risk factor. The CLOUD Act vs. GDPR clash has accelerated European data sovereignty initiatives, including:

• Preference for EU-based providers
• Sovereign cloud offerings
• Technical and organizational controls that keep real control inside the EU

While U.S. providers promote solutions like EU Data Boundary or Sovereign Cloud, the real issue is jurisdictional control, not just where the servers are. This reality is driving more EU customers toward EU-owned or EU-operated providers.

Operating under the CLOUD Act: Hyperscalers’ mitigation strategies in Europe

Large U.S. cloud providers, often referred to as hyperscalers, increasingly emphasize EU-focused offerings such as EU Data Boundary, European Sovereign Cloud, or Sovereign Controls. At first glance, these initiatives may suggest that keeping data within the EU is sufficient, but exposure depends on who can access it and how, not just where it’s stored.

The reality is different. As long as a communications service provider is headquartered in the U.S. or controlled by a U.S. parent company, it remains subject to the CLOUD Act. That law allows U.S. authorities to demand disclosure of data under a provider’s control, regardless of where it is stored, including inside EU data centers of hyperscalers. This conflict means that no U.S. hyperscaler can offer absolute protection simply by localizing data in the EU.

This gap between marketing and legal reality has been acknowledged publicly. For example, Microsoft’s own chief legal officer in France admitted under oath before the French Senate of Parliament that the company cannot guarantee EU data is safe from U.S. access requests. Regulators, academics, and European policymakers across the industry have voiced similar concerns.

Why do hyperscalers make these claims?

• Commercial positioning: The European cloud market is strategically important, and customers want GDPR guarantees. By advertising “sovereign” services, providers strengthen trust and increase their chances of winning contracts.
• Technical improvements as marketing: To back this up, hyperscalers have invested in EU data residency, encryption features, and access controls. These steps do improve security, but they do not change the fact that the CLOUD Act still applies.
• Shaping perception: By emphasizing “compliance,” providers steer the conversation away from the legal conflicts and toward technical solutions. This reduces customer concerns, at least in the short term, even though the underlying jurisdictional problem remains.

What does this mean for EU businesses?
For customers, the takeaway is simple: claims of “EU-only” or “sovereign” compliance from U.S. hyperscalers should be viewed with care. These providers may offer strong technical safeguards, but the jurisdictional tension with the U.S. CLOUD Act remains unresolved. In practice, EU-owned or EU-controlled providers generally reduce exposure to U.S. legal process, though no model is entirely immune.

This reality is driving Europe’s push for genuine digital sovereignty. The goal is not just EU data centers run by U.S. companies, but infrastructure, governance, and control that remain fully under European jurisdiction.

Positive aspects of the U.S. CLOUD Act

The CLOUD Act’s main contribution is speed with structure: It improves lawful access to electronic evidence in serious crime cases and gives clearer rules for both law enforcement and providers.

Enhances public safety and speeds investigations

The U.S. Cloud Act helps investigators get electronic evidence faster in cases of terrorism, violent crime, child sexual exploitation, and cybercrime. It fixes delays caused by routing requests through mutual legal assistance treaties (MLATs). The U.S. Department of Justice reports that MLAT demand has increased sharply, overloading resources and slowing response times. The CLOUD Act offers a more efficient, privacy-aware way to access data needed for investigations.

Modernizes the cross-border evidence framework

It updates outdated rules from the 20th century to match today’s cloud environment. The Act clarifies when providers under U.S. jurisdiction must disclose data they control, aligning with Article 18(1) of the Budapest Convention on Cybercrime. This gives both authorities and providers a clearer, more predictable legal basis than before.

Reduces dependency on slow MLAT channels

Through executive agreements with trusted partners, the Act allows foreign authorities to use their own legal process to send direct, targeted orders to U.S. providers. This reduces MLAT delays while keeping MLAT available for cases outside the scope of an agreement.

Practical efficiency for law enforcement and providers

For investigators, the Act creates a faster, clearer path to vital evidence. For providers, it brings more legal certainty about when and how they can respond. EU-facing guidance also describes the CLOUD Act as a modernization step that reflects the rise of cloud services and streamlines lawful access procedures.

Built-in safeguards

Executive agreements are limited to serious crimes, require independent review, and only allow targeted (non-bulk) demands. They cannot intentionally target U.S. persons or people located in the U.S. These guardrails are designed to protect rule-of-law values while making cross-border cooperation faster and more effective.

Cloud Act and its positive impact on businesses

The CLOUD Act can also benefit companies. It creates clear triggers for disclosure, faster lawful pathways, and built-in safeguards that let providers operationalize compliance. When cloud providers combine these mechanisms with strong transparency reporting, rigorous governance, and tested challenge procedures, compliance itself becomes a competitive trust signal.

Compliance clarity for U.S. providers
The CLOUD Act gives providers a consistent playbook for handling lawful requests. It clarifies when U.S. authorities can demand production of data and when foreign authorities can go directly to U.S. providers. This reduces the uncertainty that existed under MLAT-only processes. The result: greater predictability, lower friction in daily request handling, and faster support for legitimate investigations.

Governance as a competitive differentiator
Because requests must be specific and providers can challenge overbroad or conflicting demands, the Act rewards vendors with strong governance. This includes:

• Clear request-handling policies
• Audit trails
• Legal review by counsel
• Transparent reporting

Providers who demonstrate disciplined, rights-respecting procedures gain an edge in building trust with enterprise customers and regulators.

A more modern, internationally aligned framework
By modernizing access mechanisms, the Act introduces legal clarity that aligns with evolving global standards for electronic evidence. This helps multinationals by making processes more predictable: they can design compliance once and apply it consistently across jurisdictions, rather than reinventing the wheel for each request.

Risks and negative impacts of the CLOUD Act

Despite its benefits, the CLOUD Act does not resolve the fundamental tensions with the GDPR. Instead, it creates legal conflicts, compliance costs, and reputational risks for EU-facing businesses. As a result, companies can expect continued pressure toward EU-sovereign hosting, tighter control of encryption keys, and stricter governance around handling requests.

Practical guidance for companies

To deal with the tension between the CLOUD Act and the GDPR, companies need a playbook that combines legal, technical, and vendor strategies. Think of it as five key areas:

1. Vendor & architecture choices

• Prefer EU-owned or sovereign providers: Using EU-based vendors reduces direct CLOUD Act exposure.

• Localize data and controls in EU regions: Data residency helps, but location alone isn’t enough. Pair it with measures that keep real access inside the EU.

• Keep encryption keys in EU hands: Use client-side encryption and customer-managed keys held by an EU entity. That way, even if a provider gets a U.S. order, it cannot decrypt your data.

• Adopt zero-trust & least-privilege designs: Strict access controls, minimal admin rights, and partitioned/federated setups limit how much technical reach any single provider has.

2. Security controls & operational readiness

• Data mapping & classification: Keep an up-to-date inventory of what you store, where it lives, who can access it, and which laws apply. Tag and classify data so protections apply automatically.

• Audit trails & transparency: Log all admin access, key usage, and disclosure events. Be ready to provide transparency reports and audit evidence to customers.

• Government-request playbook: Build and rehearse a standard operating procedure (SOP) for handling requests:

  • Check validity and scope
  • Test if there’s a GDPR transfer basis
  • Route via MLAT if appropriate
  • Decide whether to challenge (e.g., via comity)
  • Run tabletop exercises so the process is muscle memory

3. Contract & governance levers

• Provider contracts: Require notice of government requests (unless barred by law), commitments to challenge overbroad/conflicting orders, data-location limits, and preservation of customer-held keys

• Risk assessments before onboarding/renewal: Evaluate provider jurisdiction, data categories, encryption setup, and transfer risks. Document the decision.

• Plan for comity challenges: Support your provider if they need to contest a conflicting request, and be prepared to steer cases toward MLAT or executive-agreement channels.

4. Encryption & key-management patterns that work in practice

• Client-side end-to-end encryption (E2EE): For your most sensitive data, make sure only your endpoints can decrypt it

• App-level encryption + KMS you control: Where full E2EE isn’t possible, encrypt at the application level and keep the keys in your own key management system

• BYOK/HYOK with EU custody: Host keys in EU-based hardware security modules (HSMs). Use split-key or m-of-n approval so decryption needs multiple authorizations.

5. Monitoring & market strategy

• Track executive agreements: New agreements change request pathways and safeguards. Update your playbook and contracts accordingly.

• Scrutinize sovereign offerings: Check who actually controls the infrastructure, admins, and keys. Don’t rely only on “EU boundary” marketing claims.

• Re-platform where needed: For high-risk workloads, consider EU-native or sovereign stacks where legal and reputational risks are highest

Source: https://gartsolutions.com/digital-sovereignty-of-europe-choosing-the-eu-cloud-provider/

CLOUD Act vs. GDPR: Speed meets privacy rules

The U.S. CLOUD Act modernizes how authorities access cross-border evidence. It:

• Speeds up lawful investigations
• Creates more predictable cooperation through executive agreements with safeguards
• Gives providers clearer rules about when and how to respond

But its ability to demand data regardless of where it is stored clashes with the GDPR, especially Article 48. For EU-facing businesses, this raises issues of sovereignty, operational complexity, and reputational risk.

The challenge is amplified by U.S. hyperscalers marketing their EU services as “GDPR-compliant” or “sovereign cloud.” While such offerings may include stronger security measures, they cannot remove the underlying jurisdictional conflict: U.S. law still applies to U.S.-controlled providers.

Companies should take a proactive approach that blends legal, technical, and strategic measures. For high-risk workloads, it often makes sense to rely on EU-controlled or sovereign providers. Data residency in the EU should be combined with strong encryption and customer-held keys to ensure providers cannot access plaintext. Good governance is equally important: clear audit trails, escalation playbooks, and transparency reporting build resilience and trust.

FAQ Cloud Act vs. GDPR

What is the CLOUD Act in the U.S.?

The CLOUD Act (Clarifying Lawful Overseas Use of Data Act) is a U.S. law from 2018 that updated the Stored Communications Act. It allows U.S. authorities to require U.S.-based service providers to hand over data they control. The law also created a framework for executive agreements with trusted foreign governments, so their law enforcement agencies can send direct, rights-based requests to U.S. providers.

What’s the difference between the GDPR and the CLOUD Act?

The GDPR is about protecting people’s personal data and setting strict rules for how that data can be processed or transferred. The CLOUD Act is about giving law enforcement faster access to digital evidence. The conflict arises because the GDPR blocks foreign court orders (Article 48) unless there’s an international agreement, while the CLOUD Act says U.S. providers must comply regardless of where the data is stored.

What does the CLOUD Act do?

In simple terms, the CLOUD Act:

• Let U.S. legal orders apply no matter where the data sits (as long as the provider controls it)
• Enables executive agreements with safeguards to replace slow MLAT processes in serious crime cases
• Allows providers to challenge an order if it clashes with another country’s law (the “comity” mechanism)
• Prevents bulk data demands or forced encryption backdoors

What does the CLOUD Act allow U.S. law enforcement to do in the GDPR context?

It allows U.S. authorities to serve legal orders on U.S.-based providers (or their affiliates) for data they can access, even if that data is hosted in the EU. But GDPR rules still apply to EU companies: under Article 48, they cannot simply hand over data based only on a U.S. order. Instead, disclosure generally requires an international mechanism—like an MLAT or an executive agreement. In practice, providers and their customers may challenge such requests in court or redirect them through MLAT or executive-agreement channels to avoid breaking EU law.