Who is accountable when an access exception outlives its approver?

The owning identity governance process is accountable, because it failed to preserve the approval trail in a durable way. When approver authority changes, leaves, or expires, the organisation still needs a verifiable record of who granted the exception and under which policy. That record is what makes accountability testable.

Why This Matters for Security Teams

An access exception is only defensible when the approval can still be proven after people move roles, leave, or lose delegated authority. That is why accountability does not sit with the individual approver alone. It sits with the identity governance process that must preserve durable evidence, enforce expiry, and retain the policy basis for the exception. Without that, the organisation cannot show whether access was authorised or merely tolerated.

This problem is amplified in environments that already struggle with non-human identities and exception sprawl. NHI Management Group notes that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which shows how quickly temporary access can become unmanaged. The broader risk picture is covered in the Ultimate Guide to NHIs and its Key Challenges and Risks section.

Practitioners should also treat this as a control durability issue, not a paperwork issue. NIST’s SP 800-53 Rev. 5 makes clear that access control depends on traceable enforcement, and the OWASP Non-Human Identity Top 10 reinforces that identity evidence must survive beyond the person who approved it. In practice, many security teams discover this only after an approver departs and no one can reconstruct why the exception still exists.

How It Works in Practice

The accountable process should bind every exception to four things: the request, the approver, the policy justification, and the expiration or review date. If the approver changes, retires, or leaves, the approval record must still be verifiable and immutable enough to satisfy audit, incident response, and access review. That means the exception workflow needs durable logging, delegated approver rules, and automatic expiry rather than relying on human memory or inbox history.

Good practice is to separate authority from retention. The approver grants the exception, but the governance system owns the evidence. That evidence should include who approved, what risk was accepted, which policy clause allowed it, and when the exception must be revalidated. For NHI-heavy environments, this matters even more because service accounts and API keys often outlive the staff who created them. The same governance discipline described in the 52 NHI Breaches Analysis applies here: if the control trail is weak, access outlives intent.

• Use time-bound exceptions with a forced review date and automatic revocation or reapproval.
• Store approval evidence in a system of record, not in email threads or chat history.
• Require secondary approval when the original approver is no longer in role or on the access roster.
• Link the exception to the exact resource, identity, and compensating control that make it acceptable.
• Keep the policy rationale searchable so auditors can test the decision after personnel changes.

For operational resilience, pair this with least-privilege and periodic recertification. The organisation stays accountable because the process can still prove who authorised the exception and whether it should remain in force. These controls tend to break down in fast-moving cloud and CI/CD environments because exceptions are granted informally and never revalidated against the live access graph.

Common Variations and Edge Cases

Tighter exception controls often increase workflow friction, requiring organisations to balance speed against auditability. That tradeoff becomes visible when operations teams need urgent access during outages, merger integration, or incident response, and the original approver is unavailable. Current guidance suggests using pre-approved emergency paths with stronger logging rather than suspending accountability altogether, but there is no universal standard for this yet.

One edge case is delegated approval. If a manager authorises a delegate, the delegate may sign the exception, but the governance system still needs to retain who had authority at that moment. Another is time-boxed access for third parties or contractors, where the exception may outlive the commercial relationship unless offboarding is tied to identity lifecycle events. NHI Management Group’s broader guidance on lifecycle and visibility in the Ultimate Guide to NHIs is especially relevant when exception records must be retained across personnel turnover.

For regulated environments, align the recordkeeping standard to internal audit and retention policy, then validate it against control families such as NIST and OWASP. The practical rule is simple: if the organisation cannot prove who approved the exception, then the exception is not operationally accountable, even if it was once verbally authorised. That distinction matters most when access review failures compound into a broader breach, as highlighted in the Microsoft SAS Key Breach.

Related resources from NHI Mgmt Group

• Who is accountable when a non-human decision system helps grant privileged access?
• Who is accountable when a time-bound access model fails?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?