A global company decides to become fully sovereign. Every system in its own data centers, in its own jurisdiction. Foreign providers out, cross-border transfers stopped, the estate air-gapped. Customer data untouchable, IP locked down.
Then it goes bankrupt. It was in the pizza delivery business, and the ordering platform was inside the air gap with everything else.
Of course nobody would do this. But notice what went wrong: not the ambition, not the execution. They applied it uniformly. The recipe and the order line got the same treatment, and only one of them needed it.
That much is now broadly accepted. The market has moved from selling sovereignty as a posture to selling it as a classification exercise, and that’s progress – nobody serious still argues every workload needs the same treatment.
The trouble is what comes next. Every framework that classifies workloads asks the same question, and it only ever points one way. They tell you how tightly to hold a workload. None of them tells you when to let go.
Start with what works
Start with what’s already there, because it’s good. Microsoft’s sovereignty guidance is the most developed example: classify your data – public, internal, confidential, secret – and map each class to a matching level of control. Residency and encryption in transit at the base, customer-managed keys above that, confidential computing at the top. It’s explicit that not every workload needs the same treatment, that low-risk data can be eligible for broader platform services, and that you should start at the baseline and move up only where the data warrants it.
That’s a well-built answer to a real question: how sensitive is this, and what protection does it need?
The question in front of you is a different one. Sensitivity tells you how tightly to hold something. It doesn’t tell you what taking that control does to you – whether it protects the business or slows it to a crawl, cuts it off from a service it was relying on, or costs more to run than the risk was ever worth.
And there’s a reason the frameworks stop where they do. It isn’t that the second question is unknown. It’s that it belongs to someone else. The people who decide how tightly to hold a workload sit in security and compliance. The people who know what an outage costs sit in operations. Neither has ever seen the other’s number.
Other disciplines settled this a long time ago by adding an axis. Procurement has used the Kraljic matrix since the early eighties: business impact on one axis, supply risk on the other, four quadrants and four different strategies – including one where the right answer is to keep it simple and spend your attention elsewhere. Maintenance engineering does something similar with criticality, service management with impact and urgency. The second axis is what lets the answer come back as not this one.
Sovereignty has the first axis. It needs the second.
Add the second dimension
The first dimension is the one the classification frameworks already measure, so keep it. How much do you need to own and control this – the data, the keys, the jurisdiction, who gets to touch it? Call it asset sovereignty – ownership, for short. A regulated customer database scores high. The company blog scores low.
The second dimension is the one that lives in another department: how much does this need to keep running when conditions turn? Not “is it important” – specifically, what happens if it stops, or becomes unreachable. Call it outcome sovereignty – continuity, for short. This is the half most sovereignty thinking leaves out, and the one I’ve argued matters most: earlier in this series I put it plainly – asset sovereignty is who owns, outcome sovereignty is who keeps running when conditions stop holding. It’s the reason the matrix needs a second axis at all. The pizza chain’s ordering platform scores high. Its recipe archive scores low; nobody notices if it’s offline for a day.
They’re not the same measure, and that’s the point. Knowing one doesn’t tell you the other – a workload can need heavy control and almost no continuity, like a sensitive archive nobody touches, or heavy continuity and almost no control, like a public service where the data is worthless to anyone else and all that matters is uptime. They do interact at the edges: a confidentiality breach can force you to pull a system offline, and locking something down too hard can be the very thing that takes it down. But you still can’t read one axis off the other – which is exactly why you place a workload on both. Collapse them into one dimension and you get the pizza chain: the recipe and the order line both scored “important,” so both got the same treatment.
Plot them against each other and you get four positions, each with a different right answer.
The four positions
High control, high continuity. The expensive corner: own it and keep it running through disruption. Regulated data in a service that can’t go dark. Few workloads genuinely belong here, and the ones that do should be there deliberately – it costs more than the other three combined.
High control, low continuity. Own it tightly and stop. A sensitive archive, a records store – anywhere the exposure is confidentiality, not downtime. The mistake is building expensive resilience for something that could be offline a week unnoticed.
Low control, high continuity. The one people get wrong most, and what the pizza chain fatally misread. You don’t need to own it, you need it to work – which usually means delegating it to someone who does continuity better than you do. Reaching for control here is how you end up less available than before.
Low control, low continuity. Neither. Buy the cheapest thing that works and spend your attention elsewhere. A single-axis framework has no way to express this quadrant, and it’s usually the largest by volume.
Three ways to get it wrong
The matrix earns its keep by what it catches. Three mistakes account for most of it.
You needed it to stay up, so you took it in-house. A customer-facing service was running fine on a hyperscaler. Someone asks whether it’s sovereign, the answer is uncomfortable, and it gets repatriated to your own two data centers. You now own it – and you’ve traded a provider running dozens of regions for a team of four running two. The pizza chain in miniature. This is the only mistake that actively backfires: you paid a premium to become less available.
You needed it kept quiet, so you built it a failover site. An HR archive, a legal hold, a set of unreleased product designs. The risk was always someone reading them, never anyone being unable to. It’s now replicated across two locations with tested recovery, and none of that spend touches the actual exposure. The pizza chain’s recipe, with a hot standby.
It needed nothing, and got the full treatment anyway. The marketing site, the internal wiki, the training videos – swept up because a policy said every system meets the same bar. Nobody ever asked what would happen if these leaked, because nothing would. The pizza chain’s menu, air-gapped.
The first is dangerous, the second is wasteful, the third is theater. Only one of them ever shows up in an incident report.
Where to start
Take your ten largest workloads and place them. Not the whole estate – ten is enough to be useful and few enough to finish in an afternoon.
Two questions each, nothing else. What would it cost us if someone else could reach this? If you’ve classified your data, you’ve largely answered that. And what would it cost us if this stopped? Your continuity people answered that years ago.
Both numbers exist. They’ve just never been on the same page – and the decision that needs both has been made without either.
Answer in consequence, not category. “Regulated” isn’t an answer. “We’d be fined and the story would run” is.
What you get is a picture rather than a policy. Most workloads will land in the bottom-left, which tells you the sovereignty budget has been spread across things that never needed it. A few will sit top-right and deserve everything you can give them – and now you can afford to, because you stopped paying for the rest. And one or two will be in the wrong quadrant, which is the reason to do this at all.
That’s the shift: from one setting applied to everything, to a decision made per workload – and a defensible answer when someone asks why this system got the full treatment and that one didn’t.
Originally published on LinkedIn