Who is accountable when audit evidence shows access was not removed?

Why This Matters for Security Teams

When audit evidence shows access was not removed, the issue is rarely just a missed checkbox. It usually signals a control failure across identity lifecycle, application ownership, and governance oversight. For NHIs, that matters because service accounts, API keys, and workloads often persist long after the business need ends, and revocation gaps can remain invisible until an audit, incident, or vendor review exposes them. NHI Mgmt Group notes that only 20% of organisations have formal offboarding and revocation processes for API keys, which makes access removal a recurring weak point in practice.

This is why accountability cannot stop at the technician who clicked the wrong button or the admin who forgot a ticket. The question is whether ownership was defined, whether removal was actually enforced, and whether evidence proves the control worked. That framing aligns with the NIST Cybersecurity Framework 2.0 and NHI governance guidance in Ultimate Guide to NHIs — Regulatory and Audit Perspectives. In practice, many security teams discover revocation failure only after audit evidence is requested, not through intentional monitoring.

How It Works in Practice

Accountability for failed access removal is best treated as shared but not vague. The identity owner is typically responsible for the lifecycle of the account or secret, the application owner is responsible for ensuring the access no longer functions in the system, and the governance or control owner is responsible for proving the process works consistently. A clean audit trail should show who approved removal, when it was executed, what systems were updated, and what validation confirmed the access is no longer usable.

For NHIs, evidence should extend beyond ticket closure. Good practice is to verify that credentials were revoked, tokens were invalidated, certificates were retired, and downstream entitlements were removed from connected tools, pipelines, and vaults. That matters because revocation is often multi-step. The OWASP Non-Human Identity Top 10 highlights how weak lifecycle controls and excessive privilege combine to keep access alive after intended decommissioning.

NHI Mgmt Group’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs reinforces that offboarding must be repeatable, not ad hoc. In operational terms, teams should define:

• one accountable owner for each NHI and its secrets
• a documented revocation workflow with approval and execution steps
• validation checks that confirm access is actually gone
• exception handling when removal fails because of dependencies or legacy integrations

These controls tend to break down when access is embedded in legacy scripts, CI/CD pipelines, or third-party integrations because the revocation action is incomplete even though the ticket is closed.

Common Variations and Edge Cases

Tighter revocation control often increases operational overhead, requiring organisations to balance fast deprovisioning against the risk of breaking production dependencies. That tradeoff is especially visible when the access in question belongs to a shared service account, an inherited integration, or a third-party platform that does not support immediate removal.

Current guidance suggests the accountable party should still be named even when the technical work is distributed. For example, if an app team owns the workload but IAM runs the execution step, the app owner remains accountable for ensuring the access should be removed, while IAM is responsible for carrying out the task and preserving evidence. Where there is no universal standard for shared-service ownership, best practice is to document the decision path and the fallback approver in advance.

The hardest cases are “zombie” NHIs, where access persists because nobody can confirm all places it exists. NHI Mgmt Group’s Ultimate Guide to NHIs — Key Challenges and Risks shows why visibility gaps make accountability hard to prove. In those cases, the accountable party is the one designated to own the control outcome, not merely the person who discovered the gap.

Related resources from NHI Mgmt Group

• How should security teams reduce SaaS access review overhead without losing audit evidence?
• What breaks when access reviews do not produce audit evidence for CMMC?
• How should organisations automate GDPR access reviews without losing audit evidence?
• Who is accountable for SaaS compliance evidence when audit logs are incomplete?