Sovereign cloud in Europe: residency is not the same as jurisdiction.

This page is the engineering perspective. If your DPO, your auditor or a procurement gate is asking what "sovereign" actually means in 2026, this is the version that holds up under scrutiny.

Residency vs. sovereignty: the distinction that decides everything

The cloud industry has spent fifteen years training buyers to ask the wrong question. "Where is the data hosted?" is a residency question. The answer can be technically correct and legally meaningless at the same time, because sovereignty is not about geography. It is about which courts can compel a provider to act.

An EU region on a US hyperscaler, such as AWS Frankfurt, Azure West Europe or GCP Belgium, keeps the bits in the EU. It does not remove the parent company from US jurisdiction. Under the US CLOUD Act (2018), a US-headquartered provider can be compelled to disclose customer data held anywhere in the world, including in EU regions. FISA 702 imposes the same exposure for the surveillance side. The European Data Protection Board has flagged this explicitly as a Schrems II problem.

"Sovereign" therefore means three concrete things, all at once:

1. The legal entity holding your data has no parent in a third country with extraterritorial data-disclosure laws.
2. No subprocessor in the data path is in such a country either.
3. You, not the provider, control the encryption keys, or the keys live with a custodian outside the third country.

Pass all three and you have sovereignty. Fail any one and you have residency. The terminology in your DPA, your privacy policy and your customer-facing pages should reflect which one it actually is.

Why "EU subsidiary" is not the answer

A common workaround pitched by US hyperscalers is the EU subsidiary structure. Microsoft Ireland, AWS EMEA SARL, Google Cloud EMEA Ltd. The argument is that the European entity is the contracting counterparty under EU law.

This does not solve the jurisdictional problem. Under the CLOUD Act, the test is not which subsidiary signed the contract. It is whether the parent company has "possession, custody or control" of the data. A wholly owned EU subsidiary is, by design, controlled by the parent. The CJEU and EDPB analysis in Schrems II treats the parent's exposure as the operative one.

So when a vendor offers a "European" plan that is operated by an EU subsidiary of a US group, the right question to ask is: "Can your US parent company be compelled to instruct you to disclose data without our consent or knowledge?" The honest answer is yes.

The pseudo-sovereign middle tier

2024 to 2026 saw a wave of "sovereign" partnerships announced, typically a European systems integrator licensing the technology stack of a US hyperscaler and operating it under European management. Examples in the market today:

• Licensed sovereign offerings, built on US hyperscaler technology, operated by a Europeane Telekom subsidiary.
• Bleu, a French sovereign cloud built on Microsoft Azure technology, operated by Capgemini and Orange.
• S3NS, a Thales and Google joint venture in France.

These offerings can be useful for specific compliance regimes, but they are not what an engineering team should call sovereign without qualification. The technology stack, the platform updates, the security patches and, crucially, the operational know-how originate from the US partner. In the worst-case threat model where the US side withdraws cooperation or is compelled to do so, the European operator inherits a stack they cannot independently maintain.

For most buyers, the cleaner architectural answer is to build on infrastructure where there is no US dependency in the supply chain at all. That is what we mean when we talk about a sovereign stack at Binadit.

What a sovereign EU stack actually looks like

Here is a concrete reference architecture for a mid-market SaaS or regulated workload running entirely under EU jurisdiction. None of these are exotic; all are production-grade.

• Compute & storage: Binadit managed compute and dedicated hardware, on EU infrastructure under EU jurisdiction.
• Object storage: Ceph or MinIO, S3-compatible, operated by us on the same infrastructure.
• CDN: Bunny.net (SI), KeyCDN (CH), or self-managed at the edge for full control.
• DNS: PowerDNS or Knot, authoritative and DNSSEC signed, or Bunny DNS where you want it bundled with the CDN.
• Email delivery: Mailgun EU (with care, because of the US parent), or fully EU options like Postmark EU, Mailpace, Tuta business, or self-hosted Postfix on the same infrastructure.
• Error tracking: Self-hosted GlitchTip or Sentry, or Sentry's EU-region deployment with the trade-offs documented.
• Analytics: Plausible (EU-hosted), Matomo (self-hosted or EU cloud), Pirsch.
• Observability: Self-hosted Prometheus + Grafana + Loki, or EU-managed equivalents (Grafana Cloud EU, Last9 with EU region).
• Key management: Hashicorp Vault on EU infra, or EU-managed KMS providers; for high-trust scenarios, on-premises HSM with cloud-side BYOK.
• CI/CD: GitLab self-hosted, Forgejo, Gitea, or the GitLab.com EU instance. Never the default github.com for code that touches personal data without supplementary measures.

The point is not that any one of these is "the" answer. The point is that the entire stack can be assembled with EU-headquartered providers, and a managed-infrastructure partner can run it for you the same way an AWS-native partner would run AWS.

The four-question test, in detail

1. Residency: where, exactly

Not "in the EU" but which datacenter, in which country, under which jurisdiction. EU is not a single legal regime; the GDPR is harmonised but the supervisory authority is local, and so is the legal recourse if a provider fails. Document the country code for primary, secondary and backup locations in your DPA.

2. Subprocessors: every one of them

In our audits of mid-market environments, the unmapped subprocessor chain is the single most common finding. The application is on EU infrastructure, which is good. But the image-optimisation API it calls is US-hosted. The transactional email is sent through a US ESP. The error tracker is the US default. The customer support widget loads JavaScript from a US CDN. Each is a separate data flow. Each needs a legal basis if data crosses to a third country.

A sovereign stack requires a complete subprocessor list, including the third-party APIs your application calls and not just the infrastructure providers. Ours is named in full in the data-processing agreement, and we will send it before you sign anything.

3. Jurisdiction: who can compel disclosure

The legal-process question. For each entity in your data path, identify the parent company's headquarters. If any parent is in the US, China, Russia or another country with extraterritorial data-access laws, that entity is exposed. EU subsidiary status of a US parent does not solve it.

This is where the architecture diagram becomes a legal document. Draw it once, review it quarterly.

4. Key custody: who can technically read the data

Encryption at rest is necessary but not sufficient. The question is who holds the keys. Provider-managed keys offer no protection against the provider being compelled to decrypt. BYOK (Bring Your Own Key) helps the compliance narrative; the provider still holds a runtime copy. HYOK (Hold Your Own Key) is the only model where the cloud provider physically cannot read the data without an active call to your key custodian. Pick the model the threat model demands.

The migration path: from AWS Frankfurt to a sovereign stack

The fear of moving off a hyperscaler is usually larger than the actual project. A typical mid-market migration runs in three phases:

1. Inventory and audit (1-2 weeks). Map every data flow, identify every subprocessor, classify by US exposure. Output: a remediation list ranked by risk and migration complexity.
2. Quick-win removals (2-4 weeks). Replace the soft dependencies first: error tracking, analytics, CDN, DNS, email. These move with little or no application change.
3. Core migration (4-8 weeks). Compute, storage, database. Use streaming replication for zero-downtime database moves; use blue-green or DNS-failover patterns at the application tier. The hard part is rarely the technology. It is the choreography.

Total elapsed time for a 6-8 person engineering team with their day jobs to do: ten to sixteen weeks. With a managed-infrastructure partner driving the migration, four to twelve. The cost difference of running the sovereign stack versus the hyperscaler is, in our experience, neutral to negative for predictable workloads, modestly higher for spiky workloads, and significantly lower once egress and bandwidth are factored in.

"Is sovereign cloud more expensive?" The honest answer

For 80% of mid-market workloads, the sovereign stack is cheaper over five years, mostly because EU providers do not charge punitive egress fees and because dedicated and bare-metal pricing is dramatically better than equivalent hyperscaler instance types. The cases where the sovereign stack is more expensive are: highly bursty workloads that benefit from sub-second autoscaling, workloads that lean on a specific managed service (DynamoDB, BigQuery, Lambda) that has no clean equivalent, and ML training workloads requiring a specific accelerator generation.

A competent engineering review will tell you in a week which category you are in. If you would like one, that is what we do for a living.

Regulatory tailwind: NIS2, DORA, EHDS, and AI Act

The regulatory direction of travel through 2025 to 2027 is towards stricter supply-chain accountability:

• NIS2 (Article 21): essential and important entities must conduct supply-chain risk assessments and contractually flow security obligations to subprocessors. A US-jurisdiction subprocessor is hard to defend in this assessment without supplementary measures.
• DORA (in force January 2025): financial entities must maintain a register of ICT third-party providers and an exit strategy for critical providers. The concentration risk language explicitly targets reliance on dominant non-EU providers.
• European Health Data Space (EHDS): secondary-use of health data is restricted to processing environments under EU jurisdiction.
• EU AI Act: high-risk AI systems require traceable training-data provenance, which is practically very difficult on a US foundation-model API.

None of these regulations ban US providers. They make the documentation and supplementary-measure burden high enough that, for most use cases, a sovereign stack is the lower-friction choice.

What we do not claim

For honesty: there are workloads where a sovereign EU stack is harder than a hyperscaler. Multi-region active-active with sub-50ms global latency. Specific managed analytics warehouses. Hyperscale ML inference on the latest accelerators. We will tell you when your workload falls in that category. For 90% of the SaaS, e-commerce, B2B platforms and regulated workloads we see, the sovereign stack is not just compliant. It is also faster, cheaper, and easier to reason about.

Where Binadit fits

We are an Article 28 data processor headquartered in Rotterdam, the Netherlands. Our infrastructure footprint is 100% on EU-headquartered providers. Our subprocessor list is named in full in the data-processing agreement and available on request. We do not take engagements that would require a US-jurisdiction subprocessor in the default data path. Where a workload genuinely requires one (a third-party SaaS the customer insists on), we document it in writing, include the supplementary measures, and surface the residual risk to the DPO before signing.

If that sounds like the kind of partner you have been looking for, the next step is a 30-minute scoping call.