All Posts
Digital SovereigntyData OwnershipCloud StrategyVendor Lock-inSovereign StackExit Readiness
The Sovereignty Spectrum: Why "My Data Is in Frankfurt" Isn't Enough Anymore
The Sovereignty Spectrum: Why "My Data Is in Frankfurt" Isn't Enough Anymore
Table of Contents (Anchor Links)
- Case study: The Jurisdictional Trap, in Two Acts
- Act 1 — The "virtual presence" precedent: OVHcloud vs. Canada
- Act 2 — The acquisition surprise: Kyndryl & Solvinity
- What digital sovereignty actually is
- Sovereignty is a spectrum, not a switch
- Why this matters now
- GitOps: A Deterministic Recovery Model
- Beyond Rhetoric: The European Reference Architectures
- The CNCF Sovereignty Stack
- Questions for your next Architecture Review
Case study: The Jurisdictional Trap, in Two Acts
Most architects believe that as long as their data sits in a server rack in Paris or Frankfurt, they are legally protected. This is a common architectural assumption, and the last twelve months have produced two case studies — both still live as I write this in April 2026 — that challenge it. Read them together. Each one addresses a specific jurisdictional vulnerability the industry has historically overlooked. Together, they explain why architectural sovereignty has moved from a compliance checkbox to a core design requirement.
Act 1 — The "virtual presence" precedent: OVHcloud vs. Canada
OVHcloud is one of the primary European alternatives to U.S. hyperscaler dependency. It is a French company, headquartered in Roubaix, that markets itself on the idea that "European data, on European soil, under European law" offers a meaningful legal boundary against U.S.‑style extraterritoriality. Its public stance on the U.S. CLOUD Act has been consistent for years: not subject to it, FISA, or the Patriot Act precisely because it is not a U.S.‑governed entity.
In April 2024, the Royal Canadian Mounted Police (RCMP) issued a Production Order under section 487.014 of Canada's Criminal Code, demanding subscriber information and metadata tied to four IP addresses. The data was hosted on OVH servers in France, the United Kingdom, and Australia. Critically, none of it was held in Canada, and the Canadian subsidiary — Hebergement OVH Inc. — had no technical access to the parent company's records.
French authorities invoked France’s blocking statute and urged Canada to route the request through the Mutual Legal Assistance Treaty (MLAT) channel, with the French Ministry of Justice formally intervening on 21 February 2025 to propose this route. Canada declined the diplomatic channel, opting instead to proceed through the domestic order.
Canada declined the diplomatic route. On 25 September 2024, Justice Heather Perkins-McVey of the Ontario Court of Justice ruled in favor of the order. Her reasoning rested on a doctrine of virtual presence because OVH Cloud operates globally and offers services in Canada, the corporate group as a whole was deemed within Canadian jurisdiction regardless of where the physical disks resided. The court also noted that OVH Canada had previously complied with an RCMP order for data stored in Germany, using that prior cooperation as evidence of "lawful and effective access."
The lesson is the doctrine, not the data. The OVHcloud case makes it clear that possession and control of data follow the corporate structure, not the GPS coordinates of the disk. If a provider has any subsidiary or point‑of‑presence in a jurisdiction, that jurisdiction’s courts may now feel entitled to reach across the corporate group. The “European cloud is automatically safer” thesis was fundamentally challenged on 25 September 2024, with its broader implications becoming a focal point of sovereignty debates in 2025 and beyond.
Act 2 — The acquisition surprise: Kyndryl & Solvinity
If OVHcloud showed how corporate structure leaks sovereignty, the Kyndryl–Solvinity story shows what happens when that structure changes and an architecture without a migration path loses its ability to choose its jurisdiction.
Solvinity is a Dutch managed-cloud provider hosting the platform for DigiD — the Dutch national digital identity system. Public-sector clients chose Solvinity because it was Dutch-owned and considered outside the reach of the U.S. CLOUD Act, at least under the governance structures in place at the time.
On 5 November 2025, Kyndryl Nederland B.V., a subsidiary of the U.S.‑listed IT‑services firm spun off from IBM, announced it had entered into an agreement to acquire Solvinity Group B.V. for an undisclosed sum, with some analyses citing an amount of at least €100 million. Under the deal, Solvinity will continue to operate under its own brand and with Dutch management, but ultimate ownership will sit with a U.S. parent subject to American law.
On 27 March 2026, Junior Minister for the Interior and Kingdom Relations Eric van der Burg informed Parliament that the DigiD contract with Solvinity would be extended by two years, despite the sovereignty concerns raised by the Kyndryl acquisition. In his justification, he stressed that terminating the contract would pose a serious risk to the continuity and security of Logius’ services, because no alternative architecture was ready to absorb the workload at short notice
The state could not exit a contract it considered a sovereignty risk because no architectural alternative was ready to receive the workload. This is a Level 4 sovereignty failure, a posture that depends on a provider never being acquired is not a strategy; it is a single point of failure.
What digital sovereignty actually is
Digital sovereignty is the ability of an organization to maintain total agency over its databases, object storage, and compute infrastructure. It is not a binary choice between open and closed source; it is the measure of your ability to control where data lives, how it is processed, and whether your business can survive the loss or "blackout" of any specific provider.
It sits at the intersection of:
Technological Independence: The ability to move workloads without a 12-month refactoring project. By prioritizing Open Standards, you ensure that even a proprietary "black box" remains an interchangeable component rather than a permanent anchor.
Operational Autonomy: The ability to maintain system uptime and "keep the lights on" without requiring active support or permission from a provider in a conflicting jurisdiction.
Regulatory Compliance & National Security: Ensuring that the legal "gravity" of your data is governed by your laws, not those of a foreign authority. This is the core requirement underpinning frameworks like the EU Data Act and GDPR.
The "Black Box" Nuance: Ownership vs. Transparency There is a common misconception that digital sovereignty requires 100% Open Source software. It doesn't.
You can be digitally sovereign while using proprietary, "black-box" systems (like a self-hosted hardware router or a licensed on-premise database) provided two conditions are met:
Possession: You own or host the instance. The "off switch" is in your building, not a remote API.
Interchangeability: The system follows open standards. If the vendor becomes a liability, the "black box" can be swapped out for an alternative without collapsing the entire architecture.
True sovereignty isn't about seeing every line of code—it's about ensuring no single vendor holds the "Kill Switch" for your business.
Sovereignty is a spectrum, not a switch
I advise teams to view sovereignty as a layered set of properties.
Level 1 — Data Residency: Where is the disk?
Is the storage volume physically located within a specific boundary? Every major provider offers this, but it protects you the least. Residency tells you where the bytes sit; it tells you nothing about who can legally compel the entity holding them.
Level 2 — Data Sovereignty: Whose laws govern the disk?
Residency is physical; sovereignty is legal. Many nations (including the U.S., China, and the UK) enforce trans-national rules based on corporate control, not server location. If a provider has a "virtual presence" in these jurisdictions, they can be compelled to hand over data held anywhere. This creates a Conflict of Laws: while your local laws (de jure) prohibit data transfer, the provider’s home-country laws (de facto) demand it.
Level 3 — Operational Sovereignty: Who can touch the disk?
When a P1 ticket is escalated at 03:00, which human sees your data? Real operational sovereignty requires:
- In-jurisdiction support: Engineers working from within your legal boundary.
- Customer-managed break-glass: Approval procedures requiring your signing key for elevated access.
- Cryptographic incapability: Keys held in HSMs you control, where the provider cannot decrypt data even under legal compulsion.
Level 4 — Digital Sovereignty: Can I rebuild this tomorrow?
This is exit readiness. It is measured in the days required to rehydrate the system elsewhere. If a provider becomes an unacceptable risk, Level 4 is your ability to migrate before the risk manifests.
Why this matters now
1. Regulatory pressure
GDPR fines reached €7.1 billion by January 2026. The EU Data Act (Chapter VII) now requires technical measures to block unlawful third-country government access to non-personal data.
2. Reducing dependency
Vendor lock-in is a compounded risk consisting of:
- Egress fees: Financial barriers to data portability.
- Proprietary APIs: Managed services (like DynamoDB or BigQuery) that require total code rewrites to migrate.
- Operational Coupling: Vendor-specific IAM and observability stacks that limit team mobility.
Expert Guidance: The EU Data Act’s mandated elimination of egress fees by January 2027 is a landmark shift, but it only addresses the financial barrier to sovereignty. It effectively removes the "ransom" required to move your data. It does nothing, however, to address the technical barrier.
If your data is "free" to leave but remains trapped in a proprietary schema or a vendor-locked managed service, you are a prisoner who can afford the bus ticket but cannot find the exit. You cannot buy your way out of technical lock-in; you have to architect your way out.
GitOps: A Deterministic Recovery Model
If you take one thing from this post, take this: GitOps (using Argo CD or Flux) is a deterministic recovery model for sovereignty.
In a GitOps model, your infrastructure state (manifests, Helm charts, network policies) lives in Git. The cluster is a derivative of the repo. Combine this with a control-plane abstraction like Crossplane, and your underlying infrastructure becomes a portable function of your code.
In a crisis migration, your workflow becomes:
- Provision a new cluster with a different provider.
- Point your Argo CD instance to the new target.
- Execute data synchronization (addressing the Data Gravity challenge).
- Cut over DNS.
"Data Gravity" Warning: YAML is light, but state is heavy. Moving the configuration takes minutes; moving 100TB of data takes weeks. Level 4 sovereignty is an illusion if you haven't solved for Data Gravity. In the simplest terms, this means having a secondary location (a Multi-cloud or Hybrid strategy) with a live, synchronized copy of your data ready to "spin up" at a moment's notice.
Beyond Rhetoric: The European Reference Architectures
In Europe, digital sovereignty has graduated from a strategic talking point into actual, deployable reference architectures. If you are building for the EU market, or looking for a blueprint for your own region, two initiatives define the current landscape:
1. Gaia-X: The Governance Layer
Gaia-X is not a cloud you "buy"; it is a framework of trust. It defines the "Rules of the Road" for data spaces—covering identity, transparency, and interoperability.
- The Architect’s Value: It makes Level 2 (Data) and Level 3 (Operational) sovereignty verifiable.
- Real-world Traction: Massive sectoral projects like Catena-X (Automotive) and the Mobility Data Space are already building on Gaia-X conformance to ensure data stays within governed boundaries.
2. Sovereign Cloud Stack (SCS): The Technical Blueprint
If Gaia-X is the "law," the Sovereign Cloud Stack is the "code." It is a German-led, open-source stack that bundles OpenStack, Kubernetes, and Ceph into a certifiable platform.
- The SRE’s Value: It is the industry’s serious answer to the "Toxic Provider" scenario. SCS allows any provider—like IONOS or Open Telekom Cloud—to offer a stack that is technically independent of U.S. hyperscaler control.
The Emerging Ecosystem (2025–2026)
Around these two pillars, the transition from "hyperscale-only" to "intentional cloud" is accelerating:
- OpenDesk: Austria's Federal Ministry migrated 1,200 employees to a Nextcloud-based sovereign stack, proving exit-readiness is possible.
- NUBO (France): A dedicated private cloud for the Ministry of Economy built on OpenStack for high-sensitivity workloads.
- The EDIC for Digital Commons: A four-nation coalition (DE, FR, IT, NL) established in July 2025 to scale these sovereign efforts across the continent.
- The "Partnership" Model: Solutions like Bleu (Microsoft/Orange) and S3NS (Google/Thales) demonstrate that even hyperscalers are now building architectures that keep operational control in local hands.
The CNCF Sovereignty Stack
- Kubernetes: Portable runtime.
- Argo CD / Flux: State reconciliation.
- Cilium: EBPF-native networking and zero-trust segmentation.
- External Secrets Operator + HashiCorp Vault: Keys that live with you, not the provider.
- Crossplane: Declarative cloud resource management.
Questions for your next Architecture Review
- Jurisdictional Mapping: Who is the ultimate parent company of our provider, and what is their exposure to extraterritorial warrants?
- P1 Path: During an emergency, what is the geographic and legal location of the engineer who accesses our unencrypted data plane?
- Encryption Logic: Is the provider cryptographically capable of decrypting our data?
- Rehydration Time: If we had to move to a different provider, is our "Time to Uptime" measured in days or quarters?
Sovereignty is engineering, not procurement
Sovereignty is not a logo on a slide or a checkbox in a vendor questionnaire. It is a property of your architecture. It is built through your encryption strategy, your GitOps discipline, and your choice of open standards.
The organizations that will navigate the next decade of regulatory shifts aren't just choosing the right vendors; they are building architectures that allow them to change their minds.