Notifications
Clear all
Topic starter
14/08/2026 6:32 pm
TL;DR: Digital sovereignty has no universal definition and should start with the business problem, risk appetite, and operating constraints, according to Commvault’s STRIVE conversation with Microsoft’s Thomas Maurer. The analyst takeaway is that sovereignty decisions become stronger when architecture, legal, compliance, and resilience are aligned before technology choices are made.
NHIMG editorial — based on content published by Commvault: STRIVE episode on digital sovereignty and practical architecture decisions
By the numbers:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.
Questions worth separating out
Q: How should organisations start digital sovereignty planning?
A: Start by defining the business problem and the risk scenario you are trying to solve.
Q: Why does digital sovereignty matter to IAM teams?
A: Because sovereignty depends on who can exercise control over systems, data, and recovery actions.
Q: What do security teams get wrong about cloud and on-premises choices?
A: They often treat the decision as a binary technology preference instead of a risk-based design question.
Practitioner guidance
- Define sovereignty scenarios before architecture decisions Capture the specific drivers for the programme, such as residency, regulatory scope, operational independence, or geopolitical resilience, then map each to a control objective before evaluating platforms.
- Map identity controls across hybrid environments Review how privileged access, service accounts, break-glass access, and audit logging behave when workloads move between cloud and on-premises estates, then remove environment-specific exceptions.
- Align legal, security, and operations on one control model Create a shared sovereignty decision record that ties contractual obligations, incident recovery, and access governance to the same risk assumptions, so teams do not work from conflicting definitions.
What's in the full article
Commvault's full episode covers the operational detail this post intentionally leaves for the source:
- The live discussion on how sovereignty definitions change by organisation, industry, and risk appetite.
- The practical trade-offs between public cloud, private cloud, and on-premises deployment models.
- The role of legal, compliance, and security teams in making sovereignty decisions work in practice.
- The broader STRIVE conversation on resilience, business continuity, and risk-led architecture choices.
👉 Watch Commvault's STRIVE episode on digital sovereignty and hybrid cloud decisions →
Digital sovereignty and hybrid design: what should leaders ask first?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
14/08/2026 6:38 pm
Sovereignty is really a control-boundary problem. The article’s central point is that digital sovereignty cannot be reduced to provider selection because the real question is who can assert control, where, and under what conditions. That makes it a governance discipline as much as an infrastructure one, especially when identity, legal jurisdiction, and operational resilience intersect. Practitioners should treat sovereignty as a boundary-setting exercise, not a procurement outcome.
A question worth separating out:
Q: Who should be accountable when sovereignty decisions create legal exposure?
A: Accountability should sit with the owners of identity, cloud operations, legal risk, and vendor governance together. Sovereignty is cross-functional because access authority, recovery rights, and jurisdiction all intersect. If responsibility is split across teams without one governed decision record, the posture will remain ambiguous.
👉 Read our full editorial: Digital sovereignty is a risk problem, not a cloud choice
