Sovereignty & Data
‘Hosted in Europe’ doesn't mean sovereign
It has become the reassuring default checkbox: "data hosted in Europe." You tick it, you breathe out, you move on. The problem is that it answers the wrong question. What decides the sovereignty of your data isn't where your servers sit — it's the nationality of the company that controls them.
Let's put it plainly, because that's the spirit of this blog: a server in Paris operated by a US company is not a sovereign server. Not because the host is lying about the location — they're telling the truth. But because location isn't the right criterion. The criterion is: who can be legally compelled to hand over the data, and under which law?
The reassuring badge that misses the point
"Europe region," "Frankfurt datacenter," "stored in France": these mentions are everywhere, and they aren't false. AWS, Microsoft Azure, Google Cloud, Cloudflare — they all offer European regions, and they really do store your data there.
But digital sovereignty isn't measured in kilometres. It's measured in jurisdiction: which law does the entity that holds and operates the service fall under? And there, the server's location changes nothing about the company's nationality.
The CLOUD Act, in one sentence
In 2018, the United States passed the CLOUD Act (Clarifying Lawful Overseas Use of Data Act). Its logic fits in a single line: a company subject to US law must hand over to US authorities the data it controls, wherever in the world it is stored.
The text was born precisely from a dispute on this very point: in the Microsoft v. United States case, the US government demanded emails stored by Microsoft… in a datacenter in Ireland. The CLOUD Act settled the debate in favour of access, regardless of where the data sits. The practical takeaway: for a US provider, "hosted in Dublin" or "hosted in Frankfurt" creates no legal barrier against US law.
And this isn't just a lawyers' quarrel. In 2020, the Court of Justice of the European Union, in the Schrems II ruling (C-311/18), struck down the Privacy Shield by pointing to exactly this risk: US authorities' access to Europeans' data, with no equivalent remedy. The data can be in Paris; the legal risk crosses the Atlantic.
"Adequate" isn't "sovereign" — two different axes
This is where a lot of people conflate two notions that have nothing to do with each other. Let's untangle them, because that's the whole trap.
- Adequacy (Article 45 of the GDPR) is a question of lawful transfer: the EU recognises that a given country — or a given framework, such as the EU-US Data Privacy Framework of July 2023 — offers protection deemed sufficient to send data there. It's a transfer authorisation.
- Sovereignty is a question of control: does the data, by its very nature, escape a power outside the EU? A provider can be perfectly "adequate" in the legal sense and entirely non-sovereign.
A clear example: a US service certified under the Data Privacy Framework is covered for transfer (legal axis), but remains subject to the CLOUD Act (sovereignty axis). The United Kingdom benefits from an adequacy decision — yet it's still part of the "Five Eyes", the intelligence alliance (United States, United Kingdom, Canada, Australia, New Zealand). "Legally transferable" and "beyond the reach of a foreign state" are two distinct things.
Sovereignty = ownership and control (does the company fall under the EEA?). Adequacy = right to transfer (can you legally send the data there?). A service can tick the second box without ticking the first. Everything else plays out in that gap.
The real blind spot: the dependencies you don't see
Say you've chosen a sovereign host for your site. Good. But your page isn't just a server: it's a constellation of third-party services that load in your visitors' browsers — and each one receives, at the very least, their IP address.
Google Fonts, Google Analytics, Tag Manager, reCAPTCHA, embedded YouTube, the Meta pixel, a Cloudflare or AWS CloudFront CDN, chat, A/B testing, maps… The median site lines up dozens of them. And the most prevalent on the web are nearly all American.
The most widespread third-party services are American
Worse: some trackers disguise themselves. With CNAME cloaking, a seemingly first-party subdomain (metrics.yoursite.com) actually points, via a DNS record, to a third-party tracker's infrastructure. To the naked eye, it looks like "yours." In reality, the data goes elsewhere — often outside the EU. This is exactly the kind of dependency an honest audit should expose rather than wave through.
Hosted in the EU ≠ sovereign: the test in practice
The right way to judge a dependency isn't to read the "where is your data" page. It's to ask, service by service, three questions:
- Who owns the company? A parent company in the EEA, or in the United States / United Kingdom / Canada / Australia? This is the decisive criterion.
- Does the data leave the visitor's browser? A network call to a third-party domain transmits the IP, and often more.
- Is the dependency disguised? A first-party subdomain can mask a transfer outside the EU via CNAME.
Nobody does this by hand across 40 requests. That's precisely what a sovereignty scanner automates: it lists every third-party service actually loaded, classifies it by jurisdiction (🇪🇺 sovereign / 🔴 non-sovereign / 🟠 to verify), unmasks CNAME cloaking, and suggests a European alternative for each dependency.
Curious about your own site? Our sovereignty checker lists your non-EU dependencies in 90 seconds, free and with no sign-up — a US/EU score, unmasked trackers and European alternatives.
Check my site's sovereignty →The good news: the alternatives exist
Sovereignty isn't wishful thinking, nor a functional sacrifice. For almost every building block of a site, there's an established EU option:
- Hosting / cloud: OVHcloud, Scaleway, Clever Cloud, Hetzner.
- Analytics: Snorklee, Matomo, Plausible, Piwik PRO.
- CDN: Bunny CDN, Scaleway.
- Fonts: self-hosted, or Bunny Fonts.
- Email / marketing: Brevo, Mailjet, MailerLite.
- Payments: Mollie, Adyen; anti-bot: DataDome, Friendly Captcha; chat: Crisp.
The goal isn't to plant a flag. It's to reduce exposure: less data leaving the EU, fewer third parties subject to foreign law, fewer grey areas to document. Every non-sovereign dependency you replace is one less dependency to justify in your records of processing.
The bottom line
"Hosted in Europe" is a useful mention, but it's only half an answer. The half that really matters — who controls the company, which law it answers to — stays beneath the surface. The CLOUD Act doesn't care about your servers' address; it cares about your provider's nationality.
Sovereignty, then, isn't a badge you display. It's a chain of dependencies you look at squarely: your host, but also your fonts, your analytics, your CDN, your third-party scripts, right down to trackers disguised as first-party. Snorklee was born from this very observation — audience measurement that's 100% sovereign, hosted in France, with no US dependency, no cookie and no banner. And the checker that comes with it is there for one thing: to show you, without flattery, what your site really carries.
Don't trust the badge. Look at the chain.
Is a service hosted in Europe necessarily sovereign?
No. That's the key point: a US provider like AWS, Microsoft Azure or Cloudflare remains subject to the CLOUD Act even if its servers are in Paris or Frankfurt. Sovereignty depends on the ownership and control of the company, not just on where the servers sit.
What exactly is the CLOUD Act?
A US law from 2018 that compels companies subject to US law to hand over to authorities the data they control, wherever in the world it is stored. It was born from the Microsoft v. United States case, which concerned data hosted in Ireland. The location of servers therefore creates no legal barrier against US law.
Does "adequate" under the GDPR mean "sovereign"?
No, they're two distinct axes. Adequacy (Article 45 of the GDPR) authorises a data transfer to a country or framework deemed sufficiently protective (for example the EU-US Data Privacy Framework). Sovereignty concerns control: a service can be adequate for transfer while still being subject to a foreign law like the CLOUD Act.
How do I know if my site relies on non-sovereign services?
By listing every third-party service actually loaded by the page and classifying it by jurisdiction. That's what a sovereignty checker automates: it identifies non-EU dependencies, unmasks CNAME-cloaked trackers, and suggests European alternatives — free and in a few seconds.
Are there credible European alternatives?
Yes, for almost every building block of a site: OVHcloud or Scaleway for hosting, Matomo, Plausible or Snorklee for analytics, Bunny CDN for the CDN, Brevo for email, Mollie for payments, and so on. Reducing exposure is rarely a question of availability — more often a question of habit.
Published June 2026. Main sources: CLOUD Act — Clarifying Lawful Overseas Use of Data Act, H.R. 4943 (2018); the Microsoft Corp. v. United States case (dispute over data hosted in Ireland, which gave rise to the text); CJEU, Schrems II ruling, C-311/18 (16 July 2020, invalidation of the Privacy Shield); EU-US Data Privacy Framework adequacy decision (10 July 2023); the "Five Eyes" intelligence alliance. Prevalence of third-party services: HTTP Archive, Web Almanac (Third Parties chapter) and W3Techs (usage shares, orders of magnitude, accessed in 2026). General information, not individualised legal advice — for a specific case, consult a DPO or a qualified lawyer.