To address mandates governing where their data is stored and used, many organizations think they can buy a sovereign cloud SKU from a hyperscaler and check the box. But this falls far short of what’s actually required – something they might discover only when a regulator asks them to demonstrate that a dataset never left a defined geography, that no foreign-jurisdiction personnel accessed it, and that they can recover it within 24 hours under incident conditions.
In a recent webinar, I joined Commvault GM Alex Zinin, who leads our digital sovereignty task force, along with Jakub Lewandowski, our associate general counsel for EMEA, and Pranay Ahlawat, our chief technology and AI officer, to examine what a complete approach to digital sovereignty needs to include and where most programs fall short.
See the full webinar and get the full Digital Sovereignty Decoded readiness report and implementation framework.
Key Takeaways
- The EU Cloud Sovereignty Framework defines eight sovereignty objectives, only one of which concerns data location.
- Selecting a sovereign cloud region addresses where data lives, but not who can access it, under what legal authority, or whether you can recover it under real conditions.
- A complete sovereignty posture spans four interdependent pillars: data locality, technological sovereignty, operational sovereignty, and jurisdictional sovereignty.
- Sovereignty programs that treat recovery architecture separately from primary data governance carry an unexamined risk that can surface during incidents.
- Rather than a policy of maximum sovereignty at any cost, organizations should design their strategy around minimum viable sovereignty: the right controls, consistently enforced, calibrated to actual obligations.
Digital Sovereignty Becomes an Enterprise Requirement
Over the past decade, the toughest digital and data sovereignty rules have mainly applied to government, defense, and other national‑security workloads. Outside of highly regulated sectors, many enterprises treated sovereignty principles as design guidance rather than a hard architectural constraint.
That’s now changing. GDPR enforcement has matured beyond guidance into substantial fines for operational failures, and newer regimes like DORA, NIS2, Germany’s KRITIS rules, and the EU Data Act have tightened expectations around jurisdictional control and operational resilience.
Sovereignty questions are now surfacing in RFPs, M&A due diligence, and board‑level risk reviews as well.
The EU Cloud Sovereignty Framework, published in October 2025, clarifies what this scrutiny actually evaluates. Of its eight sovereignty objectives, only one addresses where data resides. The other seven cover access control, operational dependencies, jurisdictional exposure, and recovery.
For enterprises, this structure is now the lens through which vendor capabilities must be evaluated.
Sneak Peek: Rethinking Sovereignty and Resilience
In this moment from the webinar, Jakub discusses how sovereignty is a risk posture, rather than a single product. Organizations need a holistic strategy that combines architecture, operations, governance, auditability, and recovery planning to address it.
Data Residency Does Not Equal Sovereignty
Data residency only answers questions about where. Sovereignty regulations also require being able to explain who, how, and under what conditions.
In practical terms, a complete sovereignty posture encompasses four interdependent pillars.
1. Data Locality
This pillar covers not just where data is stored, but where it travels. Control-plane artifacts, metadata, and telemetry can cross geographic boundaries even when primary data stays in-region.
2. Technological Sovereignty
This pillar addresses whether the organization controls the mechanisms that protect data:
- How access is granted.
- How data is encrypted.
- Whether encryption key custody is retained under all conditions.
A key concept here (pun intended) is the distinction between Bring Your Own Key (BYOK), where an organization’s own encryption keys are managed within the provider’s platform, and Hold Your Own Key (HYOK), where the organization retains independent custody of keys entirely outside the provider’s environment.
For regulated organizations with strict sovereignty requirements, BYOK may not provide sufficient protection if a foreign legal authority can compel the provider to surrender key access under some circumstances.
3. Operational Sovereignty
This covers who operates the environment and from where, including whether support personnel or third-party vendors are subject to foreign jurisdiction.
4. Jurisdictional Sovereignty
This final pillar establishes the legal framework under which services are delivered and whether there are explicit protections against extraterritorial access, such as the cross-border situations discussed in the U.S. CLOUD Act.
Each of these pillars is essential to maintain compliance. A strong data locality posture with weak operational controls can allow unexamined risk.
Where Digital Sovereignty Programs Break Down
My experiences in the field have revealed a recurring pattern: When sovereignty becomes a technical conversation, it gets too narrow, too quickly. Workshops zoom in on where data lives, teams get to work on that one question, and then they move on, leaving the other three pillars largely unexamined.
Structural problems also come into play. Digital sovereignty needs to be treated as an ongoing program with legal, technical, and operational stakeholders, not as an IT project that gets checked off as complete.
Organizations can also be led astray by a few myths. One, as we’ve discussed, is the impression that sovereignty equals residency.
Then there’s the myth of absolute sovereignty, the idea that you can achieve complete independence from all external jurisdictions and dependencies. In practice, sovereignty always involves tradeoffs between control, cost, technological velocity, and the ability to innovate.
The goal should be to strike the right balance between independence from foreign jurisdictions and the requirements of your business. It’s also important to understand that sovereignty isn’t a product you can buy, but a risk posture built from architecture, operations, contracts, certifications, and continuous auditability.
Resilience Belongs Inside the Sovereignty Boundary
Operational sovereignty is the hardest pillar to audit and the one most commonly underestimated. If your environment needed access for routine maintenance tonight, who would perform it, from which country, and under which legal jurisdiction?
Most organizations, when they work through that question for the first time, find at least one support pathway that crosses a jurisdiction boundary they hadn’t mapped.
This gap becomes most consequential during recovery. Most sovereignty programs govern primary data environments but treat backup infrastructure, restoration sequencing, and recovery point management under a separate – and often weaker – set of controls. When an incident occurs, recovery personnel may not meet jurisdictional requirements, and the sovereign architecture designed to protect data can actively complicate restoration if resilience wasn’t designed in from the start.
Commvault’s resilience operations model, ResOps™, addresses this need directly by framing recovery as an ongoing operational discipline that needs to be designed, tested, and validated inside the same sovereignty boundary as the data it protects.
Minimum Viable Sovereignty: The Right Level of Control, Not the Maximum
An absolutist approach to digital sovereignty can tax resources while unnecessarily restricting a company’s ability to meet its business goals.
A payroll system, a customer transaction database, and an internal HR tool don’t carry the same sovereignty obligations. Taking a binary approach to compliance can lead to either under-investing where it matters or over-investing beyond what’s actually required.
Minimum viable sovereignty sets a more practical target: the right controls, consistently enforced and continuously demonstrated, calibrated to what each workload actually requires across all four pillars.
Organizations have a broad range of options for how sovereign controls are delivered across their environment, each providing different controls.
How Commvault Is Addressing the Digital Sovereignty Issue
Commvault’s Geo Shield framework is designed to help organizations navigate that spectrum. Rather than offering a single sovereign SKU, Geo Shield maps to the full spectrum of deployment models:
- Regional sovereign cloud services delivered as SaaS
- Hyperscaler sovereign-launch partnerships
- Partner-operated national sovereign offerings built with local service providers
- Fully customer-controlled private sovereign environments qualifying under frameworks like FedRAMP High.
In this way, organizations can achieve a digital sovereignty posture that holds up in real-world conditions – even when an incident occurs.
Watch the Full Webinar and Get the Readiness Report
In the full webinar, available on demand, you’ll discover:
- Why digital sovereignty is more than a technology solution.
- The role of architecture and operations in sovereignty strategy.
- How governance, contracts, and auditability impact resilience.
- Why sovereignty must hold up during cyber incidents and outages.
- The importance of a holistic, risk-based approach to sovereignty.
Watch the webinar and get the full Digital Sovereignty Decoded readiness report and companion framework.
FAQs
Q: What is the difference between data residency and digital sovereignty?
A: Data residency addresses where data is physically stored. Digital sovereignty is broader: it addresses who can access data, under what legal authority, through which operational pathways, and whether it can be recovered cleanly under real conditions.
An organization can have data residing in the right country while remaining exposed to foreign jurisdiction through its support personnel, vendor access agreements, or backup infrastructure. Residency is the starting condition; sovereignty is the full posture built on top of it.
Q: What is the EU Cloud Sovereignty Framework, and why does it matter?
A: The EU Cloud Sovereignty Framework is a structured assessment tool developed by the European Commission to evaluate cloud and technology providers against sovereignty criteria during procurement processes.
It defines eight sovereignty objectives, with assurance levels ranging from zero to four for each. Only one of the eight objectives addresses data location; the rest cover operational controls, key custody, jurisdictional exposure, and recovery.
The framework represents the most comprehensive public framework for evaluating sovereignty posture and is increasingly being used as a reference by other regions and procurement bodies beyond the EU.
Q: What is the difference between BYOK and HYOK, and why does it matter for sovereignty?
A: Bring Your Own Key (BYOK) allows an organization to supply its own encryption keys, but those keys are typically managed within the provider’s platform. Hold Your Own Key (HYOK) means the organization retains independent custody of keys entirely outside the provider’s environment, including under crisis conditions or legal compulsion.
For regulated organizations with strict sovereignty requirements, BYOK may not provide sufficient protection if a foreign legal authority can compel the provider to surrender key access. The U.S. CLOUD Act, for example, can reach providers operating under U.S. jurisdiction regardless of where data is physically stored.
HYOK addresses that exposure directly, though it may require a higher platform tier in SaaS deployments.
Q: Why do most sovereignty strategies overlook operational sovereignty?
A: Operational sovereignty, covering who operates the environment and from where, is the hardest pillar to audit because it requires inventorying support contracts, vendor access agreements, and third-party dependencies across the full operational chain.
Most organizations start sovereignty programs focused on data location and encryption, which are more visible. Operational dependencies tend to surface only when explicitly audited or when an incident forces the question.
As a first step to evaluate operational sovereignty, you should identify every access pathway into your sovereign environment and the legal jurisdiction of each party with that access.
Q: How should organizations think about recovery in the context of sovereignty?
A: Recovery architecture needs to meet the same sovereignty requirements as primary data environments, but it often doesn’t. In most organizations, backup infrastructure, restoration sequencing, and recovery point management are frequently governed by a separate set of controls, or none at all.
During an incident, the personnel authorized to execute recovery may not meet jurisdictional requirements, recovery points may not have been validated as clean and uncompromised, and the sovereign architecture designed to protect data can actively complicate recovery if resilience wasn’t built into the original design. A sovereignty review should always include recovery planning.
Q: What does minimum viable sovereignty mean in practice?
A: Minimum viable sovereignty means identifying the right level of control for each workload, calibrated to actual regulatory obligations, risk tolerance, and operational constraints, rather than applying maximum controls uniformly.
Maximum sovereignty comes with real tradeoffs: technological complexity, operational burden, service limitations, and cost. Organizations that define requirements by workload across the four pillars, map those requirements to deployment models, and build evidence of consistent enforcement are in a far stronger position than those pursuing all-or-nothing approaches.
Q: What role do certifications like C5, SecNumCloud, and ISO 27001 play in a sovereignty strategy?
A: Certifications help provide auditable evidence that controls have been independently verified, an important part of any defensible sovereignty posture. C5 in Germany, SecNumCloud in France, and ISO/IEC 27001 each establish baseline requirements that providers must demonstrate through independent audits.
The strongest sovereignty postures treat these certifications as a floor, providing necessary evidence that controls exist, but not a substitute for operational testing under realistic conditions.
Darren Thomson is Vice President and Chief Technology Officer, EMEA, at Commvault. Be sure to catch him in the podcast series, STRIVE.
