Driven by geopolitics, regulation, and accelerating AI adoption, digital sovereignty has moved to the top of the executive agenda. However, improving digital independence and resilience without reducing competitiveness and efficiency is not easy. In this Viewpoint, we propose a practical, tiered approach that balances control, resilience, and competitiveness, embedding effective sovereignty management as an operational capability.
WHY DIGITAL SOVEREIGNTY NEEDS ADDRESSING NOW
Rising geopolitical tensions, tighter regulation, and rapid AI adoption are pushing digital sovereignty to the forefront of the corporate agenda (see the recent Arthur D. Little [ADL] PRISM article “Cloud Control: Rethinking Digital Dependence in the Age of AI”). As organizations become more dependent on external cloud platforms, AI models, digital infrastructure, and software ecosystems, the risk of lock-in to specific vendors, technologies, and jurisdictions increases. This challenge becomes more urgent as AI evolves from a productivity tool into a core operational layer that increasingly plans, coordinates, and optimizes enterprise workflows. Once agentic and embedded AI systems become deeply integrated into business processes, requirements such as portability, auditability, resilience, explainability, and exit capability become significantly harder and more expensive to retrofit.
At the same time, geopolitical fragmentation and regulation are accelerating sovereignty concerns. In Europe, proposed cybersecurity legislation could restrict “high-risk” suppliers from critical infrastructure sectors, potentially forcing operators to redesign systems and replace technologies across industries such as telecoms, cloud services, and energy. Similar pressures are emerging globally as governments place greater emphasis on national security, strategic autonomy, and data governance. Organizations, therefore, must define governance standards, guardrails, and exit options now, before AI industrialization embeds long-term dependencies into critical operations.
Digital sovereignty, however, goes far beyond cloud-location or sourcing decisions. It requires building long-term resilience and maintaining control over critical digital assets and operational processes in an environment where regulations, sanctions, supplier behavior, and geopolitical conditions are constantly shifting. Many organizations underestimate their “sovereignty debt” — hidden dependencies on vendors, jurisdictions, and subcontractors that are difficult to unwind.
These vulnerabilities often become visible only during crises, leading to downtime, rushed migrations, increased costs, operational disruption, and reduced strategic flexibility.
ASPECTS & TRADE-OFFS TO CONSIDER
Digital sovereignty extends far beyond cloud-region selection. Organizations are increasingly exposed to a broad and growing range of dependencies, including applications, data platforms, identity and security services, continuous integration and continuous delivery/deployment pipelines, API ecosystems, AI services, foundation models, and specialized infrastructure like GPUs. Each layer raises different sovereignty questions: where control resides, which jurisdictions apply, what cross-border data flows exist, and which third parties may gain access under what conditions. Three interdependent dimensions are particularly important: data sovereignty, system sovereignty, and decision sovereignty (see Figure 1).
Data sovereignty concerns where data resides, who owns it, and the legal regimes governing access. System sovereignty focuses on control over infrastructure, networks, portability, and reliance on third-party platforms. Decision sovereignty is the most strategic dimension: retaining the ability to make, adapt, and enforce key technology choices as geopolitical, regulatory, or commercial conditions change. Sovereignty is therefore not a binary state, but a set of deliberate control choices across the digital stack.
At the same time, sovereignty inevitably involves trade-offs. Alternatives to the dominant global technology providers are expanding, particularly in Europe, across cloud, productivity, and privacy-focused services. Choices are now becoming available from different regions across all layers of the technology stack (see Figure 2).
However, these ecosystems can still lag global hyperscalers in areas such as advanced AI tooling, scale, and operational maturity. A rigid “sovereign-first” approach can increase cost, slow innovation, and reduce competitiveness.
Many leading technology providers now offer “sovereign” services that partially address customer concerns, although limitations often remain. For example, under the 2018 US CLOUD (Clarifying Lawful Overseas Use of Data) Act, data access may still be possible under exceptional circumstances regardless of hosting location.
The key challenge for leaders is deciding where sovereignty is essential and where dependency is acceptable in exchange for capability, speed, and efficiency. Rebuilding credible alternatives takes years, and organizations that delay these decisions risk higher costs and disruption if forced to act later.
HOW TO MOVE FORWARD: A DECISION FRAMEWORK
To address the issues and trade-offs, organizations must manage digital sovereignty strategically. Many organizations fail because they lack a clear baseline view of their exposure and make decisions on a piecemeal basis across IT, procurement, security, and business. Adopting a clear decision framework can help executives make the right choices in the right sequence. The following five-step framework has proven effective in practice:
Let’s see how this works.
1. Establish a sovereignty baseline & build transparency on critical dependencies
The first step is to establish transparency across your enterprise’s most critical dependencies by building a fact base across business services, underlying data domains, and the enabling technology stack. In practice, start with the business services, whose disruption would matter most, rather than trying to map everything at once.
For each service, trace the dependency chain across the application stack, data stores, identity, connectivity, observability, DevOps toolchain, backup and recovery, and any embedded AI services or models. Four questions usually reveal the real exposure: who operates the service, who can access or administer it, what legal or jurisdictional constraints apply, and how quickly can it be restored or moved if conditions change.
Upon performing this end to end, hidden single points of dependency typically surface in places that are easy to miss in standard reviews, such as identity, workflow orchestration, managed data services, model hosting, or support arrangements. Regulatory exposures are also important to identify, such as the impending European regulations that could lead to bans on certain high-risk vendors.
The output from this step is typically a diagnostic heat map of the 10-20 most business-critical services, scoring dependency concentration, substitutability, jurisdictional exposure, control and access gaps, recovery constraints, and migration effort. The heat map helps identify exposure hotspots by highlighting where dependency is concentrated, poorly understood, or difficult to unwind and provides input for the prioritization decisions in the next step. Figure 3 shows an example of a typical heat map in which sovereignty was embedded within broader risk management.
2. Define sovereignty dimensions & tiering logic
The next step is to translate the exposure baseline into a business-led decision matrix. A matrix based on sovereignty criticality and implementation feasibility provides clear and practical prioritization logic (see Figure 4).
Sovereignty criticality captures the value-at-risk if a dependency is disrupted or control is constrained, including impacts on operations, revenue, compliance, resilience, and strategic freedom.
Implementation feasibility captures how realistically that exposure can be reduced while considering technical complexity, cost, time to implement, and ecosystem maturity. Based on these dimensions, four tiers can be readily identified, with typical asset types within each tier shown in Figure 4:
3. Classify assets into sovereignty tiers based on value-at-risk
In Step 3, starting with the heat map baseline, business services and data domains are classified into one of the four tiers. In doing so, it is important to maintain an end-to-end perspective on services and domains. This matters because the real “crown jewels” are often not the visible front-end systems but rather the underlying identity layer, orchestration logic, proprietary data, workflow orchestration, or model operations.
The approach should be business-led, not technology-led. The key question is whether the business impact of dependency justifies intervention now and whether that intervention is realistically achievable. In practice, this classification should be conducted as a short interactive exercise, not a lengthy architecture program. Test the first wave of critical capabilities against a small set of disruption scenarios (e.g., loss of provider access, sudden jurisdictional constraints, support withdrawal, or a material outage) and agree where the impact is tolerab
cloud technology axon
This new fund is, in addition to being the most ambitious biotech inve...
