Why Sovereignty Decisions Get Stuck - Making Dependencies Visible
In our previous blog, we discussed three aspects of sovereignty: data, operational, and technical. These aspects help leadership distinguish various risk types and prevent viewing sovereignty as a single issue.
However, having a framework by itself is not enough to drive decisions. Many organizations understand the concept and acknowledge that sovereignty involves trade-offs. They recognize that different workloads need varying degrees of control. Nonetheless, the conversation remains stagnant.
The reason is often simple: they cannot answer the basic questions with confidence.
Where does our data actually run? Who can access it? Which legal entity provides the service? Which identity provider is critical? Which platform services are unique to one vendor? What happens if a vendor is acquired, restricted, unavailable, or no longer strategically acceptable?
These questions cut across architecture, procurement, security, legal, compliance, operations, and business ownership. That is why sovereignty decisions get stuck. Not because leaders lack awareness, but because the organization lacks a shared and validated view of its dependencies.
Not because leaders lack awareness, but because the organization lacks a shared and validated view of its dependencies.
The Real Problem Is Not a Lack of Technology
The sovereign cloud debate often focuses on supply: which providers exist, which hyperscaler region to use, which European alternative is credible, whether private cloud should return, or whether open source is the answer.
They know the main provider, application name, and possibly the primary cloud region or SaaS contract owner. However, this is not the same as understanding the dependency chain. Critical dependencies often reside deeper within the infrastructure, such as in identity providers, logging platforms, backup locations, support access, data replication, API gateways, license servers, key management, subcontractors, integration platforms, and specialized knowledge held by a few individuals.
This is where the gap appears. Architecture diagrams may show the application, but not the support model. Contracts may name the vendor, but not every subcontractor or data flow. Security assessments may cover access controls, but not whether recovery depends on one external team. Procurement may know the commercial relationship, but not which technical services are impossible to replace quickly.
As a result, each team sees a different aspect of the dependency landscape. Technology might consider the risk manageable due to platform stability. Compliance could feel uneasy because legal entities, data flows, or access paths are ambiguous. Procurement might concentrate on contract details. Business owners could prioritize cost and continuity. All these perspectives are valid in their own way; however, they all relate to the same overall situation.
This is why decisions stall. Without a clear understanding of dependencies, sovereignty debates become vague. Assumptions are left unexamined, and risks are either overstated or downplayed. People hesitate to make choices when they do not understand what the organization fundamentally relies on.
Mapping the Dependency Chain
The first step is to map where systems, data and operational dependencies actually sit. Not where people assume they sit. Not where the contract headline suggests they sit. Where they actually sit.
For a workload, this means looking at the full chain: application hosting, data storage, backup and recovery, identity, network dependencies, monitoring, logging, support access, administrative privileges, third-party services and key management.
This step often reveals uncomfortable surprises. A service believed to be fully European may depend on a US-headquartered SaaS platform for support or monitoring. A workload described as multi-cloud may depend on a single identity provider. A system assumed to be portable may rely on proprietary data services.
None of this automatically means the architecture is wrong. The point is to replace assumptions with evidence.
Adding Business and Risk Context
Dependencies only matter in context. A single-vendor dependency for a public website is not the same as a single-vendor dependency for a national identity service, a payment platform or a patient records system.
The second step is to connect the dependency map to the actual business and regulatory context. What data is involved? Which processes depend on the workload? What is the impact of downtime? Which regulations apply? Which stakeholders would be affected if the service became unavailable or legally constrained?
This is where the three sovereignty dimensions become useful. For some workloads, data sovereignty is the main concern. For others, operational continuity is the real issue. In other cases, technical lock-in creates a long-term strategic risk.
The goal is to move away from generic statements like "this is high risk" or "this is compliant" and toward more useful statements: this workload has acceptable data residency, weak operational independence and high technical lock-in. That is clarity leaders can work with.
Test Assumptions Through Scenarios
Sovereignty becomes real when tested against scenarios. Not extreme scenarios invented to scare people, but realistic ones that could affect the organization.
What happens if a provider discontinues a service? What happens if a vendor is acquired by a company under another jurisdiction? What happens if support access is restricted? What happens if a regulator asks for evidence of control? What happens if the organization needs to exit within twelve months?
Scenario thinking changes the conversation. Instead of debating whether a dependency is good or bad, leadership can assess consequences. Can we continue operating? Can we recover? Can we prove control? Can we change direction? How long would it take?
This also prevents overreaction. A dependency may be acceptable if the impact is low, alternatives are available, and an exit path exists. Another may require action because the impact is high, and there is no credible fallback.
Instead of debating whether a dependency is good or bad, leadership can assess consequences.
Make Trade-Offs Explicit
The final step is to turn visibility into choices. Sovereignty is always a trade-off between control, cost, speed, resilience, innovation and complexity.
Once dependencies are visible, those trade-offs become concrete. More operational control may require higher cost and more internal capability. Greater technical portability may reduce access to platform-specific innovation. Stronger data sovereignty may require changes in architecture, contracts or key management.
This is where governance becomes practical. Some workloads may require immediate mitigation. Some may need a medium-term roadmap. Some may simply need better documentation, monitoring or contractual clarity.
Begin by identifying where the workload depends on certain vendors, regions, platforms, data flows, operational teams, contracts, and key management controls. Once these dependencies are clear, discussions become more straightforward: which risks are acceptable, which need mitigation, and which trade-offs the organization is willing to make.
From Chaos to Shared Understanding
One of the biggest mistakes is to apply one sovereignty policy everywhere. It usually creates either excessive cost or false comfort, because business criticality, data sensitivity, regulatory exposure, downtime impact, and available alternatives differ per workload.
The starting point must therefore be concrete. One workload. One business process. One critical service. The outcome should not be a generic maturity score, but a clear view of dependencies, risks, scenarios, and trade-offs.
What Good Visibility Enables
Good visibility changes the quality of the conversation. It moves the debate from opinions, assumptions and vendor preferences to facts that can be tested.
This sharpens decision-making. Leadership can more clearly determine when control is necessary, when speed is more important, where risk can be tolerated, and where dependencies should be minimized.
Dependencies aren't inherently problematic; invisible dependencies are. Once made visible, they can be owned and deliberately accepted, mitigated, monitored or eliminated.
In the final blog, we'll transition from understanding to action, exploring how to develop a sovereignty strategy based on practical decisions, common facts, and defined responsibilities.
