Data sovereignty usually enters the room as a slogan. It leaves as a line item, and somewhere between the two the actual question goes missing. The question is not whether a nation should control its data in the abstract. It is what happens, concretely, on the day the system stops.
We have watched that day arrive more than once. A revenue platform goes down. The people responsible for it are in another timezone, working for a company that has a support tier, a ticket queue and a contractual response window measured in business days. The port does not have business days. Trucks are queuing now.
The three costs nobody prices
When a procurement compares a foreign hosted platform against local infrastructure, the comparison is almost always made on licence cost and nothing else. Three costs sit outside that column and routinely dwarf it.
- Latency of authority. Not network latency — decision latency. How long between identifying a problem and reaching a person empowered to fix it. Offshore, this is measured in days.
- The cost of not being able to change it. A configured platform can be configured. It cannot be extended to fit a rule that changed last month, which is how organisations end up running a parallel paper process beside the system they bought.
- Exit cost. Every year on a platform you do not control increases the price of leaving it. This compounds silently and is never on the original evaluation sheet.
What sovereignty actually requires
It does not require that everything be built from scratch, and it does not require refusing foreign technology. We use open source written all over the world, and so does everyone. What it requires is narrower and more achievable: that the people who operate the system can inspect it, change it, move it, and be held responsible for it.
In practice that means four things. The source is in the client's possession, not merely licensed to them. The deployment is reproducible from that source by someone other than us. The data can be exported in a documented format without our cooperation. And there is a runbook written for the person who will be on call a year from now, who has never met us.
If your team cannot operate the system without us, we have not finished the job. That is not generosity. It is the definition of a delivered project.
The uncomfortable part
This is a worse business model in the short term. A vendor who makes themselves structurally necessary earns more from the same contract than one who makes themselves optional. We have lost work to firms promising a managed platform with a lower headline figure and a permanent dependency underneath it.
But the institutions we work with are not buying software for a budget cycle. They are buying infrastructure that has to outlive the officials who signed for it, the vendor who built it, and quite possibly the technology it was written in. Judged on that horizon, dependency is the expensive option. It just presents its invoice later.