Can You Actually Measure Digital Sovereignty? :The Sovereignty Stack : Part 5 — Series Finale
The Sovereignty Stack // Part 5 — Series Finale Can You Actually Measure Digital Sovereignty?
Can you identify the five technology dependencies your organisation would struggle most to replace?
Not the five most expensive. Not necessarily the five most critical applications. The five dependencies where your organisation has the least strategic choice — where changing direction would be most costly, most disruptive, or most time-consuming.
Most organisations can tell you where their applications run. They can tell you their cloud providers, their identity platform, their AI services. What they often cannot answer is the harder set of questions:
That is the difference between knowing your technology estate and understanding your sovereignty posture. And if digital sovereignty is an architectural property — which is the premise this series has built from Part 1 — then it should be possible to assess it architecturally. This final part of the Sovereignty Stack introduces a practical framework for doing exactly that.
01 — Sovereignty Is Not Binary
Digital sovereignty is sometimes discussed as though an organisation either has it or does not. That framing is not useful. Every enterprise has dependencies — cloud providers, software platforms, identity services, AI models, open-source components, hardware manufacturers, specialist suppliers. Some of those dependencies are entirely reasonable. Some are unavoidable. Others are poorly understood. The objective is not to eliminate dependency. It is to understand it well enough to make deliberate choices about it.
The shift from declaration to assessment is what this framework is designed to enable. Saying an organisation is "sovereign" or "cloud-agnostic" is a claim. Being able to show which dependencies have realistic exit paths, which have none, and which decisions are quietly reducing future choice — that is an architectural discipline.
02 — The Five-Dimension Sovereignty Test
For every critical technology dependency, five questions need honest answers. The framework below can be applied to any dependency across any of the seven sovereignty layers — a cloud platform, an AI provider, an identity service, a critical open-source library, or a hardware supplier.
Dependency — What are we actually dependent on?
Do not stop at the vendor name. The dependency may be a cloud service, a database, an identity provider, a proprietary API, an AI model, a software library, a hardware component, or a specialist supplier. The first challenge is often discovering the dependency beneath the dependency — the transitive relationships that are not visible in procurement contracts but are just as operationally critical.
Control — Who ultimately controls it?
Physical location alone does not answer this question. Control over a dependency means control over the technology roadmap, the data, the encryption keys, the identity infrastructure, the underlying model, and the intellectual property. An organisation can host data in-country while a foreign provider controls the encryption keys. A workload can run locally while the vendor controls the API it depends upon. The question is not where it sits. It is who can change it, restrict it, or remove it.
Criticality — What happens if it changes or disappears?
A dependency becomes strategically significant when its failure or change can materially affect an important business capability. The relevant scenarios are not just outages — they include price increases, licensing changes, product discontinuation, API changes, ownership changes, and regulatory or geopolitical constraints that make the dependency unavailable or unacceptable. The question is not whether any of these will happen. Some eventually will. The question is what the organisation loses when they do.
Replaceability — Is there a usable alternative?
This is where architecture assessments most commonly become too optimistic. Another vendor existing in the market does not mean the dependency is replaceable. The real question is whether the organisation could move the data, the integrations, the security controls, the users, the operational processes, and the accumulated knowledge to that alternative. An alternative that requires rebuilding all of those things is not a realistic exit option — it is a theoretical one. The test is not "does an alternative exist?" It is "could we actually use it?"
Exit Effort — What would it actually take to leave?
Estimate the time, cost, technical effort, contractual constraints, migration effort, retraining requirement, integration reconstruction, and operational disruption. A dependency with a theoretical alternative but a five-year exit programme is not meaningfully replaceable in practical terms. Replaceability is ultimately measured by the realism of the exit — not the existence of a competitor's product brochure. This number, even roughly estimated, is often the most clarifying piece of information in a sovereignty assessment.
03 — Apply the Test Across the Seven Layers
The five questions apply consistently across all seven sovereignty layers explored in this series. The value of using the same framework across every layer is that it allows concentration of dependency to become visible — which layer, which provider, which decision is accumulating the most strategic constraint.
The objective is not to produce seven independent sovereignty scores. It is to identify where strategic dependency is concentrated — which layer, which provider, which architectural decision is accumulating the most constraint on future choice.
04 — Criticality Is Not the Same as Sovereignty Exposure
This distinction is the most practically important insight in the framework. Standard risk assessments prioritise by criticality. Sovereignty assessment requires a different lens — because the dependency that deserves the most attention is not always the most critical one. It is the one where you have the least choice.
A highly critical platform that has several realistic alternatives and can be migrated within an acceptable timeframe and cost.
Lower sovereignty exposure
A moderately critical platform that has almost no realistic alternative and would take years and significant cost to replace.
High sovereignty exposure
Dependency B deserves greater strategic attention — despite being less critical in operational terms. This suggests the governing principle of the framework:
05 — From Assessment to a Sovereignty Heatmap
The five-dimension test produces inputs that can be visualised as an enterprise architecture heatmap. For each significant dependency, three dimensions are captured and plotted together. The resulting view is considerably more useful than any binary sovereignty declaration.
Business Criticality
How badly would the organisation be affected if this dependency changed or became unavailable?
Replaceability
How realistic is a usable alternative — not in theory, but given the actual migration effort involved?
Exit Effort
How difficult, costly, and time-consuming would it be to change this dependency if circumstances required it?
The heatmap changes the leadership conversation. Instead of asking "are we sovereign?" — a question that rarely produces useful answers — it enables a more specific and actionable question: "where are we most constrained, and which of those constraints was a deliberate architectural decision versus one we drifted into?"
06 — Compliance Is Not Sovereignty
This distinction deserves to be stated explicitly, because in regulated environments — and particularly in Saudi Arabia — the two are sometimes treated as equivalent. They are not.
Compliance asks whether the required controls are in place today. Sovereignty asks how much strategic choice the organisation retains if circumstances change tomorrow. A cloud environment can fully satisfy NCA security requirements and still be extremely difficult to exit. A platform can meet every contractual obligation and still create substantial switching costs. An AI service can satisfy data governance requirements while creating deep model and context dependency that was never assessed.
For organisations operating under the NCA framework family — ECC, CCC, OTCC, DCC, and the others — compliance assessment and sovereignty assessment are complementary disciplines that address different questions. CCC compliance tells you whether your cloud architecture satisfies the NCA's current security and data localisation requirements. A sovereignty assessment tells you whether that architecture leaves you with meaningful choices if those requirements change, if a provider's regulatory status changes, or if commercial terms become strategically unacceptable.
As Vision 2030 digital programmes mature and the regulatory environment around cloud governance, AI assurance, and data residency becomes more prescriptive, the gap between "compliant today" and "strategically resilient tomorrow" becomes more consequential. The Five-Dimension Sovereignty Test applied to your cloud and AI dependencies is not a replacement for NCA compliance work. It is the architectural layer that sits above it — and the one that most organisations in the Kingdom have not yet formally built.
The architectural question goes beyond whether a service satisfies today's control requirements. It also becomes: what strategic choices does this architecture leave us with tomorrow?
07 — The Architecture Question That Matters
Enterprise Architecture has a well-established set of quality questions it asks of every significant decision. Is the solution secure? Is it scalable? Is it resilient? Is it interoperable? Is it cost-effective? These are the right questions. They are not complete ones.
Digital sovereignty adds a dimension that most architecture review boards do not yet formally assess:
That question should influence architectural decisions before dependency becomes difficult to reverse — not after a migration project reveals how constrained the options actually are. The organisations that navigate the next decade of technology change most effectively will not necessarily be those that adopted the most capable platforms. They will be those that understood their dependencies clearly enough to remain architects of their own choices.
08 — The Final Architecture Takeaway
Sovereignty is ultimately the freedom to choose differently when you need to. And that freedom is an architectural property — designed in, assessed regularly, and governed with the same rigour applied to security, resilience, and performance.
If you applied the Five-Dimension Sovereignty Test to your technology estate today — which dependency would be hardest for your organisation to walk away from, and have you ever actually measured what it would take to leave?
09 — The Sovereignty Stack — The Complete Series
Five articles. Seven layers. One consistent question: where does your organisation actually retain the freedom to choose?
| Part | What It Covers |
|---|---|
| Part 1 The Framework |
Digital Sovereignty Is a Stack, Not a Layer Why sovereignty cannot be addressed as a single control or a single layer — and why Enterprise Architecture is the right discipline to govern it. |
| Part 2 Data & Identity |
Who Controls Information, Trust and Access? The two foundational layers — data sovereignty and identity sovereignty — and why control over both is the prerequisite for everything above them in the stack. |
| Part 3 AI |
When Enterprise Intelligence Becomes a Strategic Dependency Why the real AI lock-in is not the model — it is the context layer of prompt libraries, RAG repositories, and organisational knowledge built around it. |
| Part 4 Platform, Infrastructure, Standards & Supply Chain |
Interoperability Is Not Enough The four-level progression from interoperability to strategic choice — and why moving a workload is not the same as preserving a capability. |
| Part 5 This article |
Can You Actually Measure Digital Sovereignty? The Five-Dimension Sovereignty Test — a practical framework for identifying, assessing, and prioritising strategic dependencies across the full technology estate. |
The series began with a simple question: what does digital sovereignty actually mean for Enterprise Architecture? It ends with a more practical one: where does your organisation actually retain the freedom to choose?
Comments
Post a Comment