Notifications
Clear all
Topic starter
11/08/2026 3:15 pm
TL;DR: Digital sovereignty has moved from a compliance question to a business continuity issue because location alone does not address jurisdiction, operations, or hidden dependencies, according to Commvault’s discussion with Osmium Data Group’s Max Mortillaro. The real test is whether organisations can keep critical services running when legal, geopolitical, or third-party assumptions change.
NHIMG editorial — based on content published by Commvault: Digital sovereignty is becoming a resilience problem, not just compliance
By the numbers:
- Only 44% of organisations are currently using a dedicated secrets management system.
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities.
Questions worth separating out
Q: How should security teams govern digital sovereignty beyond data residency?
A: Security teams should govern sovereignty as an access and jurisdiction model, not only as a location model.
Q: Why do identity and privileged access matter in sovereignty programmes?
A: Because identity is often the mechanism through which external influence enters or exits a service.
Q: What do organisations get wrong when building sovereign cloud strategies?
A: They often start with infrastructure choices before defining the business problem they need to solve.
Practitioner guidance
- Map control paths, not just data locations Document every administrative and support identity that can influence a sovereign service, including vendor support, cloud operators, and internal privileged accounts.
- Review cross-border identity dependencies Identify any service accounts, tokens, certificates, or delegated access paths that traverse jurisdictions or rely on external management planes.
- Test continuity under access restriction Run scenario tests for regulatory, geopolitical, or vendor access disruption and confirm which critical services still function.
What's in the full article
Commvault's full discussion covers the operational detail this post intentionally leaves for the source:
- The full conversation on how sovereignty changes board-level risk framing and programme ownership.
- The discussion of hidden dependencies such as management systems, telemetry services, and operational controls that sit outside the apparent local environment.
- The practical trade-offs organisations must balance between risk reduction, cost, regulatory pressure, and continuity requirements.
- The episode's commentary on why organisations often start with technology choices before defining the business problem they need to solve.
👉 Watch Commvault's discussion on digital sovereignty and business continuity →
Digital sovereignty and resilience: what security teams are missing?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
11/08/2026 3:28 pm
Digital sovereignty is now an identity governance problem as much as a data governance problem. The article shows that location alone does not define control, because access, administration, and dependency chains determine whether an organisation can actually exercise sovereignty. For IAM and PAM teams, that means sovereign architecture must include who can authenticate, who can elevate privilege, and where those identities are governed. The practitioner conclusion is clear: sovereignty fails when identity control is outsourced without visibility.
A question worth separating out:
Q: Who is accountable when sovereignty controls fail during disruption?
A: Accountability should sit with the business owner of the critical service, supported by security, legal, and infrastructure teams. Sovereignty failures are usually cross-functional because they involve jurisdiction, access control, and operational continuity. If the programme does not assign ownership for those decisions, it becomes impossible to prove control when pressure increases.
👉 Read our full editorial: Digital sovereignty is becoming a resilience problem, not just compliance
