Digital sovereignty has become one of the most frequently used phrases in technology strategy, despite being one of the least examined concepts. It is increasingly attached to products, as though it were a feature that could be switched on, or a property of the brand printed on the contract: choose this platform and you are sovereign; choose that one and you are captured. The reality is almost the opposite. Digital sovereignty is not a quality of the software you buy; it is a quality of the organisation that runs it.
This distinction matters more now than ever before, because the strategic stakes are real and the marketing around them is loud. Two recent and substantial pieces of work help cut through the noise: the Danish Agency for Digital Government's December 2025 report on open source in the public sector, and an international survey of sixteen digitally mature countries it commissioned the year before. Read together, they point to the same uncomfortable but useful conclusion. Digital sovereignty is a capability, and capabilities have to be built.
Sovereignty Is Not a Product You Can Buy
It is tempting to believe that a particular kind of platform settles the question. It does not. You can be genuinely independent on a proprietary stack if you are well governed, and completely trapped on open source if you are not. The brand on the box decides very little. The organisation around it decides almost everything.
The major providers themselves demonstrate the point. Over the past year Microsoft has completed its EU Data Boundary, and introduced sovereign options such as customer-held encryption keys, Europe-based access controls and on-premises deployment of core workloads, all aimed squarely at sovereignty concerns. These are serious investments, and they make sovereignty achievable on a hyperscale commercial cloud in a way that was not possible a few years ago. At the same time, residual questions remain, such as the reach of foreign legislation over data physically stored in Europe, which no purchasing decision fully removes on its own. The lesson is not that one provider is safe and another is not. The lesson is that whatever you choose, the responsibility to understand what you hold, where it sits, and how you would abandon it if needed, does not transfer to the vendor. It stays with you.
So, the real question is never "which platform makes us digitally sovereign." It is "do we understand our configuration, own our data, know our contracts, and have a funded way to change course." Those are organisational properties, not product ones.
Control and Responsibility Are the Same Decision
The Danish 2025 report is blunt about the trade nobody likes to name. When you take more control of your technology, you also take on more responsibility: licence terms, security updates, support, maintenance, and simply knowing what you are running. Control is not a prize you collect. It is a workload you accept. The report is careful never to claim that more openness is always better; it says the opposite. Make choices based on the value they bring, and be honest about whether you can carry out what you have chosen.
Denmark built a dedicated Open Source Office for its health sector. Although, it was technically well regarded, it withered anyway. Not because of the quality of the code, but because of a lack of organisational and financial backing. Technical excellence does not provide the capability to sustain operational backing. Funding, ownership and leadership do. Especially leadership. The same pattern appears in reverse wherever sovereignty succeeds. It is sustained by an organisation with leadership that decided to allocate resources to it, not by a licence that happened to permit it.
This is why the smallest organisations struggle the most, and why the answer is rarely a heroic in-house rebuild. Acquiring a capability is demanding precisely because it is real work, and pretending a platform removes that work is how dependence quietly accumulates.
The Preconditions Are Where Sovereignty Is Actually Built
If digital sovereignty is a capability, the practical question becomes what that capability is made of. The Danish report, drawing on the experience of public authorities at home and abroad, sets out a clear and, helpfully, vendor-neutral list of preconditions. These preconditions apply just as much to proprietary software as to open source.
The first precondition is organisation and leadership. Someone has to back the decision, articulate why it is being made, and invest in the competence to carry it, whether that competence is built internally or bought in. The second is a deliberate decision about support and maintenance. It is needed whether the software is open source or not. All software needs support and maintenance, and leaving it unowned would be a mistake. The third is the ability to assess security and maturity, to judge whether there is an active community or a competent supplier behind a component, rather than assuming a license fee guarantees it. The fourth is genuine command of licences, contracts and data, knowing what terms bind you, where your information lives, and what your agreements actually say. The fifth is open standards and integration building, so that systems can talk to one another and, crucially, so that you could change a supplier later without dismantling everything. The last is honest lifetime economics, comparing the full cost of a solution over its life rather than its sticker price, because the value of being able to move never appears on an invoice.
None of these are technical tricks. Every one of them is a discipline. Together, they are what digital sovereignty actually consists of, and the encouraging part is that they can be deliberately developed.
No Organisation Stands Alone
Organisations do not have to acquire the capability to posses digital sovereignty by themselves, and the most mature countries have understood this. The recurring pattern in the international survey is the rise of shared stewardship: neutral organisations that posses this capability on behalf of many. In Denmark, the OS2 community lets municipalities pool funding and competence around shared solutions, on the principle that those who rely on something help sustain it and keep the ability to change suppliers. Estonia and Finland went as far as founding a joint institution, with staff and a budget, simply to steward software they share. Italy has built a state office to guide and support adoption of open source, Germany has established both a public body to develop shared solutions and an agency to fund the maintenance of critical open source, and the European Union is assembling common building blocks several countries can draw on.
What matters is not which model wins, but that every one of them treats capability as something to be funded, staffed and shared, rather than assumed. Digital sovereignty, at scale, is a collective discipline as much as an individual one.
Digital Sovereignty Is a Leadership Posture
Leadership, specifically the CIO and/or CTO, are the ones who need to make decisions on digital sovereignty. It is important they do so, during the procurement process itself. Data location, exit-readiness, open standards and clarity over contracts should not be afterthoughts raised once a platform is already chosen. They belong to the requirements, as standard, applied to every vendor regardless of who they are. Treated that way, digital sovereignty becomes the decision to take responsibility for your own infrastructure, to know what you run and why, and to keep your options open on purpose.
The most durable examples are governed, not improvised. Aarhus, for instance, did not become more digitally independent through a single product switch. It set a direction over many years, from a requirement to consider alternatives, to an action plan, to a digital strategy, to budgeted money set aside to widen its choice of suppliers. The throughline is not a technology. It is sustained, value-driven governance, and a refusal to let someone else set the cadence by default. The longstanding principle behind it is worth remembering: choose the best and most economical option regardless of software type. These options need to be chosen by an organisation that understands what it is choosing.
That capability is what we build at Strator. The platform is yours either way, commercial or open, cloud or on-premises. The real question is whether you can steer it, and whether you could leave it if you ever had to. Digital sovereignty is not simply a phrase on the contract; it is the knowledge that the organisation knows its situation and has the ability to migrate if it chose so.
