Sovereignty is no longer just a privacy or data-residency question. It has become a question of strategic control, resilience, and competitiveness across the entire digital stack. The debate is not about decoupling. It is about understanding the levers that others hold over critical operations, and deciding deliberately which ones to accept, mitigate, or neutralize.

For CIOs and risk leaders, sovereignty decisions now shape uptime, legal exposure, cost trajectories, and time‑to‑market – not just compliance.

For years, sovereignty was reduced to a single question – where is the data stored or where does it move? But the question expanded: a workload can sit in Europe and still be exposed to foreign legal reach, opaque service dependencies, restricted portability, or technology lock-in that becomes irreversible once embedded. The real issue is not where data lives, but who controls the systems that process and govern it – and what happens when conditions change.

External dependencies are levers that could affect your business if they change. A lever may never move. But if it does, and you have not prepared for it, your operations, your costs, your legal position, or your access to customers can shift overnight. Levers are not inherently dangerous – they are the price of doing business in a connected economy. The risk is not their existence. The risk is not knowing which ones you depend on, and not having a plan for the day one of them shifts.

Architected correctly, sovereignty is not a constraint on business goals – it is what protects the freedom to pursue them. Enterprises move to cloud, adopt AI, connect globally and build on major platforms because those choices unlock real speed and capability. Sovereignty architecture is what keeps those gains from quietly turning into exposure and risk. A company that knows its levers and mitigates against them is more business resilient – able to commit to global platforms and partnerships while keeping its options open.

Two kinds of levers

The current sovereignty debate converges on a useful distinction between two kinds of levers.

Chokepoints are structural levers. They emerge from concentration and structural constraints in physical infrastructure. Cloud workloads consolidated with a handful of global providers. AI compute and foundation models concentrated among a small number of vendors, with tightly coupled tooling, data pipelines, and upgrade paths. DNS dependencies that directly affect online trade. Sub-sea cables that, when cut, force enterprises to reroute external traffic at significant cost and latency. Power grid disruptions affecting data center regions, with a direct effect on operational continuity. These levers exist whether or not anyone is exercising them – your vulnerability is if you depend on a single one.

Control points are deliberate levers – decisions someone else can make. The decision may be jurisdictional: a foreign government compelling a provider to hand over data under its own laws, an export license revoked, a sanctioned market cut off. Or it may be commercial: a vendor changing license terms, deprecating an API your operations depend on, retiring a product, withdrawing from a region, or restructuring support. The motivation varies and is rarely directed against you specifically, but the effect on the enterprise is similar. Someone else has shifted the conditions you operate under, and your business has to absorb it.

And the two interact. A chokepoint becomes a control point the moment someone gains the ability to act on it. Sovereignty work is about reducing exposure to both – and ensuring that when a lever moves, the business keeps running.

Similar patterns have long been identified in strategic supply chains and global economic networks, where concentration and discretionary authority allow dependencies to be turned into points of leverage – an insight that translates cleanly to digital infrastructure.

Not every mitigated dependency is, in practice, a usable lever. A lever only exists if it can be acted on when conditions change. Effective sovereignty architecture turns dependencies into controllable levers: actions the business can take within the time, cost, and legal constraints that apply when a lever actually moves.

AI sharpens these dynamics. Models, training data, inference pipelines, and specialized compute are often delivered as an integrated stack, turning what look like separate dependencies into a single lever held by the platform. When access to a model changes, export restrictions apply, or inference locations are constrained, the impact is immediate and hard to reverse. In this context, sovereignty is not about avoiding AI platforms, but about architecting AI so that data, models, and control do not collapse into an unmovable dependency.

The European regulatory answer

Europe is encoding this in law. Across GDPR, the Cybersecurity Act, the Data Governance Act, the EU AI Act, DMA, DSA, DORA, the EU Data Act, NIS2, and the Digital Omnibus, the regulatory direction is consistent: digital dependence is acceptable only when the enterprise retains practical control over it – the ability to leave, to inspect, to switch, to recover, and to hold someone accountable when something goes wrong.

It clearly shows that data locality is no longer the main aspect determining sovereignty. What matters more is governance and operational authority – the ability to manage the levers, not just locate the data.

But it is worth being precise about what regulation does and does not deliver. To borrow a familiar GRC formulation, compliance – for example with GDPR or the AI Act – is the floor of sovereignty: the bare minimum an enterprise must meet to operate legally. Genuine digital sovereignty – knowing your levers, mitigating them, and designing for adaptation – is the ceiling. An enterprise that has ticked every compliance box can still be one provider decision away from operational disruption. Regulation pulls the floor upward over time, but the ceiling only rises when the enterprise itself treats sovereignty as a posture, not a checkbox.

The EU is not only translating this into legal frameworks but also into practical tools to identify dependencies – the Cloud Sovereignty Framework with its SEAL assessment being one example.

A global pattern

Europe might be the loudest but is not alone.

Australia’s Hosting Certification Framework defines which providers can host sensitive government data, with explicit ownership and control criteria. Canada’s CCCS Medium Cloud Profile (formerly Protected B / Medium / Medium) sets sovereignty conditions for federal and regulated cloud use. The United Kingdom’s NCSC and National Security Strategy 2025 treat critical-infrastructure dependencies and supply-chain exposure as national resilience issues, with the Cyber Security and Resilience Bill in preparation. Even the United States, traditionally the source of extraterritorial legal reach for others, has tightened control over its own dependencies – its Outbound Investment Security Program took effect in January 2025 and was codified by the COINS Act in December 2025, alongside continuing executive orders on connected technology supply chains.

The vocabulary differs, but the direction is consistent: every major economy is now codifying which levers it will accept, and which it will not.

From sovereignty to continuity

This is also where sovereignty meets business continuity and disaster recovery. Traditional BC/DR plans assume the lever you can’t control is a fire, a flood, or an outage. The levers framing forces a wider set of questions: what happens if a single international route fails, if a hyperscaler changes terms, a model becomes unavailable, or inference locations are restricted by jurisdiction? Each is a lever moving – and each demands the same operational discipline as a classical disaster scenario, applied to legal, commercial, and architectural dependencies. Recovery cannot assume the affected geography will still be reachable, or that the rules governing it will still be the same. A credible plan needs somewhere outside the blast radius – far enough away, and under different conditions, to absorb the load when the original environment is no longer available or no longer permissible.

In this context, resilience depends not on whether alternatives exist, but on whether the enterprise can actively pull a different lever fast enough when the original one becomes non‑viable.

And some levers are exercised through operational authority rather than technology alone: who can access systems, initiate recovery, or execute change when conditions shift. When that authority is concentrated outside the enterprise’s control or jurisdiction, it becomes a lever held by others; when it is shared, auditable, or retained, the dependency can be reduced.

Conclusion: know your levers, build for adaptation

Digital sovereignty in 2026 is about designing systems that remain governable when conditions change. The organizations that navigate this well will not be those that withdraw from global ecosystems. They will be the ones that know exactly which levers exist, who holds them, and what reversibility costs – and that have built architectures flexible enough to absorb a lever moving without business disruption.

That means three operational principles:

  • Choice – having genuine alternatives at every critical layer, so that when one provider, platform, or route becomes unavailable, an equivalent is already present and ready to carry the load.
  • Neutrality – designing for interoperability, portability, and credible exit from day one.
  • Local with global connectivity – keeping critical workloads governable under local conditions while ensuring that, when a region becomes unreachable or its rules shift, operations can continue from a different one.

The bottom line is architectural: sovereignty is the property of a system that can adapt when its levers shift, not the property of a system that has tried to eliminate them.

Example questions worth asking to discover your own levers

  • Which external dependencies could prevent critical business operations from running within 24-72 hours?
  • Which dependencies are realistically reversible within 30 days – and which ones would take months or longer to unwind?
  • Where does our ability to operate depend on a single provider’s control plane – for example in cloud platforms, identity systems, AI models or APIs, or core network connectivity?
  • Where are our safeguards based purely on contracts and promises – and where are they enforced technically, regardless of intent?
  • If a dependency shifts, what is the blast radius – a single workload, an entire region, or the company as a whole?

The chokepoint/control-point distinction here draws on TNO Vector’s work extending these concepts from supply chains to digital infrastructure, and on the broader ‘weaponized interdependence’ framework by Farrell, H. & Newman, A.

Originally published on LinkedIn