Ask most IT leaders whether their organisation has digital sovereignty over its service management landscape, and you will get a long pause. Then, usually, a resigned smile. We believe the conclusion that it is impossible is wrong.
Ask most IT leaders whether their organisation has digital sovereignty over its service management landscape, and you will get a long pause. Then, usually, a resigned smile.
They know the answer. And they have learned to live with it.
The truth is that most enterprise service management environments today are built on a foundation of US-owned, cloud-hosted platforms. Directory services. Identity and authentication layers. Platform-as-a-Service infrastructure. The SaaS applications that run HR, finance, and IT operations. Each one a dependency. Each one a point where strategic decisions — pricing, data residency, access policy, product direction — are made by someone other than you.
For many organisations, this has led to a familiar conclusion: digital sovereignty is a worthy ambition, but an impossible one. The architecture is already built. The integrations are deep. The contracts are signed. Starting over is unthinkable.
We believe this conclusion is wrong. Not because the dependencies are not real — they are — but because sovereignty is not a binary state. It is a direction of travel.
To understand the challenge, it helps to map where the dependencies actually sit. In a typical enterprise, the stack looks something like this:
Each layer on its own may seem manageable. Together, they create an environment where meaningful strategic independence is genuinely constrained. Pricing negotiations lack leverage. Regulatory compliance rests on assurances rather than controls. And the ability to evaluate alternatives — let alone act on them — is severely limited.
This is not an accident. It is the product of rational decisions made under time and cost pressure over many years. But rational at the time does not mean optimal for the future.
The most common response to a digital sovereignty conversation is paralysis. Leaders see the full picture — the accumulated dependencies, the switching costs, the integration complexity — and conclude that meaningful change would require a wholesale replacement of their technology estate. A multi-year programme. A nine-figure budget. Unacceptable operational risk.
This framing is understandable but unhelpful. It turns a question of direction into a question of destination — and because the destination seems impossibly distant, the journey never begins.
There is also a cultural dimension. Many technology teams have developed deep expertise in the specific platforms they operate. They are effective precisely because of that depth. The idea of challenging or changing those platforms can feel threatening — both to individual identities and to the short-term operational stability that teams rightly protect.
But the organisations that are beginning to move are not replacing everything. They are making deliberate, targeted improvements — each of which incrementally reduces dependency, increases control, and strengthens their negotiating position. The whole does not need to change for meaningful progress to be made.
This is the central point that is most often missed in these conversations.
Digital sovereignty is not a switch you flip. It is a spectrum. And your organisation is already somewhere on that spectrum — whether or not you have consciously placed yourself there. The question is not whether you are fully sovereign or fully dependent. The question is whether you are moving in the right direction.
Every decision you make about how you design, configure, integrate, and document your service management environment either increases your sovereignty or reduces it.
Custom code that only your vendor can maintain reduces it. Clean, well-documented, out-of-the-box implementations increase it. Data trapped in proprietary formats reduces it. Portable, well-structured data models increase it. Processes that exist only inside a vendor's workflow engine reduce it. Processes that are understood and documented independently of any tool increase it.
None of these changes requires you to abandon the platforms that are creating value today. They require a different set of design principles — applied consistently, decision by decision, project by project.
What does a sovereignty-oriented approach look like in practice? The following illustrate the kinds of targeted decisions that begin to shift the balance.
Ensure that the data your service management environment generates — tickets, configurations, service records, audit trails — is accessible in open, structured formats. Not just theoretically accessible through an API, but practically exportable, documented, and regularly validated. Your data is one of your most important assets. It should belong to you in a meaningful sense.
Every layer of custom code is a layer of lock-in. The short-term convenience of building exactly what a stakeholder asked for often becomes a long-term liability — a codebase that only certain people understand, that breaks on upgrades, and that makes migration progressively more expensive. Out-of-the-box implementations that follow the platform's intended design are not just easier to maintain. They are a form of architectural sovereignty.
If your incident management process only exists inside your ITSM platform's workflow engine, then your process is not portable. Documenting your processes — truly documenting them, not just describing the screens — gives your organisation the ability to re-implement, migrate, or adapt without starting from zero. It also forces a discipline that typically improves the processes themselves.
Point-to-point integrations between proprietary platforms create a mesh of dependency that is extraordinarily difficult to change. Where possible, build integrations through clean, well-documented interfaces — ideally using open standards — that can be re-pointed without rebuilding. This does not eliminate dependency, but it contains it.
Sovereignty is not just a technical property — it is an organisational one. If meaningful platform decisions can only be made by following a vendor's recommendations, because no one internally has the depth to evaluate them independently, then you do not truly control your environment. Investing in internal knowledge, governance frameworks, and the ability to make informed independent judgements is itself a form of sovereignty.
It is worth noting that the external environment is shifting in ways that make this conversation increasingly urgent rather than merely aspirational.
Data protection frameworks, sector-specific regulations, and emerging digital resilience requirements across European and global markets are placing increasing scrutiny on where data resides, who can access it, and under what legal frameworks. Organisations that have built their service management environments on the assumption of unrestricted data flow are finding that assumption increasingly challenged — not just by their own leadership, but by regulators and clients.
Organisations that have already begun the journey toward greater sovereignty are finding that they are better positioned to respond — not because they have solved the problem, but because they have been thinking about it systematically and have already reduced their exposure.
Service management sits at the intersection of almost every major dependency in the enterprise. It touches identity, process, data, and integration simultaneously. That makes it both the most exposed area from a sovereignty perspective — and one of the most powerful levers for improving it.
Good platform governance and digital sovereignty are, in large part, the same thing pursued for different reasons.
The governance disciplines that protect your service management architecture — clean configurations, documented processes, portable data, well-bounded integrations — are precisely the disciplines that build sovereignty. Organisations that approach service management governance with sovereignty in mind do not have to make a trade-off between operational excellence today and strategic independence tomorrow. Done well, they get both.
Digital Sovereignty is not about doing without the platforms that create value. It is about building a relationship with those platforms on your own terms — with the knowledge, the governance, and the architectural discipline to negotiate, adapt, and decide from a position of genuine strength.
The starting point is not a technology replacement programme. It is an honest assessment of where dependency risk is concentrated — across your directory and identity layers, your service management platform, your integration architecture, and your internal knowledge and governance — and a clear view of which improvements will move the needle most meaningfully.
From that assessment, a sequenced, achievable roadmap becomes possible. Not one that requires you to dismantle what works, but one that systematically closes the gaps — building sovereignty incrementally, in parallel with the value delivery that your organisation depends on today.
The organisations that will have the most strategic freedom in five years are the ones making deliberate choices right now. Not dramatic choices. Deliberate ones.
We assess where dependency risk is concentrated in your service management environment and design a practical path toward greater control — without disrupting the value you are already getting.
Start the conversationnow2value is an independent Service Management advising & consulting firm headquartered in Copenhagen, specialising in Enterprise Service Management governance, value-driven platform delivery, and Digital Sovereignty advisory.