CLOUD Act Exposure Audit: A Step-by-Step Guide for EU Organizations

By Wingston Sharon | November 2024

Most EU organizations I talk to have heard of the CLOUD Act. Fewer have actually mapped their exposure to it. This guide walks through the audit process I use when working with EU clients who want to understand — honestly, not alarmistically — what their actual risk profile looks like.

Let me be clear upfront: this is not a guide to "going dark" or eliminating all US technology from your stack. That's neither realistic nor always desirable. This is about informed decision-making. You cannot manage risk you haven't mapped.

What the CLOUD Act Actually Says

The Clarifying Lawful Overseas Use of Data Act (2018) allows US law enforcement agencies to compel US-domiciled companies — companies incorporated in the US or with a principal place of business there — to produce data they store, possess, or control, regardless of where that data physically resides.

The key phrase is "US-domiciled." If your cloud vendor, SaaS provider, or analytics platform has a US parent company, that parent is subject to CLOUD Act orders. The fact that your data sits in a Frankfurt or Dublin data centre does not shield it if the company operating that data centre is headquartered in Seattle or San Francisco.

This is distinct from GDPR. GDPR governs how data is processed. The CLOUD Act governs whether a US court can order a US company to hand over data to US law enforcement. The two frameworks can conflict directly — and that conflict has not been resolved cleanly in any jurisdiction.

Step 1: Map Your Vendors

Start with a full inventory. The scope is broader than most people expect.

What to include:

• Cloud infrastructure (AWS, Azure, GCP, and their EU-branded equivalents — yes, Azure Germany is still Microsoft)
• SaaS applications (productivity suites, CRMs, HR systems, finance tools)
• CDN and DDoS protection (Cloudflare, Akamai, Fastly — these handle your traffic)
• DNS providers (often overlooked — Route 53, Cloudflare DNS)
• Analytics and monitoring (Google Analytics, Datadog, New Relic, Splunk)
• Communication tools (Slack, Teams, Zoom, Google Workspace)
• Identity providers (Okta, Auth0, Azure AD)
• AI and ML APIs (OpenAI, Anthropic, Google, AWS Bedrock)
• Payment processors (Stripe, PayPal, Adyen — Adyen is Dutch, notably)
• Support and ticketing systems (Zendesk, Salesforce Service Cloud)

For each vendor, the question is simple: does this company have a US parent, US incorporation, or principal place of business in the US?

Practical shortcut: If the vendor's primary stock listing is on a US exchange, they are almost certainly US-domiciled for CLOUD Act purposes. If they are incorporated in Delaware (as the majority of US tech companies are), they are in scope.

Create a spreadsheet. You will use it throughout the rest of this audit.

Step 2: Classify Your Data

Not all data carries the same risk. Once you know which vendors are US-domiciled, you need to understand what data flows through each one.

High-sensitivity categories:

• Personal data under GDPR — employee records, customer PII, health data. A CLOUD Act order producing this data to US law enforcement creates a direct conflict with your GDPR obligations. You cannot provide lawful access under CLOUD Act and simultaneously comply with GDPR's transfer restrictions without a mechanism in place.
• Business secrets and IP — unreleased product plans, pricing strategies, merger discussions, source code. CLOUD Act applies to criminal and national security investigations, but the line between corporate espionage and national security can be murky.
• Regulated financial data — if you are in financial services, banking secrecy obligations may exist independently of GDPR.
• Legally privileged communications — correspondence with legal counsel stored in email or document management systems hosted by US companies.

Lower-sensitivity (but still document):

• Anonymized analytics data
• Public-facing marketing content
• Generic configuration and operational data

For each high-sensitivity data type, note which US-domiciled vendors store, process, or transmit it. This is the beginning of your risk matrix.

Step 3: Assess Actual Risk

This is where nuance matters. CLOUD Act exposure is not a binary condition. Several factors determine the practical probability of a CLOUD Act order affecting your data.

Factors that increase actual risk:

• Your organization has US operations, US employees, or US business relationships (creates US nexus)
• You operate in sectors that attract US law enforcement attention (financial services, defense-adjacent industries, pharmaceuticals)
• You have US investors with significant ownership
• Your executives travel to the US regularly and hold data on US-hosted systems

Factors that reduce actual risk:

• You are a pure EU entity with no US nexus whatsoever
• Your industry is not a common target of US federal investigations
• The data you're concerned about is not the type law enforcement typically seeks

The honest assessment for most EU SMEs: the probability of an actual CLOUD Act order affecting your specific data is low. The risk is not zero, but it is not the same risk as a multinational with US operations. Document this assessment. Your residual risk documentation needs to reflect the actual probability, not just the theoretical possibility.

Step 4: Identify Alternatives

For each vendor you've flagged as high-risk given the data it handles, identify the EU-sovereign alternative. This doesn't mean you have to switch — it means you need to know what switching would cost and look like.

For each high-risk vendor, note whether the EU-sovereign alternative is genuinely equivalent for your use case. Some EU alternatives are production-ready and cost-competitive. Others involve meaningful capability trade-offs. Document that trade-off honestly.

Step 5: Document Your Residual Risk

Not everything can move. Some US-domiciled vendors have no credible EU-sovereign replacement at equivalent quality or cost. Some migrations are simply not feasible within your current budget or timeframe. That is a legitimate business decision.

What matters is that you document it.

Residual risk documentation should include:

• The vendor name and US domicile
• The data types it handles
• Why migration is not currently feasible (technical, financial, contractual lock-in, capability gap)
• The risk level you are accepting
• The review date (when you will re-evaluate)

This documentation serves multiple purposes. If you face a DPA inquiry, it demonstrates that you have performed a systematic assessment. It also creates a roadmap for future migrations when alternatives mature.

A Practical Audit Template

Here is the table I use as a starting point with clients:

The risk level assignment should reflect both the sensitivity of the data and the probability of a CLOUD Act order based on your nexus assessment from Step 3.

What This Audit Is Not

This audit does not make you immune to legal process. If a US court issues an order, it issues an order. What this audit does is:

1. Give you visibility into your actual exposure
2. Allow you to make informed decisions about where to reduce risk
3. Create documentation that demonstrates due diligence
4. Identify the quick wins (Google Analytics → Plausible is a half-day migration) from the complex migrations

It also does not replace legal advice. If your organization has meaningful US operations or handles particularly sensitive data — defense, critical infrastructure, health — you should engage a data protection attorney who understands both CLOUD Act and GDPR, not just one of them.

Starting the Conversation

Running this audit properly takes a few days for a typical EU SME — longer for organizations with complex vendor landscapes. The vendor mapping step is usually where people discover services they had forgotten about, particularly analytics tools, monitoring agents, and third-party integrations that got added organically over time.

If you are working through this and want to discuss what you're finding, reach out at hello@agentosaurus.com.