Digital Sovereignty in the EU: Navigating Schrems II, GDPR, and Local Hosting Mandates

On 16 July 2020 the Court of Justice of the European Union threw out the EU-US Privacy Shield, and an awful lot of European companies discovered overnight that the legal basis for storing their users’ data in an American cloud had evaporated. The case is known as Schrems II, after the Austrian lawyer Maximilian Schrems who spent the better part of a decade dragging Facebook’s data transfers through the courts. The ruling did not say “you may never send data to the US.” It said something more awkward: that you, the data exporter, are now personally on the hook for proving that the country you ship data to protects it to an EU standard — and that for the US specifically, given what the NSA was doing, that protection was inadequate.

I am not a lawyer, and this is not legal advice. But I run my own infrastructure, and the entire saga turned out to be the best possible argument for doing so. When you self-host, “where does the data live and who can compel access to it” stops being a contract clause you can’t read and becomes a fact you control. That is what digital sovereignty actually means, stripped of the conference-keynote gloss. This post is about what the law really requires, why the cloud answer keeps wobbling, and how a homelab-shaped approach sidesteps most of the problem.

1 What Schrems II actually broke

The mechanics matter, because most summaries get them wrong. GDPR forbids exporting personal data to a “third country” unless that country offers protection “essentially equivalent” to the EU’s. There are a few ways to satisfy that: an adequacy decision (the Commission blesses an entire country), standard contractual clauses (SCCs — boilerplate the two parties sign), or binding corporate rules.

Privacy Shield was an adequacy framework for the US. Schrems II killed it because US surveillance law — FISA Section 702 and Executive Order 12333 — let intelligence agencies reach into data held by American providers in a way EU law considers disproportionate, with no meaningful redress for an EU citizen. The Court then turned to SCCs, the fallback everyone reached for, and delivered the sting in the tail: SCCs remain valid in principle, but a contract clause cannot bind the NSA. So the exporter must assess the destination country’s law and, where it falls short, add “supplementary measures” — extra technical or organisational safeguards — or stop the transfer.

Read that again, because it is the crux. The Court put the burden of a country-level legal assessment onto every business shipping data abroad. A two-person startup using a US analytics tool is, on paper, expected to evaluate American surveillance law and decide whether encryption-at-rest is enough to neutralise it. That is plainly absurd as a compliance task, which is why the whole area has been a slow-motion shambles ever since.

2 The 2023 patch, and why it’s wobbly

In July 2023 the Commission adopted a new adequacy decision: the EU-US Data Privacy Framework. It is, broadly, Privacy Shield with a fresh coat of paint — proportionality limits on US intelligence access and a new Data Protection Review Court for redress. US firms can self-certify under it, and transfers to certified firms are once again “adequate” without extra paperwork.

If your instinct is “didn’t this exact thing get struck down twice already,” your instinct is good. Privacy Shield replaced Safe Harbour (killed by Schrems I in 2015). The Data Privacy Framework replaces Privacy Shield (killed by Schrems II in 2020). Schrems himself has already signalled a challenge, and the framework rests on a US executive order that a future administration could amend with a signature. Building a business on a legal foundation that has collapsed twice in a decade is a particular kind of optimism. The General Court rejected an early challenge in 2025, but the substantive Schrems-style case has not had its day yet.

This is the part that pushed me, years ago, toward keeping the data I care about on hardware I can point at. It is the same instinct that runs through the SaaS trap and per-seat pricing: the more your operation depends on someone else’s terms, the more exposed you are to those terms changing under you. Legal adequacy is just another dependency that can break.

3 Sovereignty for people who run their own metal

Here is where self-hosting quietly wins. The entire Schrems problem is a transfer problem — it only bites when personal data crosses into a jurisdiction with hostile law. If the data never leaves a box in your own rack, in your own member state, the transfer question never arises. There is no third country to assess. The “supplementary measures” the Court wants are things you can simply do, rather than negotiate.

That does not make you exempt from GDPR — you are now the data controller and the processor, and all the substantive obligations (lawful basis, minimisation, retention limits, breach notification, subject access requests) land squarely on you. What it removes is the international-transfer headache and the act of faith in a provider’s certifications. You trade “trust a contract” for “own the risk,” which is a trade I’ll take every time, because at least I can audit my own setup.

A minimal self-hosted analytics stack illustrates the point. Instead of dropping a US tracker onto every page, run something like Plausible or Matomo on your own VPS in, say, Frankfurt or Helsinki:

# docker-compose.yml — self-hosted, EU-resident web analytics
services:
  plausible:
    image: ghcr.io/plausible/community-edition:v3
    restart: unless-stopped
    command: sh -c "/entrypoint.sh db createdb && /entrypoint.sh run"
    depends_on:
      - db
      - events_db
    ports:
      - "127.0.0.1:8000:8000"   # bind to loopback; reverse-proxy with TLS in front
    env_file:
      - plausible-conf.env

  db:
    image: postgres:16-alpine
    restart: unless-stopped
    volumes:
      - db-data:/var/lib/postgresql/data

  events_db:
    image: clickhouse/clickhouse-server:24.12-alpine
    restart: unless-stopped
    volumes:
      - event-data:/var/lib/clickhouse

volumes:
  db-data:
  event-data:

No data leaves the host. No US sub-processor sees your visitors’ IPs. The transfer-impact-assessment paperwork that would accompany a US analytics SaaS shrinks to a single sentence: processing occurs on infrastructure located in [member state], no third-country transfer takes place. That is the whole pitch for sovereignty — not that it’s free, but that it collapses an entire category of legal uncertainty into a fact you can verify with traceroute.

4 Encryption is necessary, not sufficient

The popular “supplementary measure” is encryption, and it’s worth being precise about what it buys. The European Data Protection Board’s guidance is clear: encryption helps only if the data is unintelligible to the foreign provider and you hold the keys. Encrypting data with keys your US cloud provider also holds is theatre — they can be compelled to hand over both. The phrase to internalise is the provider must never have access to the plaintext or the keys.

For a self-hoster that means client-side or host-side encryption where you control the key material, and storing those keys off the platform that holds the ciphertext. If you back up to an offsite or cloud target, encrypt before it leaves your control:

# Encrypt a backup locally with age, then push only ciphertext offsite.
# The remote (even a US bucket) only ever sees an opaque blob.
tar czf - /srv/data \
  | age -r age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8v \
  > /backups/data-$(date +%F).tar.gz.age

# Restore: decrypt with the private key that never left your machine
age -d -i ~/.age/key.txt /backups/data-2025-05-08.tar.gz.age \
  | tar xzf - -C /restore

The age private key lives on your machine and nowhere else. A subpoena served on the storage provider yields a blob they cannot read. That is a supplementary measure in the EDPB’s sense, and it’s the same discipline that should govern any sensitive backup regardless of the legal angle — a theme I keep returning to whenever the topic is the real cost of self-hosting, because key management is precisely the kind of ongoing work that doesn’t show up on a price comparison.

5 Where the cloud still makes sense

I am not a sovereignty absolutist, and pretending self-hosting is always the answer would be dishonest. Plenty of EU cloud regions are genuinely useful: AWS Frankfurt, OVHcloud, Hetzner, Scaleway, the various “EU sovereign cloud” offerings. The honest distinction is about who can be compelled. A wholly EU-owned and EU-operated provider sits outside the reach of FISA 702 in a way that the EU region of a US-headquartered hyperscaler does not — the US CLOUD Act can reach data held by a US company wherever in the world that data physically sits. “It’s in Frankfurt” is not the protection people assume when the parent company is in Seattle.

So the spectrum runs roughly: US SaaS with US data (worst for sovereignty) → US hyperscaler’s EU region (better latency, still CLOUD Act exposure) → EU-owned provider (no US compulsion path) → your own hardware (no provider compulsion path at all, you carry every other risk yourself). Pick the rung that matches your threat model and your appetite for operational work. For a hobby blog, an EU hyperscaler region is fine. For health records or anything genuinely sensitive, the further down that list you go, the fewer awkward legal conversations you’ll have.

6 Common mistakes and how to avoid them

A few traps catch people repeatedly, and they’re worth flagging because the law’s complexity hides them.

Assuming “EU region” means “no transfer.” As above — a US-owned provider’s EU datacentre is still reachable under the CLOUD Act. If sovereignty is the goal, the ownership and headquarters of the provider matter as much as the datacentre’s postcode.

Forgetting the sub-processors. Your tidy EU stack means nothing if your error-tracking, email, or CDN quietly routes through a US service. Audit the whole request path. A single US-based font CDN or analytics pixel re-introduces the transfer you were trying to avoid — German courts have already fined sites for embedding Google Fonts that leaked visitor IPs to the US.

Treating encryption as a magic word. If the provider holds the keys, you have not added a supplementary measure, you’ve added a false sense of security. Hold the keys yourself or it doesn’t count.

Ignoring your own GDPR duties once you self-host. Becoming the controller means you owe data subjects the same rights a big provider would — access, erasure, a lawful basis, a retention policy you actually enforce. Sovereignty is not an exemption; it’s a transfer of responsibility onto you. Treat your own logs and backups as the personal data they are. The same discipline that governs accounting for your own time applies here: the obligations don’t disappear, they move onto your plate.

7 Is it worth it, and who is this for?

If you run a hobby project or a small site with no special-category data, the honest answer is that you can lean on the Data Privacy Framework or an EU cloud region and sleep fine — just keep the keys to anything sensitive yourself and audit your sub-processors once a year. The legal machinery, wobbly as it is, mostly holds for low-stakes processing.

Self-hosting for sovereignty earns its keep when the data is genuinely sensitive, when you operate in a regulated sector, or when you simply refuse to bet your compliance posture on an executive order surviving the next administration. The reward is not that it’s cheaper or easier — it usually isn’t — but that an entire class of legal uncertainty disappears, replaced by risks you can see, audit, and fix yourself. After watching two transatlantic data frameworks get struck down in five years, I find “the data is on my hardware, in my country, and I hold the keys” a far more restful place to stand than “our provider says we’re certified.” Whether that restfulness is worth the operational work is the calculation only you can run — but at least, this way, you’re the one running it.