Sovereignty by Architecture, Not by Promise

Part of the pillar series Sovereignty You Can Actually Operate.

If you've ever evaluated a cloud provider's "sovereign" offering, you've seen the reassurance: your data stays in our EU region. It sounds decisive. It is also, on its own, beside the point.

We argued the why of European dependence in the companion piece. This post is about the how: why location does not equal control, and what it actually takes to make data residency a guarantee you can prove rather than a promise you have to trust.

Data residency vs data sovereignty

Start with the distinction that the whole field turns on.

	Data residency	Data sovereignty
What it controls	Where data physically sits	Whose laws govern it, and who can compel access
Unit	Geography (a region, a data center)	Jurisdiction (a legal system, a corporate chain)
How it's delivered	Provider configuration	Architecture + ownership
Defeated by	A provider quietly re-homing the bytes, or an adequacy decision withdrawn	A lawful order to the provider's parent company

Residency answers "where are the bytes?" Sovereignty answers "who can be compelled to hand them over, or to decrypt them?" You can have perfect residency and zero sovereignty at the same time.

Why location ≠ control

Here is the mechanism that makes an "EU region" insufficient. Jurisdiction follows the provider's corporate nationality, not the data's coordinates.

Under the US CLOUD Act, a demand served on a US-headquartered company reaches data it controls anywhere in the world: Frankfurt, Dublin, Amsterdam included. Storage location is legally irrelevant; what matters is that the provider is subject to that jurisdiction. The clearest confirmation came from a hyperscaler itself: asked under oath whether French data could be shielded from US authorities, Microsoft France's representative said, "No, I cannot guarantee it." (The Register, 2025)

This is also why the legal "fix" for transatlantic transfers is fragile. The EU–US Data Privacy Framework was upheld by the EU General Court in 2025, but it remains an adequacy decision that can be annulled, and the underlying access powers it sits alongside are untouched. In mid-2026, US legal and political changes affecting agency independence and surveillance authorities reopened exactly these questions (WilmerHale, 2025). A promise can be withdrawn. Architecture cannot.

Is an EU region enough for GDPR?

Short answer: no, not on its own. Choosing an EU region changes where data sits, not which government can compel access to it. For GDPR you also need a valid transfer position and, crucially, technical and organizational measures that hold even if the provider is lawfully ordered to act against your interests. An EU region is a necessary ingredient, not the finished dish.

The "sovereign cloud" labels, and what they leave out

The market has responded with tiers, certifications, and "sovereign" SKUs. They are not all equal. The EU's own Cloud Sovereignty Framework scores offerings on a ladder (SEAL-0 to SEAL-4), and the gap between the rungs is the whole story.

SEAL level	What it means
SEAL-1	EU contracts exist on paper, but a foreign parent can still compel access
SEAL-2	EU law is applicable and enforceable (the procurement eligibility floor)
SEAL-3	Meaningful EU control; service immune to non-EU supply-chain disruption
SEAL-4	Full EU control, zero non-EU dependencies; no provider has reached it

Source: European Commission, Cloud Sovereignty Framework, 2026. In the April 2026 EU sovereign-cloud tender, the European awardees reached SEAL-2 and SEAL-3.

The residual gaps in US-parented "sovereign" offerings are consistent: control of the software roadmap stays with the foreign parent; encryption keys may still be technically reachable by the provider; operational and support access paths remain; and the ultimate corporate jurisdiction is unchanged. Independent analysts have been blunt that wholly-owned "sovereign" clouds keep CLOUD Act exposure that "never fully goes away" (InfoQ, 2026).

Residency by construction: the enforcement primitives

So what makes residency an architectural guarantee? The shift is from "we promise not to move it" to "we are technically incapable of disclosing it." Four primitives do the work.

1. Customer-held / external keys. If the operator never holds your decryption keys, a legal order produces ciphertext. There is nothing readable to hand over. This is the single highest-leverage control, and the reason "encrypted at rest" alone is not enough: what matters is who can be compelled to produce the key.

2. Encryption in transit, at rest, and in use. The first two are table stakes. Processing data inside hardware-isolated environments, with verifiable attestation, narrows the window where plaintext is exposed to the operator.

3. No-egress regional isolation. Compute and storage that cannot replicate out of a chosen jurisdiction by default: localization designed into the system, not promised in a policy.

4. Independent EU operation. The decisive, non-technical primitive: an operating entity governed by EU law and not controlled by a foreign parent. This is the part that actually severs the chain of compulsion, and it's why genuinely sovereign offerings tend to be operated by European entities, not foreign-owned subsidiaries.

Put together, these four primitives are what turn a promise ("we won't move your data"), one that depends on trust and a stable legal regime and can be revoked, into a property of the system that holds even under a lawful order.

How we built the Soveryne Cloud Foundation

The platform page for the Soveryne Cloud Foundation carries one line that summarizes our entire design philosophy, and the title of this post: sovereign by architecture, not by promise. That wasn't marketing-first. It was an engineering constraint we set ourselves.

So the foundation is built on those primitives. Files and data are encrypted end to end, in transit and at rest, with keys held inside EU jurisdiction, so what is yours stays yours, and there is nothing for a foreign order to compel. You control which EU regions your compute and storage live in, by design. AI and LLM inference run on EU-sovereign infrastructure, because, as we argue in detail elsewhere, the prompt is the data, and sending it to a foreign GPU is a transfer like any other. And it is operated end to end by an EU entity, on our own infrastructure, with no US-jurisdiction subprocessor in the data path and no US-held keys and an open-source core you can inspect.

For organizations that need the strictest posture, the Soveryne tier provides a dedicated environment with its own inference GPUs, on-premises deployment options, and knowledge transferred to your own team, so sovereignty never quietly becomes dependence on us either. Where you need grounded, cited answers that stay in-jurisdiction, that's exactly what Counsel is built to do.

FAQ

What is the difference between data residency and data sovereignty? Residency is where data physically sits; sovereignty is whose laws govern it and who can compel access. Residency is geography; sovereignty is jurisdiction.

Can the US access EU data under the CLOUD Act? Yes, if the provider is subject to US jurisdiction. A US-headquartered company can be compelled to produce data it controls, regardless of where that data is stored.

Does the CLOUD Act apply if the data is encrypted? It depends on who holds the keys. If the provider can be compelled to decrypt, encryption doesn't defeat the order. If the keys are held externally by the customer or an independent EU entity, the order produces only ciphertext.

Is choosing an EU region enough for GDPR compliance? No. It addresses residency, not the question of foreign legal compulsion. You also need a valid transfer position and technical/organizational measures: ideally external key custody and EU-controlled operation.

---

Sovereignty is a property you can engineer and prove, not a checkbox you trust. See the architecture in practice, explore the Soveryne Cloud Foundation, or read the companion piece on Europe's real dependence map.

Sources

• The Register, Microsoft "cannot guarantee" data sovereignty (2025): https://www.theregister.com/2025/07/25/microsoft_admits_it_cannot_guarantee/
• European Commission, Cloud Sovereignty Framework explained (2026): https://commission.europa.eu/news-and-media/news/sovereign-cloud-framework-explained-2026-06-01_en
• InfoQ, analysis of US-parented sovereign cloud and CLOUD Act exposure (2026): https://www.infoq.com/news/2026/01/aws-european-sovereign-cloud/
• WilmerHale, CJEU to review the EU–US Data Privacy Framework (2025): https://www.wilmerhale.com/en/insights/blogs/wilmerhale-privacy-and-cybersecurity-law/20251201-european-court-of-justice-to-review-challenge-to-eu-us-data-privacy-framework
• CSIS, the CLOUD Act and transatlantic trust: https://www.csis.org/analysis/cloud-act-and-transatlantic-trust
• BSI, C3A, Criteria enabling Cloud Computing Autonomy (2026): https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Angriffszielen/Cloud-Computing/C3A/C3A.html