A companion to the digital sovereignty series. It doesn’t replace your business-impact analysis, threat modeling or vendor-risk process — it puts them on one causal chain, one unacceptable consequence at a time.
The method in one line: don’t decide how sovereign something should be. Decide what must not happen, and work backward until the remaining dependencies can no longer make it happen — or until you’ve decided you can live with them.
Run the ten columns across one unacceptable consequence, then across the next. The point isn’t to fill every cell perfectly. It’s to notice where a “sensitive, so bring it in-house” reflex doesn’t survive the questions — and where “just use the hyperscaler” is the right, defensible answer.
How to use it
Work left to right. Use one row for each unacceptable consequence, meaning that a workload may need more than one row.
- Workload (for context) — the thing you’re placing a bet on: an application, a dataset, a model, a service.
- Unacceptable consequence (the main column) — not “what do we want,” but what must not happen to us. If nothing here is genuinely unacceptable, stop: this workload doesn’t need a sovereignty decision, and that is a valid, money-saving answer.
- What can cause it — the events or conditions that would produce that consequence.
- Who or what holds the lever — the party (or non-party: a standard, an ecosystem, a jurisdiction, your own past self) that can pull the cause into being. Name it.
- Dependency depth — how deep? Follow the dependency down. Your redundant system may still rest on one identity service, one DNS provider, one recovery control plane. Stop when the consequence of the remaining dependency no longer matters — not before, not forever.
- Current / proposed mitigation — what you already have in place against this or what you will do to mitigate this.
- New dependency created — every mitigation adds one. Name what you just took on: e.g., an operational burden, a new supplier, a skill you must now keep.
- What remains? — after the mitigation and its new dependency, what’s left that could still produce the unacceptable outcome?
- Acceptable? — yes / no. Can you accept it or can what remains still produce a consequence you cannot accept? If it can, loop back and mitigate again, and check its new dependency. If it can’t, you are sovereign enough for this workload. Stop.
- Reassessment trigger + review cadence — the specific change in conditions that would make you run this row again (a contract change, a new regulation, a provider’s roadmap shift, a growth threshold). Important: Don’t wait for a trigger, review periodically too (at least once per year).
The worksheet
| Workload | Unacceptable consequence | What can cause it | Who/what holds the lever | Dependency depth | Current / proposed mitigation | New dependency created | What remains? | Acceptable? | Reassessment trigger + review cadence |
|---|---|---|---|---|---|---|---|---|---|
To understand how the sovereignty loop works, read this: https://mguenther.nl/series/sovereignty-loop/
Three honest cautions
The worksheet starts one step too late. It assumes you already know which consequences are unacceptable, and who in the organization gets to say so. When a CISO, a CFO and a business owner each name a different unacceptable consequence — foreign access, lost capability, doubled cost — and all three are real, the worksheet won’t rank them for you. That’s a governance conversation to have before the first row, not a cell to fill in.
You can only reason backward from consequences you’ve imagined. The depth column and honest dependency-tracing help, but they don’t abolish the unknown. Where your causal model is incomplete, resilience and adaptability are the hedge: avoid making today’s assumptions so structural, so set in stone, that an unforeseen change in the future leaves you unable to respond.
The Flip Test isn’t a requirement to keep every option open. Ask whether today’s architecture leaves you room to respond if the assumptions behind today’s answer move. You don’t know which assumption will change — that’s the point.
Five worked rows (examples)
| Workload | Unacceptable consequence | What can cause it | Who/what holds the lever | Dependency depth | Current / proposed mitigation | New dependency created | What remains? | Acceptable? | Reassessment trigger + review cadence |
|---|---|---|---|---|---|---|---|---|---|
| Customer records database | Regulator-triggered loss of the right to operate in the market | A foreign authority obtains access to protected customer data in a way that violates applicable requirements | Foreign authority exercising compulsory powers over the provider | Provider → parent entity → legal regime governing it | Encrypt data with keys held outside the provider’s control; keep workload and data in the required EU region | Key custody and recovery become our responsibility; loss or compromise of keys becomes our risk | The provider may still be compelled to disclose ciphertext and associated metadata, but cannot disclose usable record contents if it has no access to the keys or plaintext | Yes – provided the remaining disclosure cannot produce the unacceptable regulatory consequence | Provider gains access to keys/plaintext; key-custody model changes; new subprocessor/jurisdiction; relevant lawful-access or regulatory ruling changes; periodic review at least annually |
| Factory production-control system | Production stops for more than 8 hours because we cannot restore or operate the system ourselves | Vendor service becomes unavailable, support is withdrawn, or remote administration is inaccessible | Equipment/software vendor | Production system → proprietary management software → vendor support and licensing systems | Maintain local administrative access, offline recovery images and configuration backups; train internal staff to perform recovery without vendor assistance | We must keep recovery material current and retain people who know how to use it | Some rare hardware or firmware failures may still require vendor support, but routine operation and recovery no longer do | Yes – remaining vendor dependency cannot realistically cause an outage beyond the 8-hour limit we are unwilling to accept | Vendor changes licensing/support model; recovery test fails; key staff leave; major system upgrade; annual recovery exercise |
| Public marketing website | None identified beyond short-term inconvenience and lost traffic. Stop. | ||||||||
| Customer-support AI assistant | Inference cost rises enough that operating the service is no longer economically viable | Model provider raises prices substantially or retires the model and forces migration to a more expensive replacement | AI model/API provider | Application → AI gateway → provider API → model catalogue and pricing | Keep the application provider-neutral; qualify a second model/provider against the same quality and cost requirements | We must maintain the abstraction layer, evaluation suite and compatibility with the alternative model | A sudden price increase can still raise costs temporarily while we switch; the alternative may also be somewhat more expensive or perform differently | Yes – provided we can switch within an agreed period without exceeding the cost level we are unwilling to accept | Material price change; model deprecation; changed API/terms; alternative model fails evaluation; periodic portability test and annual review |
| Online transaction platform | Customers cannot complete transactions for more than 2 hours because connectivity to the platform is lost | Primary network provider suffers an outage, withdraws service, or loses the route connecting our sites to the platform | Network service provider | Application → private connection → carrier → local access network → shared ducts / exchange / upstream routes | Add a second carrier using a physically diverse path and test failover regularly | We must operate two connections, maintain routing/failover configuration and verify that advertised path diversity remains real | Both carriers may still share infrastructure deeper in the path, and failover may briefly interrupt service | Yes – provided no remaining shared dependency can realistically keep the service unavailable beyond 2 hours | Carrier topology changes; new common upstream dependency discovered; failover test fails; service terms change; annual review |
- Notice what the first row does: it turns “this data is sensitive, so we must own the infrastructure” into a specific, smaller decision – hold the keys – and it names the new dependency that choice created (key custody and recovery) rather than pretending the mitigation was free.
- And notice the third row: the honest answer is that there is nothing here you can’t accept, so you stop. A method that can conclude “do nothing” is doing its job.