EU data residency for agencies: how to actually guarantee it

EU data residency means your client data physically lives in an EU region and stays governed by EU law — and the only way to actually guarantee it is to control where the database is created, on an account you own, rather than trusting a vendor’s promise to “host in the EU” on your behalf. Residency and sovereignty are two different questions, most SaaS answers only the first, and the gap between them is where transfer risk hides.

This post explains what data residency really means, why “hosted in the EU” is a weaker claim than it sounds, how Schrems II and the US CLOUD Act shape the risk, and how choosing your own region on your own account turns residency from a promise into a resource you can point at. It is general information, not legal advice — confirm your own obligations with counsel.

What does “EU data residency” actually mean?

Data residency is the answer to a physical question: in which country or region does this data sit at rest? For an agency handling EU client data, the target answer is usually “in an EU region,” so that personal data stays inside the European Economic Area rather than being copied to servers elsewhere.

But residency on its own is only half the picture. The other half is data sovereignty — whose laws govern the data, and who can compel access to it. Data can be resident in Frankfurt and still fall under a non-EU legal regime if the company holding it is subject to foreign law. GDPR itself is built around this distinction: Chapter V (Articles 44–50 of Regulation (EU) 2016/679) restricts transfers of personal data to “third countries” precisely because where the data goes and who can reach it are separate risks from where the disk is.

So a complete residency claim has to answer three things, not one:

1. Location — which region the data physically sits in.
2. Jurisdiction — whose law governs it and who can compel disclosure.
3. Control — who chose the region, and who can quietly change it later.

Most “hosted in the EU” statements answer only the first.

Why “hosted in the EU” is a weak residency promise

“We host in the EU” sounds reassuring, but as a residency guarantee it has three soft spots that matter for an agency signing a data processing agreement.

It is a policy, not a construction. A vendor that chooses an EU region today can choose a different one tomorrow, add a US failover for resilience, or move support tooling offshore — usually without asking you. The claim is only as durable as the vendor’s current configuration and goodwill.

It rarely covers the whole chain. The primary database might be in the EU while backups, logs, error monitoring, email delivery, or AI features route through non-EU sub-processors. Each of those is a potential transfer of personal data. “Hosted in the EU” describes one component; your Article 28 sub-processor obligations cover all of them.

It doesn’t settle jurisdiction. If the vendor — or its parent — is subject to foreign access laws, EU-located servers do not put the data beyond the reach of those laws. This is the core of the transfer problem, and it is where Schrems II and the US CLOUD Act come in.

We wrote about the mechanics of the sub-processor chain in more depth in data residency and GDPR for agencies — the short version is that consolidation without ownership just centralises the risk in one vendor instead of spreading it across three.

What do Schrems II and the US CLOUD Act change about EU data?

Two developments turned “where is the server” into “whose law reaches the data,” and any honest residency conversation has to account for both.

Schrems II (2020). In case C-311/18, the Court of Justice of the European Union invalidated the EU-US Privacy Shield framework and ruled that Standard Contractual Clauses are only a valid transfer mechanism if the data still receives protection essentially equivalent to EU law in the destination country. The practical effect: you cannot transfer personal data outside the EU on paperwork alone — you have to assess the actual legal regime the data would be exposed to. (A successor adequacy decision, the EU-US Data Privacy Framework, was adopted in July 2023, but it has already drawn legal challenges, so relying on it as permanent is optimistic.)

The US CLOUD Act (2018). The Clarifying Lawful Overseas Use of Data Act allows US authorities to compel companies subject to US jurisdiction to produce data they control — regardless of where that data is physically stored. A US company (or an EU subsidiary of one) can therefore be reachable even when the servers are in the EU. This is the concrete reason “hosted in the EU” and “under EU jurisdiction” are not the same sentence.

Neither of these means EU agencies cannot use technology with any US connection — plenty of compliant setups exist. It means the jurisdiction and control questions are load-bearing, and a residency claim that only talks about geography is quietly leaving them unanswered.

“Hosted in the EU” vs. residency on your own account

The difference is easiest to see side by side. The columns below compare a typical vendor “hosted in the EU” promise with a database provisioned on your own cloud account, in a region you chose.

Question	“Hosted in the EU” (vendor promise)	Residency on your own account
Who chooses the region	The vendor, as a policy	You, at provisioning time
Who can change it later	The vendor, often without notice	You — it is your resource
Whose account holds the data	The vendor’s	Yours
Jurisdiction exposure	Depends on the vendor’s / parent’s legal home	Bounded by your account and region choice
Sub-processor chain	The vendor’s full list, which can grow	Shorter — infrastructure you already contract with
Proof for an auditor	A clause in a policy	A resource visible in your own dashboard
What happens on exit	Export, then trust deletion	The database stays yours; the vendor loses access

The point is not that “hosted in the EU” is dishonest — plenty of vendors mean it sincerely. It is that every row on the left is a promise you have to trust, and every row on the right is a fact you can inspect. For a data sovereignty question at agency scale, inspectable beats trustworthy.

How choosing your own region on your own account guarantees residency

This is the design decision behind sSystm and, more broadly, the BYOC (Bring Your Own Cloud) model: there is no central vendor database holding your CRM data. When your organisation signs up with its own Cloudflare account, sSystm provisions a dedicated Cloudflare D1 database on your account, in the region you choose, with an optional hard EU-jurisdiction guarantee.

Why that is a stronger residency claim than “hosted in the EU”:

• You pick the region, and it is your resource. The database appears in your own Cloudflare dashboard. Residency isn’t a setting the vendor manages for you — it is a choice you made on infrastructure you control.
• The EU-jurisdiction guarantee is hard, not a preference. With it enabled, the database is pinned to EU jurisdiction rather than defaulted there and potentially moved. That directly addresses the sovereignty half of the question, not just the geography half.
• The chain is shorter and closer to you. The data sits on infrastructure you already have a direct relationship with, which shortens the list of parties with technical access — the thing your Article 30 records have to track.
• Exit doesn’t move the data. Because the database was always on your account, leaving the platform revokes the vendor’s access rather than triggering a migration. There is nothing to export because there is nothing to leave behind.

None of this removes your responsibilities as the data controller. sSystm still operates the software and still counts as a processor under GDPR, so you still need your own DPA, your own sub-processor documentation, and — if this is a live compliance question — your own legal review. What changes is the strength of the underlying claim: you can show the database, the account and the region instead of quoting a policy. More detail on the security and data model lives on the security page.

How to actually guarantee EU data residency: a checklist

Before you write a residency claim into a client DPA, confirm the following about any tool you use — sSystm included:

1. Is the database on my account or the vendor’s? Dedicated-but-vendor-owned is isolation, not residency you control.
2. Can I choose the region — and is that a real provisioning choice or a marketing line? Ask to see it in your own console.
3. Is EU jurisdiction guaranteed or merely defaulted? A default can drift; a guarantee is a commitment.
4. What is the full sub-processor list, including backups, logs, email and AI features? The soft spots are usually outside the primary database.
5. Is the vendor (or its parent) subject to foreign access laws? This is the Schrems II / CLOUD Act question — and it survives an EU region.
6. What happens on exit? The right answer is: the vendor loses access, you keep the data, with no export step.

If a vendor answers the first three with “on your account, your chosen region, guaranteed EU jurisdiction,” you have a residency claim you can prove. If the answers are all “trust our policy,” you have a promise — which may well be honoured, but is not the same thing.

Where this leaves you

EU data residency is not a checkbox; it is three questions — location, jurisdiction and control — and “hosted in the EU” only answers one of them. Schrems II and the US CLOUD Act are the reason the other two matter, because they show that where a disk sits and whose law reaches it can diverge. The most robust answer available to an agency today is to keep the database on your own account, in a region you choose, under a hard EU-jurisdiction guarantee — so residency becomes a resource you can point at rather than a promise you have to believe.

Start with what a BYOC agency OS is for the underlying model, read the deeper GDPR and sub-processor breakdown, and see the security and data model for how the connection works in practice. This article is general information about data residency, not legal advice; for your specific obligations, talk to counsel.