Who should be accountable for recurring access reviews when access changes are approved?

Accountability should sit with the business owner or access owner who understands whether the access is still needed. Security can operate the process and enforce deadlines, but reviewers must have enough context to approve, reject, or escalate decisions. That separation keeps governance practical and auditable.

Why This Matters for Security Teams

recurring access review are only useful if the person approving or revoking access can judge business need, not just technical possibility. When approval authority is blurred, access tends to accumulate, exceptions get normalized, and reviewers sign off on accounts they do not understand. That is especially risky for non-human identities, where the real failure mode is usually not a missed checkbox but a credential or entitlement that quietly outlives its purpose.

NHIMG research shows how quickly that drift becomes operational debt: Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. For review programs, that means the accountability model must be tied to ownership of the workload, data, or business process, not to the team merely enforcing the workflow. Security can coordinate the cadence, evidence, and escalation path, but it cannot reliably decide whether access is still needed without context.

That separation also aligns with control guidance in the OWASP Non-Human Identity Top 10 and the review discipline expected in NIST SP 800-53 Rev 5 Security and Privacy Controls. In practice, many security teams discover broken accountability only after stale access has already been used to reach systems no reviewer still actively owns.

How It Works in Practice

The practical model is simple: the business owner or access owner is accountable for the decision, while security or IAM operations is accountable for running the process. That means security triggers the review, tracks overdue responses, records evidence, and enforces escalation. The owner of the application, data set, automation, or service account decides whether the access remains justified, should be reduced, or should be removed.

For non-human identities, this often requires a more specific ownership chain than human user access. A service account should map to a named system owner, not a platform queue. An API key should map to the team that depends on the integration, not just the team that created the secret. A recurring access review works best when the reviewer can answer four questions at runtime:

• What workload or process uses this identity?
• Who is the accountable business or technical owner?
• What changed since the last approval?
• Does the current privilege still match the operational need?

Current guidance suggests combining ownership with evidence, such as recent usage logs, ticket history, change records, and rotation timestamps. That is consistent with the NHI Lifecycle Management Guide, because approvals are only defensible when they reflect the full lifecycle of the identity, including creation, use, rotation, and offboarding. Where possible, teams should align this with least privilege and periodic attestations rather than broad blanket approvals. The review record should show who made the decision, what they knew, and when they last confirmed the need for access.

This model becomes harder when ownership is fragmented across outsourced operations, shared platform teams, or machine-to-machine integrations with no clear service owner, because accountability then gets diluted across multiple approvers and no one can confidently sign off.

Common Variations and Edge Cases

Tighter accountability often increases review overhead, requiring organisations to balance decision quality against the speed of recurring attestation. That tradeoff is real: a simple delegated approval matrix may be efficient, but it can also hide the fact that the person signing off does not know whether access is still justified.

There is no universal standard for this yet, but current practice is to keep accountability with the party closest to the business need and let security own the control mechanics. In regulated environments, a separate control owner may be added for evidence retention, while the business owner remains the approver of record. For highly automated environments, especially those with secrets, service accounts, and API keys, the review should be paired with rotation and revocation workflows so that an approved change does not leave obsolete credentials active. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks highlights how visibility gaps and excessive privilege compound when ownership is vague.

Edge cases include temporary project access, emergency elevation, and third-party managed identities. In those situations, the reviewer should be the party with enough context to answer whether the access still serves a defined operational purpose, while security retains the authority to remove unreviewed access. That approach matches the intent of the OWASP Non-Human Identity Top 10 and the control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls, where ownership, periodic review, and timely removal all have to work together.

Related resources from NHI Mgmt Group

• What breaks when ITGC access reviews are not tied to role and responsibility changes?
• Who should be accountable for user access reviews in a regulated environment?
• Who is accountable when SSO access reviews and audit logs are not maintained?
• Who is accountable when an approved AI application keeps access after the original business need has changed?