Who is accountable for identity governance when organisations shift production, suppliers, and workloads in response to disruption?

Accountability sits with the organisation, not the disruption. Security, IAM, and governance teams must define access policies, approve exceptions, monitor privileged use, and ensure access is removed when business conditions change. In volatile operating models, unclear ownership leads to persistent access risk, poor auditability, and weaker control over third-party and internal identities.

Why This Matters for Security Teams

When organisations shift production, suppliers, and workloads during disruption, identity governance becomes a change-management problem as much as an access problem. Accountability cannot move with the event or the vendor; it has to stay anchored to clear internal control ownership, approval authority, and evidence. That matters because temporary exceptions often become permanent, especially when business continuity pressure outruns review cycles. The NIST Cybersecurity Framework 2.0 treats governance and risk ownership as core security functions, not afterthoughts.

NHIMG research shows why this is not theoretical. In Ultimate Guide to NHIs — Regulatory and Audit Perspectives, identity governance is framed as a lifecycle discipline, not a one-time approval. That is especially important when machine identities, supplier accounts, and emergency access all expand at once. In the SailPoint report The Critical Gaps in Machine Identity Management report, 59% of companies said auditing machine identities is harder because of unclear ownership and limited visibility. In practice, many security teams encounter access sprawl only after an outage, supplier change, or recovery effort has already created it.

How It Works in Practice

Accountability should be assigned before disruption occurs, not after a supplier swap or workload move is underway. The security owner defines policy, the IAM or PAM team enforces it, the business owner accepts the access need, and the risk or governance function signs off on exceptions. For non-human identities, that means every service account, API token, certificate, and workload credential should have an owner, a purpose, a review date, and a revocation path. NHIMG’s Lifecycle Processes for Managing NHIs emphasises that this lifecycle view is what turns access from a static entitlement into a governed control.

In volatile operations, the practical model is:

• Document who approves emergency access, third-party access, and workload migration access.
• Use short-lived credentials where possible, with revocation tied to the end of the change window or task.
• Track ownership for human and machine identities in the same governance register.
• Require periodic recertification of access that was granted for continuity, recovery, or supplier substitution.
• Log who accepted residual risk when standard controls were bypassed.

For workload identity, cryptographic proof matters more than password-style administration. The SPIFFE workload identity specification is useful here because it treats workloads as first-class identities that can be issued and verified at runtime. That aligns with the NHIMG Guide to SPIFFE and SPIRE, which helps practitioners separate identity proof from long-lived secrets. These controls tend to break down when emergency change processes bypass normal ownership records because no single team can later prove who authorised what.

Common Variations and Edge Cases

Tighter governance often increases operational overhead, requiring organisations to balance continuity speed against auditability and removal discipline. That tradeoff becomes sharper when suppliers are partially trusted, production is shared across entities, or workloads move between cloud and on-prem environments during an incident. Current guidance suggests the accountable party should remain the organisation that benefits from the access, even if a contractor or platform team executes the change.

There is no universal standard for every edge case yet, but the direction of travel is clear: use least privilege, ephemeral access, and explicit exception ownership. NHIMG’s Top 10 NHI Issues and The Critical Gaps in Machine Identity Management report both point to the same operational weakness: unclear ownership causes poor visibility, and poor visibility delays revocation. In supplier-heavy environments, the right answer is not shared accountability in the abstract, but named accountability for approvals, monitoring, and removal, with escalation defined when a supplier cannot meet the required control. When those boundaries are unclear, access persists long after the disruption has passed.

Related resources from NHI Mgmt Group

• Why is it important to integrate identity and data governance?
• Should organisations prioritise external exposure or internal credential governance first?
• Should organisations delay production AI agents until identity governance is mature?
• Who is accountable when breach response depends on identity governance?