Digital Sovereignty in Practice: What It Really Means for a Public Organisation

Digital sovereignty is often discussed as if it were a place: keep the data in the country, host everything on local servers, and the question is settled. I think that framing is too narrow. For a public organisation, sovereignty is less about where technology sits and more about who holds the decisions: the ability to choose a provider, to change it, and to leave it without putting essential services at risk.

In practice, this turns a political slogan into a handful of concrete questions. Under which legal jurisdiction does our data fall? Who operates the service day to day, and who can access it? Could we move to another solution within a reasonable time if we had to? And do we keep enough internal skills to understand what we have bought? When the honest answer to several of these is "we are not sure", the organisation has a dependency it has not yet named.

The mistake I see most often is treating every system the same way. A public service runs hundreds of capabilities, and they do not all deserve the same level of control. A sensible approach starts by sorting them: whatever is critical to the mission or involves sensitive personal data deserves strong guarantees and a credible exit plan, while commodity services can accept more convenience. Sovereignty then becomes a proportionate choice rather than an all-or-nothing ideology.

That is why sovereignty is, for me, an architecture and governance discipline before it is a hosting decision. Open standards, clear contractual exit terms, documented dependencies and people who can challenge a supplier are less visible than a data centre, but they are what keeps choices open. Next week, I will look at the practical side: how to design cloud choices for reversibility.