EU-sovereign by design: the US CLOUD Act and where your UK business data really lives

Some context before we start: this is general information, current at the time of writing, and it is not legal advice. Take proper advice on anything load-bearing for your own business.

You know what your website looks like. You know what it says. Almost nobody can answer a simpler question: where does the data behind it actually live, and who can be compelled to hand it over?

Every enquiry form, every customer email, every booking, every card payment leaves a trail of personal data. That data sits on servers owned by someone, in a country with its own laws, run by a company that answers to a government somewhere. For most UK small businesses, that somewhere is the United States, even when the marketing page says “EU data centre”.

This article explains why that matters, what the US CLOUD Act is in plain English, and what “EU-sovereign by design” actually means when it is more than a slogan. It is the on-page version of our whitepaper. If you would rather have the branded PDF to read later or forward to a colleague, you can get the whitepaper here.

The US CLOUD Act, without the jargon

The CLOUD Act (Clarifying Lawful Overseas Use of Data Act) is a United States law passed in 2018. In one sentence: it lets US authorities compel a US-headquartered technology company to hand over data it controls, regardless of which country the data is physically stored in.

So if your customer records sit on a service run by a US-parent company, the fact that the server is in Dublin, Frankfurt or London does not put the data beyond the reach of a US legal order. The jurisdiction that matters is not where the disk spins. It is where the company that controls the disk is headquartered.

That is the part almost every “EU region” marketing claim quietly skips.

Why this is a UK small-business problem, not a big-tech problem

Two things are true at once, and they pull in opposite directions.

First, UK GDPR expects you to know where personal data goes, to protect it, and to be careful about transfers and third-party access. You are the data controller. The obligation is yours, not your supplier’s.

Second, the CLOUD Act means a US-parent supplier can be lawfully required to disclose data under US process, in ways that may sit uncomfortably next to those UK GDPR expectations. This is the conflict-of-laws problem that sat underneath the Schrems II ruling (Court of Justice of the European Union, July 2020) and the years of transatlantic data-transfer wrangling that followed.

You do not need to be a bank or a hospital for this to matter. A clinic holds health information. A solicitor holds privileged client information. An accountant holds financial records. A shop holds a customer list that is the business’s single most valuable asset. If any of that can be reached through a jurisdiction you never chose, that is a risk you are carrying without having decided to.

EU region is not the same as EU-sovereign

Here is the trap, stated plainly. Choosing the “EU region” on a US provider changes where the data sits. It does not change who can be compelled to produce it.

A US-parent cloud with a London data centre is still a US-parent cloud. The region toggle is a latency and residency setting, not a sovereignty guarantee. Genuine sovereignty is about the legal reach over the company that holds your data, and that is decided by corporate headquarters and ownership, not by a dropdown.

This is not anti-American, and it is not a claim that these providers are careless. They are excellent at what they do. It is simply an honest statement of which laws apply, so you can make an informed choice instead of an accidental one.

The Sovereignty-by-Design Test (a named framework)

Sovereign by design means the choice is made deliberately, at the foundation, not patched on afterwards. In practice it is a five-part test.

The Sovereignty-by-Design Test. A data posture is genuinely EU-sovereign when: the providers on the critical path have their corporate home in the EEA or the UK; the region is pinned explicitly in configuration and verified rather than assumed; no US-resident software sits on the path that touches identifying personal data; every sub-processor is written down, kept current and disclosed; and a Data Processing Agreement is in place with each one, with notice given before the mix changes.

None of this is exotic. It is ordinary good practice. It is just rarely done, because the convenient default is a handful of US giants and nobody asks the question in this article.

How UK Web Marketing builds it

We build and run web and marketing infrastructure for UK small businesses on EEA and UK-hosted foundations, so the critical client-data path does not sit under US jurisdiction. The working stack:

Job	Provider	Where
Hosting	Vercel	London (lhr1)
DNS, email routing, CDN	Cloudflare	EU and UK edges
Outbound email	Resend	EU
Customer records (CRM)	Capsule	UK
Payments	Stripe (Payments Europe)	Ireland, EU entity
Analytics	Plausible	EU, cookieless, no Google Analytics

We keep a current sub-processor disclosure, hold Data Processing Agreements with each supplier, and give notice before the mix changes. Cloudflare and Stripe are retained as considered, documented exceptions rather than accidental defaults. Every site we build ships with this posture as standard, not as a premium add-on.

We are not claiming that any single tool makes a business immune from every legal process everywhere. We are claiming something narrower and honest: that where your data lives, and whose laws reach it, should be a decision you made on purpose. If you want the vendor-by-vendor detail, that lives in our companion piece on a UK and EU-based, GDPR-friendly stack.

A five-minute check for your own business

Run this against your current setup.

1. List every tool that touches customer data: website host, forms, email, CRM, analytics, payments, backups, chat.
2. For each, find the parent company and its country of headquarters (not the data-centre region).
3. Mark anything with a US parent that holds identifying personal data.
4. Ask each supplier for its sub-processor list and its DPA. A supplier that cannot produce these quickly is telling you something.
5. For anything flagged, decide: is there an EEA or UK-hosted alternative that does the same job? Often there is.

You do not have to fix everything at once. You do have to know the answer, because under UK GDPR the responsibility is yours.

Frequently asked questions

Does the CLOUD Act mean my data is unsafe on a US provider?

No, and that is not the claim. The CLOUD Act does not mean your data is careless-handled or about to leak. It means a US-headquartered company can be compelled, under US legal process, to disclose data it controls, wherever that data is stored. The point is not that the provider is bad. The point is that a jurisdiction you never chose has legal reach over your customers’ data, and under UK GDPR you are the one responsible for having decided that on purpose.

Is choosing the “EU region” on a US cloud enough for UK GDPR?

Choosing the EU region changes where the data physically sits, which helps with data-residency questions, but it does not change who can be compelled to produce the data. A US-parent provider remains within US jurisdiction whatever region you pick. For a genuine sovereignty posture the provider’s corporate home, not just its data-centre location, needs to be in the EEA or the UK. Residency is a setting; sovereignty is about legal reach.

Do I need to rip out every US tool tomorrow?

No. This is a decision to make deliberately, not a fire drill. Start with the five-minute check: list every tool that touches customer data, find each parent company’s country of headquarters, and mark anything US-parent that holds identifying personal data. Then decide, tool by tool, whether an EEA or UK-hosted alternative does the same job. Often one does. You do not have to fix everything at once, but under UK GDPR you do have to know the answer.

Why do you keep Cloudflare and Stripe if they are US-linked?

Because they are considered, documented exceptions rather than accidental defaults. Cloudflare’s DNS, email routing and CDN run on EU and UK edges, and Stripe processes payments through Stripe Payments Europe, an Ireland-based EU entity, so card details never touch our own servers. Both are retained on purpose, recorded in the sub-processor disclosure, and reviewed. The discipline is the point: an exception you can name and defend is different from a default you never questioned.

What is a sub-processor, and why should I ask my supplier for the list?

A sub-processor is any third party your supplier uses to help process your data: the host behind your form tool, the email relay behind your CRM, the analytics behind your dashboard. Under UK GDPR you are entitled to know who they are. A supplier that can hand you a current sub-processor list and a Data Processing Agreement within a day understands its own posture. One that cannot produce them quickly is telling you something about how well it knows where your data lives. You can see our own sub-processor disclosure as a worked example.

The short version

Where your data lives, and whose laws reach it, is one of the few genuinely strategic decisions a small business makes online, and it is usually made by accident. EU-sovereign by design simply means making it on purpose: EEA and UK-hosted providers on the critical path, the region pinned in configuration, a written sub-processor list, and a Data Processing Agreement with each supplier. Your data, your customers, your jurisdiction. Not someone else’s cloud.

If you would like the full paper to keep or forward, get the branded whitepaper PDF here. If you would like this built and run for you from the first commit, start with a free audit, and see the posture behind every build at sub-processors.