Digital sovereignty is often reduced to the location of data. Knowing which country hosts a server matters, but it is not enough. An organization may store its data in Europe while remaining entirely dependent on one provider, a proprietary format, a remote identity service or an infrastructure that it can no longer operate without outside support. Sovereignty is therefore not isolation. It is the practical ability to understand, decide, move and continue operating.
From source code to the dependency chain
In software, control begins with knowing what actually runs. Internally developed code is only one part of the system. Libraries, container images, SaaS services, extensions and build tools form a dependency chain that can be difficult to map. A forced update, a licensing change or a discontinued API can quickly become an operational risk.
Open-source software and open standards provide a decisive advantage because they make auditing, maintenance and migration more accessible. They do not automatically guarantee autonomy. A poorly documented open-source project, without available skills or a recovery procedure, can create a dependency as strong as a proprietary product. Sovereignty depends as much on people and organization as it does on licensing.
Infrastructure is also a strategic decision
The same reasoning applies to IT infrastructure. Public cloud provides remarkable deployment speed, elasticity and shared capacity. It becomes problematic when a company no longer knows how to rebuild its services elsewhere, retrieve its data in a usable format or estimate future costs. Conversely, local infrastructure is sovereign only when it is properly secured, monitored, backed up and maintained.
The objective is not to choose systematically between cloud and on-premises systems, but to assign each workload to the right environment. Collaborative messaging, an industrial system, a sensitive database and an AI model do not share the same constraints or criticality. A hybrid architecture can be sovereign when data flows are known, responsibilities are explicit and exit mechanisms are tested.
Measure sovereignty instead of proclaiming it
A credible strategy must be verifiable. The organization should know which data leaves its perimeter, which identities control access, which components cannot be replaced and how long it would take to restore a service. It should also be able to estimate migration costs, test backups and document the skills required for operations.
Useful indicators include the proportion of data that can be exported, recovery time, the number of critical dependencies without an alternative, the share of access controlled by an external identity provider and the time required to deploy a service on another infrastructure. These measurements make trade-offs more rational and allow progress to be tracked over time.
Sovereignty as an engineering discipline
This approach does not promise absolute independence, which would often be unrealistic. Its purpose is to avoid invisible and irreversible dependencies. A sovereign company is not one that builds everything itself. It is one that knows what it delegates, why it delegates it and how it could regain control.
Assess your digital dependenciesTom Cheniaux - rephrased using AI