Digital sovereignty is one of those areas where tech people and policy people risk getting out of step with each other. Not because they want different things, but because they鈥檙e approaching the problem through different lenses.
A big part of the problem here is we鈥檙e often dealing with different levels of abstraction. So, it鈥檚 one thing to talk about digital sovereignty as a policy aim. It鈥檚 quite another to figure out what this means for which CRM you should buy.
To make things even more complicated, sovereign or not sovereign isn鈥檛 the yes/no question we might think it is. So, in practical terms, it can be difficult to know how to translate this into a concrete implementation strategy for a specific use case.
Which is what we鈥檙e talking about today.
Digital sovereignty鈥檚 implementation problem
Digital sovereignty is a growing concern, and not just for the public sector. According to , 98% of enterprises want to prioritize digital sovereignty, but only around half are actually taking action.
That鈥檚 a big implementation gap. So what gives?
One huge challenge here is that digital sovereignty is very, very multidimensional. It鈥檚 not one thing that we can buy or assign to a specific team. Sovereignty is not just about where our data is stored. It鈥檚 where the system runs, who can access it, what laws apply, what can we inspect, how does data move, and what migration to a replacement might look like.
So legal, security, architecture, procurement, risk, and technology teams can all be involved - but each may be looking at a different part of the problem.
The other big challenge is the level of analysis we want to look at this from. Yes, we might want to achieve digital sovereignty at an organizational level or across our operations in their entirety. But, for immediate implementation, it normally makes more sense to think smaller. This means prioritizing certain workflows and use cases where control and resilience are bigger priorities, rather than treating every workflow exactly the same way.
We鈥檒l come back to this idea in a minute.
You鈥檙e not going to start making your own hardware
First, it鈥檚 important to think about what we mean when we say that digital sovereignty isn鈥檛 really a clean binary thing. Digital sovereignty is basically an organization鈥檚 ability to retain control and independence over the systems, data, and infrastructure it uses - without being unacceptably constrained by external actors.
鈥�Unacceptably鈥� does a lot of heavy lifting here. Unless you start printing your own chips, you鈥檙e never going to remove external actors from the picture entirely. Well, maybe you could do that, but it鈥檚 unlikely you鈥檇 ever get anything else done.
So, there鈥檚 a question of what鈥檚 an acceptable level of sovereignty, but we also have to balance this with the practical realities.
If we accept that some dependence on external actors is probably inevitable, we get into asking who these actors are. For instance, are they based in a jurisdiction that aligns with our own regulatory needs? Is it an open-source project or a commercial vendor?
That leads us to鈥�
When is 鈥榮overeign鈥� 鈥榮overeign enough鈥�?
We hinted at the idea that what鈥檚 an acceptable level of control and independence for one workflow might not be for another. For example, our requirements for a sensitive workflow like managing IT incidents will probably be quite different to our needs when managing employee holidays.
Most of the time, what鈥檚 an acceptable level of sovereignty really depends on our risk tolerance for a specific workflow. A workflow that handles sensitive data or that could lead to serious consequences if disrupted needs a higher level of control than a low-stakes internal process.
If we don鈥檛 recognize this, it鈥檚 easy to start thinking in all-or-nothing terms about digital sovereignty, and that鈥檚 where the implementation gap starts to come into play.
So, we need to decide what level of control the workflow actually warrants. That might mean stronger requirements around hosting location, provider access, auditability, portability, contractual protections, or the ability to keep operating if the relationship changes.
How can we measure sovereignty?
To start putting this into practice, we need to understand how we can actually measure digital sovereignty. Otherwise, there鈥檚 really no way to know if we鈥檝e achieved anything.
Helpfully, there are some established practices out there. For example, the provides a model for measuring sovereignty across multiple dimensions, including legal, operational, technical, security, and supply-chain considerations. We can actually use this to give ourselves a definitive score.
But, as we鈥檝e said, the more important question is often around acceptable sovereignty for specific workflows. So, we might equally want to use frameworks like this as a blueprint for defining our own priorities, rather than adopting them wholesale.
The first step is understanding which dimensions of digital sovereignty matter most for our use case. These might include jurisdiction, provider access, hosting location, auditability, portability, operational continuity, interoperability, supply-chain exposure, or contractual exit rights.
From there, we need to turn each of these into something we can actually measure. So, 鈥渋nspectable鈥� should mean architecture, data flows, logs, or relevant code can be reviewed. 鈥淧ortable鈥� should mean data can be exported in a documented, usable format, etc.
Only then are we in a position to translate digital sovereignty into implementation requirements that we can actually use.
Four practical tests: run, connect, inspect, exit
Still, no one likes to hear 鈥榳ell, you know, it depends鈥�鈥�
So, even though the specific measurement criteria that we use and how we weight each of these can vary, it鈥檚 still important to understand the practical ways that we can judge whether a specific solution gives us the level of control that we need.
One useful way to think about this, without getting overly prescriptive, is in terms of four practical tests:
- Can we run it where we need to? Whether this means within a particular jurisdiction or on our own hardware, the point is that specific solutions must satisfy our requirements, whether legal or in terms of control over the environment.
- Can we connect to the systems we rely on? Sovereign systems have to work with our existing identity, monitoring, data, and other tooling without making the whole workflow dependent on keeping those same tools in place forever.
- Can we inspect how it works? Open-source software can help here, but the wider requirement is evidence. We need enough visibility into architecture, data flows, access controls, and dependencies to verify how the solution behaves, not just how it is described by the vendor.
- Can we exit if we need to? Leaving a provider is not just a contractual question. We need to know that we can take our data, preserve the records we need, understand what happens to backups and logs, and keep the workflow operating while we move to another vendor or environment.
Even though our granular requirements within each of these might vary, the categories give us a repeatable way to move from abstract sovereignty goals to real-world implementation decisions.
Establishing defensible control
Ultimately, digital sovereignty isn鈥檛 about complete independence. It鈥檚 about establishing a level of control over our workflows that we can defend.
This means being able to explain why a particular level of sovereignty is appropriate, in terms of the risks we鈥檙e addressing and the evidence that supports our decisions.
Ultimately, understanding the compromises we may have to make here - and why we鈥檙e making them - is what鈥檚 going to close the gap between 鈥�sovereignty is a priority for us鈥� and 鈥榮overeignty is something we鈥檙e actively taking steps towards鈥�.
The goal is to move digital sovereignty from an abstract aspiration to specific requirements, informed by actual use cases.
Which workflows matter most? What level of control do they need? What would show that a solution meets that? And where are we prepared to accept trade-offs?
You鈥檙e never going to eliminate every dependency. But you can make those dependencies deliberate, defensible, and appropriate for the workflows they support.