Being sovereign means being able to choose

Digital sovereignty is often associated with where data is located, control of infrastructures, the nationality of suppliers, or an organization’s ability to operate its own technologies. These dimensions matter, particularly where sensitive information, critical infrastructures, or regulatory obligations are at stake. They are not, however, enough to define sovereignty.

An organization can host its data in its own country, meet its regulatory obligations, and use perfectly secure technologies while having become deeply dependent on a handful of suppliers, platforms, or specialized skills. Legally, it remains free to change. Operationally, that freedom may have become extremely costly, complex, or practically impossible to exercise.

Digital sovereignty can therefore be approached from a much more concrete principle: being sovereign means being able to choose. To choose a technology, a supplier, or an architecture. To be able to negotiate. To be able to refuse a change that has become incompatible with the organization’s needs. To be able to move your data, replace a component, or change technological direction when circumstances require it.

The fundamental question is then no longer solely who owns the infrastructure or which country it sits in. It is about determining whether the organization retains enough control over its environment to keep making its own decisions.

On paper, a company generally remains free to change suppliers. It can replace a piece of software, migrate to another platform, modify its infrastructure, or adopt a new architecture. The operational reality, however, becomes far more complex over time. Data accumulates in certain formats, applications are integrated with one another, automations are developed, and internal processes are built around a platform’s features. Employees acquire specialized skills, contracts are renewed, and new components gradually reinforce the existing ecosystem.

Each of these decisions may be perfectly justified. It is their accumulation that can gradually turn a useful technology into a structural dependency. When leadership eventually wants to change direction, it discovers that the cost of exit far exceeds that of the new software being considered. Data has to be converted, integrations rebuilt, processes changed, employees trained, security mechanisms reviewed, and sometimes two environments maintained throughout a long transition.

The organization retains its theoretical freedom. It simply has to pay more and more to be able to exercise it.

This dependency rarely takes hold as the result of a conscious decision. A first application meets a need effectively. A second integrates naturally with the first. An additional service simplifies operations. Employees become proficient in the environment, and new projects logically favor the technologies already mastered. After a few years, staying becomes far simpler than changing.

This standardization brings real benefits. It can reduce complexity, facilitate integration, concentrate skills, and improve operational efficiency. The risk appears when that efficiency gradually turns into lock-in and the organization continues to favor an environment mainly because it has always used it.

An interesting organizational phenomenon can then appear. The more a company invests in an ecosystem, the more it naturally develops the skills and arguments needed to understand its strengths and manage its weaknesses. Known problems become familiar, teams know how to work around them, and procedures are established. An alternative technology immediately introduces more uncertainty: its weaknesses are less well known, its risks have to be assessed, new skills have to be developed, and some habits have to change.

The situation can become paradoxical: the organization knows the problems of its current environment perfectly well, yet those problems sometimes seem less threatening than the hypothetical problems of a solution it knows less well. With all the caution the metaphor demands, one could speak of a kind of “digital Stockholm syndrome”: the dependency becomes so familiar that it sometimes ends up being defended as if any alternative necessarily represented a greater risk.

The phenomenon is of course both technological and organizational. It results from investments already made, accumulated skills, habits, perceived risk, and the anticipated cost of change. Recognizing it does not mean calling into question the value of the technologies in use or the expertise of the teams. It rather makes it possible to distinguish the actual quality of a solution from the difficulty that replacing it would represent.

Take the example of an organization that has spent several years developing an environment largely built on Microsoft technologies. Its specialists are trained and certified, its applications are integrated into that environment, and its identity mechanisms, its workstations, and several processes depend on it. This situation may be entirely appropriate and continue to offer the best combination of capabilities, security, cost, and efficiency.

Suppose, however, that leadership wants to evaluate certain open source solutions in order to gain more flexibility, customize certain applications, or diversify its dependencies. The strategic question is not to determine in the abstract whether Microsoft is preferable to open source, nor to assume that open source would be inherently more sovereign. Both approaches can be excellent or inadequate depending on the needs.

The revealing question is rather this: does the organization still have the ability to seriously evaluate both options? If an alternative can practically no longer be considered because all the skills, integrations, knowledge, and processes are concentrated around a single ecosystem, part of the freedom of choice has already disappeared.

Skills themselves can contribute to this dependency. When an organization invests for several years in one particular technology, it naturally develops extremely effective specialists. That expertise is an important asset. It also influences how new possibilities are assessed. Every new technology necessarily involves a learning curve, and that difference in familiarity can easily be confused with a difference in maturity or risk.

Governance must therefore allow experts to fully express the technical risks they identify while distinguishing those risks from the normal cost of learning a new environment. This ability becomes particularly important with artificial intelligence, open source technologies, cloud, new cybersecurity architectures, and emerging technologies.

This line of thinking leads to a dimension too rarely built into technology decisions: the cost of exit should be part of the cost of acquisition. Organizations generally assess with care the licenses, implementation, integration, training, maintenance, and infrastructure needed to adopt a solution. They assess far less systematically the conditions needed to leave it.

Yet several questions could be asked from the outset. How will we get our data back? In what formats? Which applications will depend on this platform? Are the interfaces sufficiently documented? Which standards are used? How many people will have the knowledge needed to administer the environment? What would happen if the commercial terms changed substantially? How long would it take to migrate?

A technology can be economically very advantageous for ten years and become extraordinarily costly at the moment the organization wants to replace it. Sovereignty also consists in knowing that cost well enough before you need to.

This obviously does not mean that an organization should seek to eliminate all of its dependencies. A modern company necessarily depends on telecommunications providers, software, hardware, cloud services, cybersecurity, financial systems, and a multitude of partners. Digital sovereignty consists rather in knowing those dependencies, understanding their consequences, and controlling them well enough to preserve options.

Some dependencies are perfectly acceptable. Some can be replaced quickly, while others would take several years. Some concern secondary functions, whereas others could affect continuity of operations. Maturity consists in knowing these differences and consciously deciding which ones can be accepted.

Open source illustrates this nuance well. Access to the code, the ability to modify a solution, the use of open standards, and the existence of several suppliers can increase technological freedom. This does not, however, automatically create sovereignty. A company can become extremely dependent on a complex open source platform that it does not have the skills to maintain. It can depend on one particular integrator or accumulate so many customizations that updates become difficult.

The licensing model changes; the need for governance remains. Sovereignty always depends on the ability to understand, maintain, evolve, and eventually replace the environment.

The cloud raises exactly the same question. The major platforms offer considerable capabilities and provide rapid access to infrastructures, data services, cybersecurity mechanisms, and advanced artificial intelligence capabilities. Increasingly deep integration can, however, gradually raise the cost of a future migration.

Making extensive use of a cloud provider can perfectly well be a sovereign decision. The difference lies in how consciously that decision is made. Does the organization understand its dependencies? Does it know which data and which processes are tied to the platform? Does it know the consequences of changing providers? Does it have continuity mechanisms and realistic options if its needs or market conditions change?

Artificial intelligence makes this reflection even more important. Organizations are beginning to connect models to their documents, their databases, their CRMs, and their operational processes. Agents may gradually take on increasingly significant work sequences. The more deeply these capabilities become integrated into operations, the more the ability to change model, platform, or provider must be considered from the design stage.

Sovereignty in the age of AI will depend in particular on how organizations structure their knowledge. If organizational knowledge remains governed independently of the model that exploits it, if agent identities are controlled, if interfaces are documented, and if processes are sufficiently modular, the organization retains more freedom to evolve its environment. An architecture built entirely around one vendor’s particularities can, on the contrary, quickly turn a successful adoption into a dependency that is hard to reverse.

Interoperability thus becomes an instrument of sovereignty. Documented interfaces, accessible data formats, open standards where appropriate, modular architectures, a sufficiently clear separation between data and applications, and precise knowledge of dependencies do not guarantee that a migration will be simple. They do, however, help prevent it from becoming practically impossible.

This freedom also has economic value. An organization that can no longer reasonably change suppliers has fewer levers when prices rise, contractual terms change, a feature disappears, or the supplier’s strategy shifts. An acquisition or the discontinuation of a product can also quickly transform a commercial relationship.

A credible ability to choose another solution therefore directly influences your negotiating position. Even when a company stays with the same supplier for twenty years, the simple fact of being able to change has strategic value.

This view ultimately makes it possible to assess digital sovereignty with a very concrete question: if we had to change tomorrow, could we actually do it? That does not necessarily mean immediately, free of charge, or without difficulty. A major transformation can legitimately take time and require considerable investment. What matters is determining whether a realistic path exists.

This analysis does not lead to systematically abandoning proprietary technologies, repatriating all infrastructures, or replacing the major suppliers. It rather makes it possible to distinguish chosen dependencies from those that took hold gradually without any explicit decision. It is precisely that knowledge that allows an organization to determine where it wants to invest, where it accepts being dependent, and where it must preserve greater reversibility.

Digital sovereignty is not merely a matter of owning your servers, hosting your data locally, or selecting technologies developed in your own country. It represents above all a capacity for decision and for evolution.

An organization can use proprietary technologies, cloud platforms, SaaS solutions, open source, artificial intelligence, and international suppliers while retaining strong control of its environment. That control rests on knowledge of architectures, data governance, interoperability, identity management, an understanding of supplier dependencies, the maintenance of essential skills, and the existence of realistic migration paths.

This view connects directly to Hypersecurity. An organization’s resilience depends as much on its ability to protect its technologies as on its ability to keep evolving when a technology, a supplier, a risk, or a requirement changes. Sovereignty and reversibility then become properties of the architecture itself.

At Quantum Beyond, our experts work alongside IT, cybersecurity, governance, and executive teams to bring this cross-cutting perspective. Mapping dependencies, understanding the consequences of technology choices, structuring knowledge, assessing migration possibilities, and designing architectures capable of evolving all help strengthen existing capabilities while preserving more options for the future.

Digital sovereignty therefore does not ask an organization to become independent of everything. In a deeply interconnected technological world, dependencies are inevitable and can create enormous value. True control consists in knowing which ones were chosen, what they entail, and how they might evolve.

Being sovereign means knowing what you depend on, understanding what that dependency entails, and retaining enough options to still be able to choose your own direction.