Sovereignty in technology is one of the most used and least defined words in a boardroom. It fills speeches, tenders, and vendor decks. It rarely reaches a contract. The honest version is narrow and testable. Sovereignty is a set of four written answers about any supplier your business cannot live without. When the answers are missing, sovereignty does not exist. What exists is a comfortable relationship that lasts exactly as long as it suits the other side.
Sovereignty is a test, not a posture
Most conversations about sovereignty stay at altitude. National clouds, strategic autonomy, data borders. Useful debates, and far too abstract for a leader who has to decide something on Tuesday.
Bring it down to the ground. Sovereignty, at the level where a company actually lives or dies, means one thing. Can you keep operating, and keep control of what matters, when a supplier changes its mind. That is it. Everything else is commentary.
A posture is a statement you make about yourself. A test is a question reality asks you. The difference shows up the day a supplier raises its price, changes its terms, gets acquired, or simply has a bad week. A posture collapses that day. A test you passed in advance holds.
So the useful question is never whether you feel sovereign. It is whether you would pass the test if someone ran it on you tomorrow.
Four questions decide who is in control
I use the same four questions on every critical supplier. They are deliberately concrete, because sovereignty dies in abstraction and survives in specifics.
Who decides when an update ships to your systems. You, on your schedule, or the vendor, unilaterally, on a random morning, with no warning.
Who holds the encryption key to your data. You, or the vendor, which means the vendor can technically read everything you store.
Can you cut the service yourself, cleanly, without depending on the vendor’s goodwill or notice period. A switch you cannot reach is not a switch you own.
What happens to your access the day the vendor is acquired. By a competitor, by a fund, by an actor under another jurisdiction with other rules.
Four questions. If the answers are not written into the relationship, you are not sovereign over that supplier. You are trusting. Trust is a fine fuel for a partnership. It is not a guarantee, and it should never be mistaken for one.
A rule written into the architecture does not get argued in meetings
Answering the four questions is step one. Making the answers stick is the harder part, and this is where most sovereignty efforts quietly fail. They live in a policy. Policies decay.
Leo Casagrande framed a useful idea under the name framework by design. A rule that matters belongs in the infrastructure, not in a charter. It gets encoded to the point where doing the wrong thing is no longer an option. The constraint lives in the wall, not in the wiki.
Apply that to connectivity and sovereignty together. You can write we value high availability and reversibility in a policy. No one reads it on the day it matters. Or you build it in. Two carriers instead of one. Multi-factor authentication imposed on everyone by the system itself. A recovery plan that has actually been tested, not filed. Data you have already proven you can extract, in a usable format, within a day.
Casagrande has a line I keep. The framework has won when you no longer need to enforce it. A sovereign architecture is exactly that. You pay the cost once, at design time, and after that the constraint works for you while you sleep. A policy asks for discipline every single day. A wall asks for nothing.
The missing mandate is the right to say no
There is a second discipline, and it is human, not technical. In conversations with other practitioners, the same pattern keeps surfacing. Organizations hand out plenty of mandates to execute. Almost none to contradict.
Think about your own company. Who has the written authority to block a signature that creates lock-in with no priced exit. Not to advise against it. Not to add a cautious note to the file. To stop it. In most organizations that authority sits nowhere. An architect can warn. A security lead can flag. The decision then travels upward, toward people with neither the time nor the detail to see the trap close.
This matters because reversibility looks like a technical question and behaves like a political one. The ability to leave a vendor, to recover your data, to switch off a service, is negotiated before you sign, or it is not negotiated at all. After signing, you no longer negotiate. You ask. And asking is a much weaker position than deciding.
Giving someone a real mandate to contradict, in the cold, before the ink dries, is the cheapest insurance a company can buy against the dependencies it signs without seeing.
What sovereignty looks like on an ordinary Tuesday
Sovereignty is not dramatic. It does not look like independence or a fortress. On a normal Tuesday, in a sovereign company, a vendor pushes an update and it lands when the company allowed it to. The data sits somewhere the company can point to and retrieve. A contract comes up for renewal and leaving is a real option, which is precisely why the price stays honest. Someone in the building has the mandate to look at all of this and the right to say no.
None of that requires heroics. It requires four written answers, a few constraints built into the architecture instead of a charter, and one named person allowed to contradict. Sovereignty stops being a slogan the moment those three things exist, and stays a slogan every day they do not.
FAQ
What four questions determine whether a company is actually sovereign over a critical supplier?
Who decides when an update ships to your systems — you or the vendor unilaterally. Who holds the encryption key to your data. Can you cut the service yourself, cleanly, without depending on the vendor’s goodwill. And what happens to your access the day the vendor is acquired by a competitor, a fund, or an actor under another jurisdiction. If these answers aren’t written into the relationship, you’re trusting the vendor, not sovereign over them.
Why does writing a sovereignty policy usually fail to protect a company?
Because policies decay and nobody rereads them on the day they matter. The fix is to encode the constraint into the architecture instead — two carriers instead of one, MFA enforced by the system itself, a recovery plan that’s actually been tested, data already proven extractable in a usable format. A rule built into the infrastructure works while you sleep; a rule written in a charter asks for discipline every single day and eventually loses.
