Why do compliance approvals not guarantee data sovereignty?

Why This Matters for Security Teams

Compliance approvals are often treated as proof of sovereignty, but they usually validate paperwork, scope, or control design rather than who can actually operate the environment. For data sovereignty, the decisive question is whether the organisation retains practical authority over platforms, keys, support channels, and privileged administration. That is why governance evidence must be operational, not just documentary, and why NIST’s NIST Cybersecurity Framework 2.0 is useful only when translated into enforceable access and oversight. NHIMG research shows this gap is common: the Ultimate Guide to NHIs notes that 92% of organisations expose NHIs to third parties, which often means operational control is distributed long before anyone asks who can really administer the system.

Security teams get caught out when an audit trail shows approval, but a vendor, cloud operator, or support workflow still has privileged paths into the environment. In practice, many teams discover sovereignty failures only after an incident, contract dispute, or regulatory review exposes who actually held the keys.

How It Works in Practice

Operational sovereignty has to be demonstrated across the full control chain: who can create, use, rotate, escrow, recover, and revoke secrets; who can access backups and support consoles; and who can override policy in emergencies. A compliance sign-off should therefore be treated as one input, not the outcome. Teams usually need to prove that sensitive data and non-human identities are governed through local authority, short-lived access, and auditable control points. The Lifecycle Processes for Managing NHIs section of NHIMG’s guide is especially relevant here because sovereignty depends on lifecycle control, not merely deployment location.

• Document the exact parties with administrative access, including cloud support, managed service providers, and subcontractors.
• Require customer-controlled keys where feasible, and define who can rotate or recover them under incident conditions.
• Separate approval of control design from proof of runtime enforcement, including privileged access logs and support escalation paths.
• Verify that offboarding, revocation, and break-glass procedures are actually enforceable, not just described in policy.

This aligns with the direction of the NIST Cybersecurity Framework 2.0, but current guidance suggests the sovereignty test is stricter: the organisation must be able to show it can independently restrict access even when another party hosts or supports the platform. These controls tend to break down in shared-responsibility cloud models because privileged support access, tenant administration, and encrypted backup recovery are often outside the customer’s direct control.

Common Variations and Edge Cases

Tighter sovereignty controls often increase operational overhead, requiring organisations to balance autonomy against vendor dependency, incident response speed, and regulatory deadlines. There is no universal standard for this yet, so the right answer depends on whether the data is regulated, exported, mirrored, or processed by third parties. Compliance may still be useful, but only as evidence that a control framework exists, not that sovereignty is complete.

One common edge case is encrypted data stored with externally managed keys: the data may remain unreadable in theory, yet the provider can still administer recovery workflows or metadata services. Another is cross-border support, where staff, ticketing systems, or maintenance tooling create access pathways that are invisible in the approval pack. NHIMG’s Top 10 NHI Issues resource is relevant because secrets, service accounts, and privileged automation are usually where control is lost first, even when the compliance evidence looks complete.

Best practice is evolving toward continuous assurance: prove who can operate, not just who signed off. For many organisations, the practical test is whether they can revoke external privileged access without waiting on the same party that hosts the system.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities for SOC 2 compliance?
• Why do non-human identities create compliance risk even when policies exist?
• When does a machine identity become a compliance problem?