An organisation can own its applications and data while depending heavily on another company’s ability and willingness to operate the underlying platform. Authentication, databases, deployment tools, backups, and support may all rely on one provider.
That dependency becomes visible when the provider changes prices, retires a service, suffers an outage, or becomes subject to a legal restriction. The organisation still owns important assets, but its range of practical choices may be narrower than ownership suggests.
Digital sovereignty concerns meaningful control over data, technology, infrastructure, and the decisions made through them. At national level, it includes the capacity to pursue public objectives without unacceptable external dependence. At organisational level, it includes the ability to govern suppliers, maintain operations, and change direction.
These ambitions overlap, but they are not identical. A country’s industrial policy does not automatically provide an individual organisation with a workable migration plan.
Control Has Several Dimensions
A public agency might choose a domestic hosting region for a case-management system. That establishes something about where specified data is stored. It does not, by itself, establish who can administer the service, which legal obligations affect the provider, or whether the agency can operate without it.
| Dimension | Practical question |
|---|---|
| Data location | Where are primary records, backups, and relevant service data processed? |
| Legal authority | Which jurisdictions and contractual obligations affect the arrangement? |
| Operational control | Who can administer, suspend, restore, and change the service? |
| Technical independence | What can be replaced without redesigning the application? |
| Organisational capability | Who has the skills and resources to exercise those options? |
Data residency is therefore one part of a broader assessment. Encryption and customer-controlled keys can improve specific controls, but their effect depends on the architecture, including where decryption happens and who controls the running application.
The European Commission’s technology sovereignty agenda addresses a wider set of capabilities and dependencies. That broader framing is useful: control is a relationship between institutions, infrastructure, and operational capacity.
Dependencies Accumulate Through Useful Features
The agency’s first cloud deployment might use standard virtual machines and a database. Later, it adopts managed identity, a proprietary workflow service, event processing, monitoring, and an integrated AI capability.
Each choice can be reasonable. Managed services may improve delivery speed and reduce operational effort. Over time, however, those choices become connected to application behaviour, employee skills, contracts, and support procedures.
Convenient platform capabilities
|
v
Application and workflow integration
|
v
Accumulated operational dependence
|
v
Higher cost and time required to switch
|
v
Fewer practical alternatives during a disputeThis is one way technical dependency becomes bargaining power. A customer may be legally free to leave while facing a transition that takes longer than the decision window available.
Calling that arrangement lock-in describes the constraint. It does not establish that every integrated service was a poor choice. The question is whether the organisation understood the trade-off and retained sufficient options for the consequences involved.
Competition Policy and Sovereignty Address Related Problems
Competition policy can address market power and practices that restrict alternatives. Sovereignty asks additional questions about continuity, jurisdiction, public authority, and control of important capabilities.
The EU’s Digital Markets Act establishes obligations for designated gatekeepers in core platform services to support fairer and more contestable digital markets. It complements existing competition rules. It is not a general guarantee that every cloud application can move unchanged between providers.
The EU Data Act separately includes measures addressing switching between data-processing services and interoperability. These measures can improve the conditions under which customers exercise alternatives.
An engineering implication follows: stronger switching rights are valuable, but customers still need to understand their data, application dependencies, and operating requirements. Legal changes can reduce barriers while technical migration remains real work.
Equally, architecture alone cannot resolve market concentration or the conditions imposed by a dominant intermediary. Policy and engineering operate on different parts of the problem.
A Credible Exit Requires More Than an Export
For the agency, exporting case records would be necessary but insufficient. Another system would need to preserve relationships, permissions, attachments, retention rules, and the meaning of status transitions.
An exit assessment should identify what must move, what must be rebuilt, and how service will continue during transition. It should also distinguish planned migration from emergency continuity. A six-month migration option provides little protection against a disruption that must be managed today.
Useful evidence includes a sample export that can be interpreted elsewhere, documented dependencies, realistic transition estimates, and a tested route for recovering essential information. Procurement can require cooperation, but someone must own the technical and organisational work of making that cooperation useful.
Historical records need particular care. As reprocessing and recovery illustrate, a technically successful conversion should still preserve the information needed to explain earlier decisions.
Domestic Hosting and Open Source Still Require Governance
A domestic supplier may reduce some jurisdictional concerns while remaining dependent on foreign hardware, software, or subcontractors. Open-source software can improve inspectability and the ability to modify a system, but someone still needs to operate it, maintain dependencies, and respond to vulnerabilities.
Similarly, using multiple providers can reduce some concentration risks while increasing cost and complexity. Shared identity, network, or software dependencies may leave supposedly separate deployments exposed to the same failure.
The appropriate objective is proportionate control. A public information website and a critical administrative service do not necessarily require the same degree of independence. Identify the decisions the organisation must retain, then evaluate whether the proposed arrangement preserves them under realistic conditions.
Political Power Includes the Ability to Set the Terms
Digital platforms influence which services can reach users, which interfaces are available, and what conditions apply to participation. When a public institution or business relies on that access, a platform’s technical and commercial decisions can affect its ability to act.
Governments also exercise power through procurement, regulation, investment, and decisions about public infrastructure. Those interventions have trade-offs. Requirements intended to reduce dependence can affect cost, supplier choice, interoperability, and delivery capability.
A useful sovereignty assessment makes those trade-offs visible. It names the dependency, explains the consequence of losing control, and identifies the capability or alternative that would reduce exposure.
Digital sovereignty becomes operational when an organisation can exercise the choices it claims to retain. That requires legal rights, practical alternatives, sufficient expertise, and ongoing attention as the technology changes.
Key Takeaways
- Digital sovereignty includes legal, operational, technical, and organisational control.
- Data residency alone does not establish independence from a supplier.
- Competition and switching rules can improve alternatives without eliminating migration work.
- Credible control requires maintained capabilities and evidence that important options can be exercised.
