Digital sovereignty / substitutability

Digital sovereignty is the ability to change

Digital sovereignty is often described through location. Where is the data? Where is the provider based? Which jurisdiction applies?

Those questions matter, but they do not tell an organisation how much control it has.

A service can be hosted in the preferred location and still depend on one provider for identity, operations, proprietary interfaces, specialist skills and the contractual right to keep using it. The more useful test is substitutability: could you change a critical dependency if you had to?

That does not mean every service must be easy to replace or that every organisation should build everything itself. It means knowing which dependencies matter, what would happen if one became unavailable or unsuitable, and whether there is a credible route to change.

Sovereignty is a level of control

Full technological independence is rarely a practical objective. Modern services depend on connected supply chains of cloud platforms, software, networks, identity systems, hardware and expertise.

The decision is therefore not simply sovereign or not sovereign. Different workloads need different levels of control.

A low-impact internal service may need an understood supplier, an ordinary recovery plan and regular review. A critical service may need stronger contractual protection, portable data, an alternative identity route and an exit plan that has actually been tested. A small number of highly sensitive capabilities may justify much deeper operational and technical independence.

The level should follow the consequence. What matters is the organisation's ability to absorb a change, not the label attached to the platform.

Map the dependency, not only the data

Data is one part of the system. A meaningful review looks across the full dependency chain:

Data: Can it be retrieved in a usable form, within the time the business needs?
Identity: Who controls access, administration and recovery if the normal route is disrupted?
Applications and interfaces: Which proprietary services, formats or APIs would need to change?
Operations: Does the organisation have the skills, documentation and access needed to run or move the service?
Infrastructure: Which compute, network, hardware or regional dependencies have no realistic substitute?
Commercial and legal terms: What rights, notice periods, costs and restrictions shape the available choices?

This changes the conversation. A residency statement may answer one question. It does not prove that a service is controllable, portable or resilient.

An exit plan is not evidence until it has been tested

Many organisations have an exit clause in a contract and a diagram showing an alternative architecture. That is useful preparation, but it is not the same as knowing the switch can be made.

A credible plan needs practical evidence. Can the data be exported and restored? Can identity and access be re-established? Do teams know the sequence of work? Are the dependencies documented? How long would the transition take, and what would the organisation lose while it happened?

Testing does not always require a full migration. A restore exercise, a partial workload move, a supplier-failure scenario or a rehearsed runbook can expose assumptions before a real event does.

Substitutability is therefore an operating capability. It has to be maintained as the service, supplier and organisation change.

Control has a cost, and so does dependency

Increasing control is not free. Portability can constrain design choices. Maintaining an alternative route creates work. Additional providers, skills, testing and contractual safeguards all carry cost.

But dependency also has a price. It can appear in a difficult renewal, an expensive late migration, a slow response to a regulatory change or a business opportunity that cannot be pursued because the current service lacks the required controls.

This is where FinOps and sovereignty meet. The decision should compare the cost of greater control with the exposure created by not having it. The right answer may be to retain the dependency, reduce it or replace it. Retaining it can be a deliberate decision when the value is worth the risk and the organisation understands the consequences.

Make sovereignty part of normal decisions

Digital sovereignty should not live as a separate programme that reviews everything after it has been built. It belongs in the decisions organisations already make about sourcing, architecture, investment and operations.

For each important dependency:

Understand the business service and the consequence of disruption.
Identify the parts that would be difficult to replace.
Decide how much control the service actually needs.
Choose proportionate safeguards and a credible exit route.
Test the assumptions and revisit them as the system changes.

The goal is not independence at any cost. It is managed interdependence: using the capability and innovation that suppliers provide while retaining enough control to make a different choice when the business needs one.

Digital sovereignty becomes practical when an organisation can answer three questions clearly: what do we depend on, what happens if it changes, and what can we do next?