Sovereignty Is a Supply-Chain Problem

Sovereignty Is a Supply-Chain Problem#

Core thesis#

EU data sovereignty is achievable today, with today’s vendors, at commercial prices. We built a data services company on that premise and it holds.

But it is not a checkbox, and it is not a procurement filter you can apply in an afternoon. It is a supply-chain audit that runs the full depth of the stack, and the two failure modes that matter most are invisible on any pricing page.

Geography is not jurisdiction#

The first thing to unlearn: “hosted in the EU” is a statement about latency, not about law.

A datacenter in Frankfurt operated by a US-controlled entity is within reach of the US CLOUD Act. The Act follows control, not cabling. A vendor with an EU brand, EU offices, EU invoicing, and an EU datacenter can still be obligated to produce data under US legal process if the ownership chain terminates in a US parent.

This is not hypothetical for us. More than one vendor was eliminated from our stack for exactly this reason — cross-ownership structures that placed a European-presenting service under US jurisdiction. In no case was this disclosed prominently. In every case it was discoverable: registry filings, annual reports, acquisition announcements. The information exists. It is simply not where the marketing is.

Telemetry is the second leak#

The subtler failure mode: the vendor is genuinely EU-owned and EU-hosted — and the product phones home anyway.

Error reporting to a US SaaS. Analytics beacons. A CDN for fonts and scripts. A support widget. Each of these is a data flow to a US cloud, each is a subprocessor whether or not the vendor thinks of it that way, and each one appears on the wire whether or not it appears in the DPA.

The honest vendors list their subprocessors and keep the list current. For the rest, the network tells the truth. We made a habit of watching outbound traffic before signing anything, and it changed decisions.

The coverage gap#

Here is the part that deserves to be stated plainly, without complaint but without varnish: at almost every layer of the stack, the pure-EU market is thinner than the US market. Often much thinner.

Where a US-jurisdiction buyer chooses among ten mature options — hosting, transactional email, monitoring, payments, banking, AI inference — the buyer who requires EU ownership and EU hosting and a clean subprocessor chain chooses among two or three. Sometimes one. Occasionally, after the audit finishes, the honest count is zero, and the answer is a Debian server and a daemon you operate yourself.

This is a market observation, not a grievance. The gap is real, it is measurable in research hours, and anyone telling you sovereign procurement is frictionless has not done it.

What we found#

Some categories have genuine depth. European infrastructure hosting is excellent — the German providers in particular are mature, well-priced, and straightforwardly under EU jurisdiction. This layer was the easiest decision in the stack.

Other categories required real work. Banking for a small EU entity involved more elimination rounds than expected. Monitoring and alerting largely resolved to self-hosting, because so much of the commercial tooling either sits under US control or leaks telemetry into US clouds by default. AI inference was the most constrained category of all: EU-native options exist and are improving quickly, and for anything beyond them, the processing terms have to be read line by line — where the model runs, where the logs live, who the subprocessors are — before a single customer record goes near an API.

The pattern across all of it: the sovereign option nearly always exists. It is rarely the default, rarely the best-known name, and never the path of least resistance.

The method#

What made this tractable was treating it as an engineering discipline rather than a procurement preference:

  1. Resolve the ownership chain to ultimate control. Registry filings and acquisition history, not the About page. Three layers deep is common.
  2. Read the subprocessor list before the feature list. A missing or stale subprocessor list is itself an answer.
  3. Watch the wire. Outbound traffic from a trial deployment tells you what the documentation won’t.
  4. Prefer self-hostable. When the audit fails, a well-understood open source daemon on your own hardware passes it. This is the UNIX position: small components you control compose into a system you can attest to.
  5. Re-audit on acquisition news. Sovereignty is a state, not an event. An ownership change upstream can silently change your jurisdiction overnight.

None of this is exotic. It is the same rigour a supply-chain engineer applies to components: provenance, dependencies, failure modes. The data stack deserves the same treatment as the bill of materials.

Why this is good news#

The temptation is to read the thin coverage as an indictment. I read it the other way.

First: it can be done. We are the existence proof, and we are not special — a small company with no procurement department assembled a fully EU-sovereign stack using commercially available services plus a modest amount of self-hosting. The cost was research and attention to detail, not miracles and not enterprise budgets.

Second: every gap in that coverage is a business. The European market does not lack demand for sovereign services; it lacks depth of supply, and depth of supply is exactly the thing that new entrants fix. The audit discipline that today filters vendors out will, in a few years, be the baseline those vendors are built to pass.

Sovereignty is not a constraint we route around. It is a requirement we engineer to — and the engineering is entirely within reach.