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 tolerable and where it is not.
4. Define policy, target operating posture & exit requirements by tier
Having classified assets into tiers, the next step is defining the policy set and operating posture. For each tier, this means specifying what is mandatory, what is preferred, what is accepted only by exception, and which trade-offs the business is willing to make across cost, speed, and innovation:
In this way, strategy translates into practical management choices. These may involve, for example, contract redesign, architectural decoupling, revised support models, or a deliberate decision to accept dependency where the business case for sovereignty is weak. Policies should be explicit enough to guide engineering and commercial decisions, with clear rules on provider patterns, portability, recovery expectations, and trigger conditions for change.
This becomes particularly relevant in AI-driven environments. For example, in the telecommunications sector, Singtel has built a sovereign AI capability that combines GPU infrastructure, cloud resources, and connectivity into an integrated stack. At the same time, it operates an orchestration layer that distributes workloads across multiple clouds and networks. This illustrates that sovereignty in practice is less about full-stack independence and more about controlling orchestration across a hybrid ecosystem.
5. Embed sovereignty into the IT operating model & governance
Finally, sovereignty policies and operating postures must be embedded into the IT operating model. This requires a clear mechanism for resolving trade-offs when speed, cost, innovation, and control pull in different directions. Decision rights should be explicit across the business, CIO, CISO, procurement, and architecture functions. Sovereignty should be managed as a capability: continuously monitored, periodically stress-tested, and adjusted when conditions change, including new regulations, sanction exposure, vendor terms, or geopolitical escalation.
In practice, this changes how IT is run. Sourcing strategy needs to assess where multi-vendor approaches justify the additional overhead; architecture standards need to incorporate modularity, redundancy, custody, and observability; and platform engineering priorities need to include guardrails that allow teams to move quickly without locking the organization into fragile dependencies. It also requires stronger commercial discipline, including executable exit clauses, audit rights, subcontractor transparency, and protection against price or licensing shocks where bargaining power permits.
A lightweight but disciplined governance rhythm is usually sufficient: the architecture function sets standards; the security function validates access and control requirements; the procurement function enforces commercial protections; platform engineering provides reusable guardrails; and the business functions themselves approve the trade-offs where speed, cost, and sovereignty compete with one another.
Sovereignty postures should be reviewed and refreshed whenever there is a significant change, such as a major contract renewal, a large transformation decision, new AI platform choices, or a trigger event such as a regulatory shift or geopolitical escalation.
A small set of actionable metrics should also be established, such as concentration by provider, the share of Tier 1 workloads with tested exit paths, unresolved exceptions, and contracts lacking audit, transparency, or portability protections. This helps turn sovereignty from an abstract principle into a recurring management agenda.
Case study — Operationalizing digital sovereignty in critical infrastructure
Faced with increased Internet of Things/operational technology convergence, geopolitical uncertainty, and growing dependency on a small number of global technology platforms, a national critical infrastructure provider recognized the need to rethink how it managed its digital dependencies and build a strategic capability that extended beyond piecemeal sourcing decisions. Supported by ADL, the client developed a new risk-based framework and embedded it into its existing governance and risk management processes. The framework included:
Achieving transparency on digital dependencies was the essential first step. This ensured that infrastructure ownership was not automatically treated as the only solution for digital independence, with improvements in exit capability and supplier control often proving preferable. A key design choice was to treat digital sovereignty as an operating model capability rather than a standalone strategy. Using this approach, the client was able to balance resilience, cost efficiency, and innovation effectively.
DIGITAL SOVEREIGNTY REQUIRES A STRATEGIC, NOT PIECEMEAL, APPROACH
The challenge for executives is not whether digital sovereignty matters, but how to pursue it selectively without undermining competitiveness. Ultimately, investing in digital sovereignty is about preserving strategic freedom and reducing the operational and commercial risks associated with forced dependence on external digital ecosystems. Companies should:
By Volker Pfirsching, Michael Majster, Joeri Samyn, Sabine Kaiser
cloud technology
Addleshaw Goddard entra en el mercado neerlandés mediante la integrac...
