(Originally posted in LinkedIn on September 10th, 2025)

Or perhaps let’s continue and update the discussion we started during our last executive dinner from a couple of months ago! As I mentioned then, Cloud Sovereignty is not a switch to flip; it is a continuum of jurisdictional, operational, technical, and supply‑chain controls that can be tuned per workload and per risk scenario. Framing it as a spectrum can liberate decision‑makers from absolutist thinking and anchor choices in incremental, auditable controls rather than slogans.

Why trust matters

Contracts and DPAs are necessary, but they are not physical barriers. Technical and operational controls, on the other hand, materially constrain access paths when legal regimes collide across borders. EU guidance after Schrems II is blunt: if foreign surveillance is a realistic risk, supplementary measures must be technical (e.g., strong encryption with independent key control), with contracts serving only as complements.

A ladder to climb (carefully)

What follows is a “ladder” of sovereignty levels—each step accumulates the prior one, and each implies cost, complexity, and trade‑offs that should be justified by risk and strategy.

Not sovereign

At this base level, data may be regionally hosted, but there are no jurisdictional or operational constraints beyond standard compliance and provider controls; it suits low‑risk, high‑agility workloads. It prioritizes speed and breadth of services, accepting extra-geography exposure as residual risk to be managed by ordinary controls.

Example configuration

• Regional hosting with baseline encryption at rest/in transit using provider defaults, documented as accepted residual risk for low‑impact workloads.
• Standard IAM with least privilege, logging, and alerting, but no constraints on non‑local support or access paths beyond policy.
• Routine compliance mappings without jurisdictional add‑ons; reliance on provider attestations and internal monitoring.

Data sovereign

Here, data residency and processing locality are enforced, and supplementary technical measures address cross‑geography exposure risks. This level often aligns with evolving certification schemes (e.g., EUCS) while taking into account their ongoing political delays and interpretive variability.

Example configuration

• Enforce strict residency for storage and processing; encrypt data with tenant‑controlled keys stored in a separate trust domain (e.g., on‑prem HSM or independent key service).
• Classify datasets by transfer risk; block or tokenize cross‑geography flows, and document transfer impact assessments for exceptions.
• Adopt data minimization and pseudonymization to reduce identifiability if data exits jurisdiction in exceptional circumstances.

Local services sovereign (operational)

Operations, support, administration, and break‑glass are limited to personnel and infrastructure within the jurisdiction, shrinking extraterritorial leverage and insider risk via controls, process, and oversight. This step complements data controls by addressing who can touch the systems and how, not just where data sits.

Example configuration

• “Local‑only” administration with just‑in‑time access, time‑bounded privileges, and approval workflows constrained to in‑jurisdiction personnel.
• Split‑knowledge break‑glass procedures with quorum approvals and immutable audit trails retained locally for forensic assurance.
• Segregated change control, support pathways, and incident response that exclude non‑local routes and require local authority sign‑off.

Software/technical sovereign

Control shifts from place and people to technology choices: open formats, portability, confidential computing, and hard key custody reduce dependence on any single vendor or legal regime. The aim is to minimize switching costs and enforce technical barriers that make unauthorized access implausible, even if law permits it.

Example configuration

• Encrypt data end‑to‑end with tenant‑owned keys outside provider control; adopt application‑layer encryption and envelope keys with independent rotation.
• Use open standards and portable deployment patterns (e.g., near-vanilla Kubernetes, container images, and open data formats) to keep credible exit paths.
• Apply confidential computing or trusted execution to protect data in use, complementing at‑rest and in‑transit protections.

Hardware/supply‑chain sovereign

At the apex, the organization (or state) controls facilities, hardware, supply chains, networks, and even energy, accepting the cost of autonomy as the price of ultimate assurance. This is more a policy “north star” than a near‑term operating mode for most enterprises; it is pursued where state‑level threats or strategic industrial policy demand it.

Example configuration

• Domestic data centers with dedicated physical perimeters, independently procured hardware, and in‑country maintenance and logistics.
• Owned HSMs, private backbone or leased dark fiber, and national peering policies under local corporate control.
• Local power strategies with redundancy and fuel contracts; documented vendor‑of‑last‑resort plans for critical components.

Risk, acceptance, and the always relevant Mr Pareto

Sovereignty is a risk decision first: We identify, analyze, evaluate, treat, and accept residual risk using established frameworks (NIST SP 800‑30; ISO/IEC 27005) so that each rung on the ladder is justified in business terms. Quantitative methods like FAIR help compare expected loss against the cost and complexity of sovereignty controls, keeping choices economically sound.

A pragmatic view applies the Pareto (80/20) principle: we start with the vital few controls that remove most exposure—data residency with independent keys, local‑only operations, and tight identity boundaries—before chasing diminishing returns at higher tiers. We must document what is accepted and why, and move up the ladder only when loss reduction clearly exceeds the marginal cost.

At the end we should have reached an equilibrium of a sovereignty level that mitigates the non-accepted risk, and the allocated budget. Risk is our driver and budget is our restraint.

So, cost shapes sovereignty

Independent analyses in 2025 show meaningful price premiums and operational overhead for sovereign and ultra‑isolated environments, validating the idea that one can be “as sovereign as one can afford”. Beyond list prices, localization and isolation reduce service breadth and increase integration work, so the budget should track the risk curve, not the rhetoric.

Contracts are not barriers

EU guidance is explicit: contractual clauses and policies alone cannot neutralize extraterritorial surveillance; only robust technical measures materially change the access calculus. Therefore, trust must be operationalized—shift reliance from promises to cryptography, process segregation, and local control—while acknowledging contracts still play an important accountability role.

The U.S. legal backdrop (briefly)

As Dave Michels wrote in his very informative article, we should differentiate between the CLOUD Act (law‑enforcement access) and FISA §702 (intelligence collection); both shape residual risk when using providers subject to U.S. jurisdiction, including in European regions. European policymakers’ ongoing concerns and debates underscore why technical and operational measures, not just DPAs, are necessary for high‑sensitivity workloads.

Is “100%” real?

Full control over software, hardware, supply chains, networks, and power is a valid ideal, but for most organizations it is a quite distant horizon that risks crowding out innovation if pursued indiscriminately. We have to treat it as a strategic direction on a state level, and not a default requirement.

There is only one entity that can realistically reach near 100% of cloud sovereignty in the world right now. They would have to build everything on their own and also source the actual materials to do so from within their geographical border, even if their technology lags a little behind. Any ideas who might that be?

Closing suggestions

• Name the ladder: Publish a simple, shared vocabulary—data, operational, software, and supply‑chain sovereignty—and map typical controls to each step for clarity and accountability.
• Lead with the vital few: Prioritize tenant‑held keys, strong residency, and local‑only operations before pursuing higher‑cost autonomy steps.
• Quantify and accept: Use NIST/ISO methods and FAIR to decide when to stop climbing; document residual risk and revisit as laws, threats, and budgets evolve.

In the end, sovereignty is not a destination but a discipline: a commitment to replace blind trust with proportionate control, advancing one step at a time as risks justify and budgets allow.