---
title: "Sovereignty Is Not a Destination – It’s an Operating Capability | Blog | Commvault"
type: "BlogPosting"
language: "en-US"
url: "https://www.commvault.com/blogs/sovereignty-is-not-a-destination-its-an-operating-capability"
date: "2026-11-06T09:00:32-05:00"
modified: "2026-11-05T19:01:33-05:00"
description: "Stop chasing a sovereign end state. Build the ability to change course on your terms."
image: "https://www.commvault.com/wp-content/uploads/2026/11/Thumbnail_Blog-Sovereignty-Not-a-Destination-2026.png"
authors:
  - name: "Ruben Renders"
    jobTitle: "Solutions Director, MSP, Commvault"
breadcrumbs:
  - name: "Commvault Home"
    url: "https://www.commvault.com/"
  - name: "Blogs"
    url: "https://www.commvault.com/blogs"
  - name: "Sovereignty is not a destination its an operating capability"
---

# Sovereignty Is Not a Destination – It’s an Operating Capability

Ask five leaders what digital sovereignty means and you will get five answers. Some hear a policy debate. Others hear a vendor pitch. Most feel stuck.

---

In this episode of STRIVE, I sat down with Dirk Deridder, CTO at Smals, the Belgian ICT service provider for the public sector; and Mark Molyneux, Commvault’s CTO of Northern Europe. We landed on one idea. As Mark put it plainly: Sovereignty is not a destination. It’s an operating capability.

---

Watch the [full episode](https://www.readiverse.com/resources/video/strive-digital-sovereignty-vs-resilience-what-comes-first).

---

## Key Takeaways

---

- Sovereignty is not the end goal. Resilience and autonomy are.
- The hardest recovery problem is rebuilding an entire ecosystem – data, certificates, keys, and trust relationships – not restoring a single application.
- Measure portability, not ideology. If you can swap a component in a day, you have far less sovereignty risk.
- Not everything needs to be sovereign. Find your organization’s minimum viable sovereignty by mapping your dependencies and classifying your services, and that should help shrink the problem.
- Test your exit before you need it.

---

## Why the Conversation Changed

---

Dirk has watched IT become the backbone of critical services for decades and noted that dependencies are not new. The conversation is. Before 2025, his talks centered on data protection and residency. Since then, sovereignty comes up everywhere.

---

Mark sees the same pattern. Across the EU, it now ranks among the top three agenda items in his customer meetings. Leaders no longer ask only where data lives. They ask who controls the technology stack, what happens if commercial terms change, and how dependent they are on a single jurisdiction.

---

## Resilience Is the Real Objective

---

Dirk makes a clear distinction. Some sovereignty decisions belong to policymakers. As a CIO or CTO, you cannot make your country more sovereign. However, you can control your organization’s digital autonomy: you can make independent choices and deliver your roadmap. And you can control your resilience if you can answer the question, “Can we keep operating when a dependency fails, whatever the reason?”

---

That framing works for private organizations, too. Know your dependencies, but make resilience your goal, whether the cause of a disruption is a natural disaster, a human error, a contractual dispute, or anything else.

---

## The Hardest Problem Is the Ecosystem

---

Modern organizations do not run isolated systems. They run systems of systems. Dirk uses the example of a national e-health platform connected to pharmacies, hospitals, and doctors. Recovery means more than restoring a database. It means re-creating the environment: certificates, endpoint identification, firewall rules, encryption keys, and the trust relationships across the whole chain.

---

Mark added that cyber resilience changes the lens. A recovery time objective (RTO) measured in seconds works for a failed server. For a cyberattack, you need a [mean time to clean recovery](https://www.commvault.com/blogs/the-5-critical-steps-to-clean-recovery). Sovereignty needs the same shift.

---

## Sneak Peek: Can Your Organization Recover From a Catastrophic Failure?

---

---

In this moment from the **STRIVE** discussion, Dirk describes two different failure scenarios, from a catastrophic failure of the entire internet to a single point of failure caused by something as small as an unknown DNS dependency. In both cases, he asks organizations to discern whether they are resilient enough to recover everything – not just data – if such a scenario were to occur. And he advises that mapping dependencies is the first place to start in the journey to resilience.

---

## Measure Portability

---

Dirk offers a practical test for sovereignty: Define a portability time objective for your critical services. If you can swap a component or provider within one day at zero cost, you have no sovereignty issue. You can simply switch to a different component or provider.

---

Most organizations cannot. The cause is not technical debt. It is technical gravity. Migrations can take months and consume budgets. He says identity and access management creates some of the strongest pull, so start there.

---

## Every Choice Has a Price

---

You pay for more control in functionality, support, and cost. Resilience works the same way. High availability can mean six servers instead of one. Every extra copy of your data – live, backup, air-gapped, or held in a data embassy – adds cost. Your risk appetite and your industry set the right level.

---

Mark’s point: The mission is not maximum sovereignty. It is the right amount for your risk appetite.

---

## Find Your Dependencies, Then Decide What Must Be Sovereign

---

Dirk’s advice is to follow a risk-based approach. Small items can cause big failures, and a single DNS dependency can leave you stuck. Mark added that dependency mapping gives you the filter. Classify your business services and the data behind them. One hundred percent of your estate does not need to be sovereign. When you categorize, the challenge shrinks fast.

---

This is a business exercise, not only an IT one. Ask the business what is critical and you will hear everything. Break it into core processes and a short list will emerge.

---

## Provider Contracts Give You Control – Testing Gives You Capability

---

A strong provider contract matters. Dirk looks for clear terms, such as 12 or 24 months to exit if a vendor stops a service. I added that transition service agreements spell out what a transition looks like. That addresses part of the legal side. It does not solve resilience, which is a hard operational capability.

---

So test it. Mark’s advice is to exercise control before you must. Move data between providers regularly. Do it when the usual expert is out of the office. You do not want to find your gaps at two in the morning.

---

## Where to Start

---

Dirk’s advice to a leader at the beginning of their sovereignty journey:

---

- **Start close to home.** Define your minimum viable company by finding the entry point that your people need to do their job.
- **Define your critical processes.** If an hour of downtime bankrupts you, it is critical. If it’s a process like payroll, where you have backups or workarounds that you can employ while the system is down, it’s not critical.
- **Inventory your dependencies.** Look critically at your technology stack, not only from a sovereignty or a geographical perspective, but look at it from a vendor perspective as well. What if this vendor triples their price? Will I be kept hostage? Or can I say, “no, I will move away to another one”?

---

I would add one more test: Can you still move money and keep customers served? If the euros keep flowing, you are still operating.

---

## Why This Conversation Matters

---

Sovereignty will keep rising on board agendas. Leaders who treat digital sovereignty as a destination will chase a perfect state that does not exist. Leaders who treat it as an operating capability will build something better: the proven ability to change course, recover cleanly, and keep critical processes running. That is [ResOps](https://www.commvault.com/explore/resilience-operations).

---

Dirk closes with the best advice of the session: Stay pragmatic. Prepare for the worst you can realistically plan for, and treat it as a practice.

---

## Watch the Full Episode

---

In this conversation, we explore:

---

- Why autonomy and resilience matter more as goals than sovereignty.
- How to rebuild an ecosystem of ecosystems.
- What a portability time objective looks like in practice.
- How to map dependencies and set the right level of sovereignty.
- The three first steps for leaders that are starting out.

---

[Watch now.](https://www.readiverse.com/resources/video/strive-digital-sovereignty-vs-resilience-what-comes-first)

---

And to [learn more about digital sovereignty](https://www.readiverse.com/explore/digital-sovereignty), we’ve put together a compendium of resources, including a readiness report, webinar, and several blog posts and podcasts.

---

## FAQs

---

**Q: Is digital sovereignty the same as resilience?**

---

**A:** No, but they overlap. Sovereignty is an operating capability inside resilient operations. It shows up when you must exercise control, such as moving a workload or exiting a vendor.

---

**Q: What is a portability time objective?**

---

**A:** It is the time it takes to swap a critical component or service for an alternative. The shorter it is, the lower your digital sovereignty risk.

---

**Q: Does everything need to be sovereign?**

---

**A:** No. Map your dependencies, classify services and data, and apply the right level of control based on your risk appetite.

---

**Q: What is minimum viable sovereignty?**

---

**A:** [Minimum viable sovereignty](https://www.readiverse.com/blogs/minimum-viable-sovereignty) is the minimum set of requirements an organization needs to retain effective control over its digital assets, operations, and data, how data must be treated, where it can be hosted, and what exit plans must be available. Where technology platforms and infrastructure are located matters, but location alone is not enough.

---

**Q: Where should I start?**

---

**A:** Begin with your workplace environment: Define your critical processes and build an inventory of your technology and vendor dependencies.

---

[Ruben Renders](https://www.linkedin.com/in/rubenrenders/) is Solution Director, MSP, at Commvault.
