Who is accountable when inappropriate access survives a quarterly review?

Why This Matters for Security Teams

A quarterly access review can confirm that a list was checked, but it does not by itself prove that inappropriate access was removed. That distinction matters because control ownership is fragmented across IAM, IGA, HRIS, and application teams, and each layer can fail independently. NHI Management Group notes that 91.6% of secrets remain valid five days after notification, which shows how often remediation lags behind detection in real environments. See the Ultimate Guide to NHIs for the broader lifecycle context.

The practical issue is accountability. Reviewers can flag risk, but only a designated control owner can ensure revocation, entitlement correction, and root-cause cleanup happen. That is especially true for non-human identities, where access often lives in code, vaults, CI/CD pipelines, and application configuration rather than in one human-readable system. The OWASP Non-Human Identity Top 10 frames these gaps as an identity governance problem, not just a periodic certification problem. In practice, many security teams discover failed revocation only after an audit exception, incident, or unexpected production access reveals that review completion did not equal access removal.

How It Works in Practice

Accountability should be mapped to the control that can actually change the access state. In a healthy model, the reviewer validates evidence, but the IAM or IGA owner executes the entitlement change, the application owner fixes local authorization logic, and the HRIS or source-of-truth owner corrects upstream identity data so the issue does not recur. For NHIs, that chain often includes secrets managers, workload identity, and token issuance services, which means the revocation path must cover more than a single directory record. The 52 NHI Breaches Analysis is useful because it shows how control failures cascade when ownership is unclear.

Operationally, the best pattern is a closed-loop workflow:

• Reviewer records the exception and classifies the risk.
• Control owner receives a ticket with a required remediation due date.
• IAM, IGA, or application owner removes the access and verifies the target state.
• Evidence of revocation is attached to the case, not assumed from the review result.
• Root cause is routed to the system that created the bad entitlement in the first place.

That model aligns with governance guidance from NIST’s AI Risk Management Framework, which emphasizes accountable operational ownership rather than ceremonial review. It also fits NHI realities described in the Ultimate Guide to NHIs, where visibility gaps and excessive privileges make remediation dependent on clear ownership. These controls tend to break down in organisations where entitlement data is split across multiple systems and no single owner can verify end-to-end revocation.

Common Variations and Edge Cases

Tighter accountability often increases operational overhead, requiring organisations to balance clean ownership against review speed and ticket volume. In mature programs, that tradeoff is accepted because a fast review with no remediation is not governance, but the balance shifts when thousands of accounts or service principals are in scope.

There is no universal standard for this yet, but current guidance suggests assigning a primary owner for each access decision and a separate execution owner for each removal action. That matters when the reviewer is a manager, the system of record is HRIS, and the actual access sits in an application team’s local ACL. The manager can attest, but they cannot be accountable for a vault rotation they do not control. Likewise, for NHIs, a quarterly review may surface a stale API key, while the real fix is to rotate the secret, update the workload identity, and revoke downstream tokens.

Edge cases usually appear when ownership is shared, outsourced, or automated. In those environments, accountability should be written into the service model, with explicit remediation SLAs and escalation paths. If a review exception cannot be assigned to one named control owner, the organisation has a governance gap, not just a staffing issue.

Related resources from NHI Mgmt Group

• When should organizations review access controls?
• What breaks when an AI review system has write access to repositories and pipelines?
• Who is accountable when forged session data bypasses application access controls?
• Who should be accountable when an AI agent or service account causes access drift?