Digital sovereignty: how to control the dependencies that matter

Digital sovereignty: how to control the dependencies that matter

Across boardrooms and public institutions, the conversation about who controls our digital infrastructure, data, and AI is intensifying. Even more so how it affects what you can deliver to customers, what it costs to operate, and how exposed you are when conditions change. It shows up in different forms: cloud strategy, AI adoption, vendor risk, regulatory pressure, but underneath, it is all the same question:

“How much control do you actually have over the digital infrastructure your organization depends on?”

Digital sovereignty is often framed as a political or procurement debate. That framing is too narrow. Digital sovereignty sits at the intersection of risk, customer value, and cost. When critical systems and data are controlled elsewhere, your risk exposure is set by someone else’s priorities. Your ability to serve customers is constrained by what their platform allows. And your costs harden as switching becomes too expensive to contemplate. Digital sovereignty is the discipline of taking back control over those three things. The goal is not vendor independence; it is sufficient control over the capabilities that matter most.

Table of contents

Why digital sovereignty matters now: AI adoption, concentrated software supply chains, and geopolitical risk

Three dynamics converge that make the issue more urgent:

  1. AI is moving from experimentation to scale, which means organizations are applying AI models to sensitive data in core processes. AI adoption in Europe is increasing rapidly, which raises the stakes materially.
  1. Software supply chains are heavily concentrated. According to a 2025 European Parliament report, around 80% of European corporate software and cloud spending flows to U.S. companies, leaving organizations dependent on infrastructure and policy decisions made elsewhere.
  1. Geopolitics has moved from background to boardroom as tariffs, sanctions, and shifting alliances expose digital dependencies that earlier were considered efficiencies.

Together, these dynamics have moved digital sovereignty from a niche concern to an active management priority.

What digital sovereignty delivers for public and private organizations

Done well, digital sovereignty will:

  • Reduce risk: tighter control over critical systems, data, and processes reduces exposure when vendors shift ownership or countries change policies or tariffs. One of our PE clients moved their core document management system from the cloud to on-premise, allowing them to run local open source AI models and deliver the functionality they need at close to zero risk.
  • Improve customer value: organizations that own and govern their own data can build faster, more personalized, and more innovative services, because they are not constrained by what a vendor’s platform allows or prioritizes. A financial services client with modular architecture was able to onboard a new AI-powered customer interaction layer in weeks rather than quarters, simply because their data was portable and their stack was not locked to a single provider’s roadmap.
  • Lower cost: better sourcing decisions become possible – and lower cost over time becomes likely – once lock-in eases and transparency improves. The French police force is running a customized Linux version, saving approximately €2 million per year in licensing costs and reducing total cost of ownership by an estimated 40%.

These benefits matter whether you are a private or a public organization. For private organizations the stakes are competitive: speed, cost, and resilience. For public organizations they are democratic: the ability to be transparent, and govern in the public interest.

Digital sovereignty in practice: a 3-step approach

Step 1: Make your dependencies explicit

Most organizations have no clear picture of where their dependencies actually sit. The starting point is making dependencies explicit. Start at the top: identify the core processes that drive value, then map the systems and data pools that support them, and finally identify the technologies and suppliers behind those systems and data.

For each supplier that touches core processes, map the jurisdictions they fall under, not just where they are headquartered. Ownership structure, parent company, and underlying infrastructure all shape who can legally access systems and data.

Step 2: Weigh risk, customer value, and cost; and decide where control matters

The practical question is always: given what we now know about our dependencies, what is the right balance between risk control, cost, flexibility, and customer value? Pursuing total sovereignty is impractical, but ignoring dependencies until they become crises is dangerous. Some dependencies are rational and worth keeping. Others quietly compound risk or constrain the organization in ways that only become visible when it is too late to act cheaply. Digitally sovereign organizations are not the ones that control everything, but the ones whose IT stack is built to adapt as the balance shifts.

Based on your organization’s dependency scan and sovereignty considerations, prioritize by impact and feasibility: where does dependency hurt most, and where can we realistically change it? For each critical dependency, decide whether to accept, reduce, or replace it.

Open source software, hyperscaler solutions, European alternatives, proprietary niche platforms: none are inherently right or wrong. What matters is whether the choice controls risk, ensures flexibility, provides transparency, and controls costs. The same logic applies to AI components: which model runs where, on what terms, and with what ownership over prompts, outputs, and data.

The German state Schleswig-Holstein began replacing Microsoft Office with LibreOffice due to vendor dependency and high licensing costs. Some technical dependencies in specialized applications made a complete switch impractical, so the migration was phased deliberately: by end of 2025, 80% of workplaces had made the switch, with the remaining 20% still running Microsoft where substitution was not yet feasible. The result was meaningfully reduced exposure to U.S. jurisdiction, €15 million annual licensing cost savings, and – critically – no degradation in public services.

Step 3: Architect, plan and execute

Next, dependency findings need to be translated into clear architecture choices, a business case, and a roadmap to deliver. These are business as usual, though for sovereignty programs specifically, we see four pitfalls that are often underestimated.

The first is around ‘capabilities’: bringing systems back in-house requires skills and resources that most organizations have not built up or have lost over the years. The second is around ‘supplier pressure’: incumbents deploy active retention tactics, such as discounts, roadmap promises, migration friction. All of these make switching feel more expensive than it actually is. The third is around ‘internal inertia’: organizational reluctance to disturb what works today, which quietly delays action until the cost of moving has gone up. The fourth is around ‘short term costs’: switching has its costs, so the business case needs to reflect different external scenarios and the optionality that sovereignty provides.

The goal is not to eliminate every dependency. It is to know which ones you have, choose deliberately which to keep, and build an organization that can revisit those choices as conditions change.

Want to improve your digital sovereignty?

SparkOptimus helps organizations get concrete about digital sovereignty: which dependencies to keep, which to change, and how to execute. Curious how this applies to your organization? Get in touch with our team

Written by Joris Hulst, Matti van Engelen, Stephan Weenk, TIjmen Kroezen
Joris Hulst
Associate partner | Practice Lead Data & AI

Ready to transform your organization? Discover how with our 1-week scan.

Download the Gen AI in consumer goods benchmark report

Download the Gen AI in consumer goods benchmark report