Digital sovereignty is not a new concern. What has changed is the scale and complexity of the dependencies organisations now need to understand.
Over the past several years, data sovereignty has moved steadily up the agenda as organisations have considered where their data resides, who can access it and which laws and jurisdictions apply. Those questions remain important. But the digital ecosystems supporting critical services have also become significantly more interconnected, spanning cloud platforms, software providers, specialist suppliers, operational services and global technology supply chains.
Against this backdrop, shifting geopolitical relationships, evolving regulation and greater scrutiny of technology supply chains are adding another dimension. They are not necessarily reasons to retreat from global technology ecosystems, but they do make it increasingly important for organisations to understand where their critical dependencies sit and how much control they retain if circumstances change.
This is where the sovereignty conversation needs to broaden.
An organisation can meet its data residency and regulatory requirements and still have limited practical control over a critical digital service:
The strategic question, therefore, is not simply where does our data reside?
It is: where are we dependent, how material are those dependencies, and what credible options would we have if circumstances changed?
At UBDS Digital, we assess that question across eight dimensions of dependency: Technology, Data, Operations, Security, People, Commercial, Contracts, and Jurisdiction. Together, they provide a broader view of digital sovereignty, helping organisations understand where they retain strategic choice, where that choice is constrained and where greater optionality may be required.
For the majority of workloads and use-cases, complete technological independence is neither realistic nor necessarily desirable.
Modern organisations depend on technology providers because those providers offer capabilities, expertise, scale and innovation that would be difficult or inefficient to reproduce internally. The strategic issue is not dependency itself, but whether the organisation understands that dependency, the significance of the risk it creates and the choices available if circumstances change.
Recent UK parliamentary research reflects this distinction. The Parliamentary Office of Science and Technology frames digital sovereignty around the agency and capacity to shape, use and maintain the digital systems on which organisations and countries depend, rather than viewing sovereignty as isolationism or complete technological self-sufficiency.
This emphasis on choice is also reflected in the House of Commons Library's Digital Sovereignty briefing, which examines digital sovereignty in the context of the UK's reliance on foreign technology and its ability to make informed choices about its digital future. At an organisational level, the principle is similar: external dependencies are not inherently problematic, but they need to be understood well enough that they do not unintentionally limit future choices.
For executives, this changes the conversation. Instead of pursuing independence at any cost, organisations can identify material dependencies, understand how they could affect critical services and decide deliberately which risks to accept, reduce or mitigate. That is ultimately a question of strategic choice.
Technology portability is an important part of digital sovereignty, but it is only one part.
An application might be capable of running in another cloud environment; that does not necessarily mean the organisation could move the service successfully. The application may rely on proprietary services or APIs. Its data might be difficult to extract and rehydrate. Operational processes may depend on provider-specific monitoring and backup tools. Security could rely on an existing identity platform or key management service. Critical knowledge might sit with a supplier rather than the organisation.
Even if those challenges can be overcome technically, licensing arrangements, committed expenditure, switching costs or contractual terms could make exercising the alternative difficult.
This is the distinction between cloud portability and service portability. Service portability considers the dependencies surrounding the whole service across the 8 dimensions, not simply whether its underlying workload can theoretically run somewhere else.
The existence of an alternative is not the same as the ability to exercise it.
Platforms, APIs, runtimes and proprietary services.
Technology choices inevitably create dependencies. Organisations select platforms and managed services because they can accelerate delivery, improve performance or reduce operational burden. Those benefits should not automatically be sacrificed in pursuit of portability. The strategic question is whether the resulting dependency is understood. An application may theoretically be movable while remaining tightly coupled to proprietary APIs, runtimes or managed services. Replacing those capabilities could require substantial redesign, investment or time. For critical services, leaders need to understand what those choices mean for future options.
Executive question: Do you understand the technologies that comprise a service, and how difficult would it be to operate this service without the technologies it currently depends on?
Portability, gravity, lineage and rehydration.
Knowing where data resides is important, but location alone does not establish control. Leaders also need to know whether critical data can be extracted, transferred, reconstructed and made usable in another environment. Large or highly interconnected datasets can develop significant gravity, while schemas, metadata, applications and processing services may determine whether the data remains useful. An organisation could possess its data without having a practical way to restore the service that depends on it. The converse is also true – a service may be truly portable, but if you lose access to the only copy of the data, the service may be unrecoverable. It’s also worth remembering that in modern software architectures, the Infrastructure as Code (IaC) that defines environments should also be treated as critical data.
Executive question: Could we recover and use our data independently of the current service?
Monitoring, backup, tooling and support.
Services rely on the operational ecosystem that keeps them observable, recoverable and supported. Monitoring, automation, backup processes and service-management tooling can create operational dependencies that become apparent only when an organisation changes its operating model or provider. A service that can be moved technically but cannot be operated effectively in its new environment is not meaningfully portable.
Executive question: Could we continue operating the service effectively if the current operational ecosystem changed?
Identity, access, key custody and assurance.
Security capabilities can themselves become critical dependencies. Identity services, access controls, cryptographic keys and assurance mechanisms often span applications and platforms. If those capabilities are tightly coupled to a particular environment or provider, they can constrain an organisation's ability to move or recover a service. This does not mean every security capability must be owned internally. It means leaders should understand where control resides and what would happen if the relationship underpinning it changed.
Executive question: Which security capabilities do we genuinely control, and which depend on a third party?
Skills, knowledge and supplier expertise.
Some of the most consequential dependencies do not appear on architecture diagrams. A critical service may rely on specialist knowledge held by a small internal team, an individual contractor or a supplier. Documentation may exist, but that does not necessarily mean another team could operate, recover or migrate the service effectively. If an organisation cannot exercise an alternative without the people associated with its current operating model, its choices remain constrained.
Executive question: Do we retain, or can we quickly obtain, enough knowledge and capability to exercise our technology choices?
Licensing, committed spend and switching costs.
Alternative service or technology models can be technically viable but economically unrealistic. Long-term commitments, licensing models, data transfer costs and the investment required to recreate capabilities elsewhere can all influence whether an organisation has a credible choice. A service may be capable of moving, but the cost of doing so could make the option impractical.
Executive question: Is exercising our alternative technically possible but commercially prohibitive?
Exit rights, termination and transition support.
Simply having the contractual right to leave a provider is not the same as having an executable exit. Effective transition may require access to information, data, documentation, specialist resources and supplier cooperation. If these requirements have not been considered in advance, an organisation may discover that its contractual freedom provides less practical choice than expected, particularly for critical services with demanding continuity requirements.
Executive question: Do our contracts give us a practical route out, or merely the legal right to leave?
Ownership, law, supply chain and policy exposure.
Digital services operate within legal, commercial and geopolitical environments that organisations cannot fully control. Provider ownership, applicable laws, technology supply chains and changes in national or international policy can influence service availability and operation. Jurisdictional dependency should not be reduced to declaring one country or provider inherently safe or risky. The more useful exercise is understanding where exposure exists, how concentrated it is and what options would remain if circumstances changed.
Executive question: Which legal, ownership and supply-chain conditions sit outside our control, and what would happen if they changed?
Assessing the eight dimensions individually is useful, but the greatest strategic risks can emerge when dependencies reinforce one another.
A technology dependency might require specialist supplier expertise, creating a People dependency. The same technology could carry significant licensing commitments, creating a Commercial dependency, while transition support may be governed by contractual arrangements. Individually, each dependency might appear manageable. Together, they could make exercising an alternative considerably more difficult.
The same can happen with data. Data gravity may make migration challenging, while operational tooling, security controls and jurisdictional considerations further restrict the available choices.
This is why digital sovereignty cannot be reduced to a single metric. Executives need to understand both the materiality of individual dependencies and their concentration across a critical service.
Identifying a dependency does not automatically mean removing it. Some dependencies will be entirely appropriate. A proprietary service may deliver substantial competitive value. A specialist supplier may provide expertise that would make little sense to maintain internally. A long-term commercial commitment might produce significant financial benefits.
The important step is making those decisions consciously. Once a material dependency is understood, an organisation can decide whether to accept it, reduce it, diversify it, mitigate it or create a credible exit option.
That last point is where service portability becomes particularly important. An architecture diagram, exit strategy or contractual clause can indicate that an alternative should exist. They do not demonstrate that the organisation could actually exercise it.
Where portability is strategically important, it should be demonstrated, not assumed.
That might mean proving that critical data can be recovered and rehydrated, validating that an alternative environment can operate the service, ensuring necessary skills exist or testing whether transition arrangements work within acceptable timescales. The objective is not mobility for its own sake. It is confidence that strategic choices remain available when they are needed.
For boards, the governance question is equally clear: which digital dependencies could materially restrict the organisation's resilience or strategic freedom? Technology leadership can then use the eight dimensions to demonstrate where credible alternatives exist and where further action is needed.
Every modern organisation operates with dependencies. Digital sovereignty does not require eliminating them.
What matters is understanding which dependencies are critical, knowing what they mean for the organisation and retaining sufficient control to make deliberate choices as circumstances change.
Assessing the 8 dimensions of Technology, Data, Operations, Security, People, Commercial, Contracts, and Jurisdiction provides a broader view of the dependencies surrounding a digital service. It can reveal where an organisation has genuine options, where those options are constrained, and where greater service portability may be required.
Digital sovereignty is not independence at any cost. It is the ability to choose.
Understanding dependency is the first step. The next is determining which dependencies create material risk and whether your organisation has credible options when circumstances change.
UBDS Digital Sovereignty & Service Portability helps organisations assess critical services across the eight dimensions of dependency, identify where control and choice are constrained, and determine where greater portability or other mitigations are required.
Explore Digital Sovereignty & Service Portability and speak to UBDS Digital about strengthening the resilience, control and strategic optionality of your critical digital services.