TL;DR: Quarterly access review execution is often harder than policy design, because teams still need to map reviewers, handle self-review conflicts, track sign-off, and produce audit evidence across a 17 to 21 day cycle, according to Zluri. The governance risk is not the certification itself but the operational gap between documented intent and repeatable execution.
At a glance
What this is: This is a step-by-step guide to running quarterly access reviews, with emphasis on certification setup, reviewer assignment, sign-off, remediation, and audit evidence.
Why it matters: It matters because IAM programmes fail when access review policy cannot be executed consistently across applications, reviewers, and remediation workflows.
👉 Read Zluri's step-by-step guide to quarterly access review execution
Context
Quarterly access reviews are a governance control, but they only work when reviewer assignment, remediation, and evidence capture are operationally repeatable. The guide shows how a certification cycle moves from launch to sign-off and audit handoff, which is the part many IAM teams underestimate when they rely on policy alone.
For IAM, IGA, and PAM teams, the practical challenge is not whether access reviews should exist. It is whether the organisation can keep the process deterministic across applications, self-review conflicts, delegation, and remediation failures without turning each quarter into a manual project.
Key questions
Q: How should teams run quarterly access reviews without turning them into manual projects?
A: Treat quarterly access reviews as a repeatable control workflow, not a one-off audit task. Define reviewer ownership, set fallback paths, test remediation playbooks, and monitor sign-off separately from review completion. The review is only effective when decisions, entitlement changes, and evidence capture all complete inside the same governance cycle.
Q: Why do access reviews often fail even when the policy is documented?
A: Documented policy fails when identity ownership data, reviewer assignments, or remediation integrations are incomplete. A certification can launch successfully while still depending on missing app owners, broken playbooks, or manual sign-off chasing. The weak point is usually execution fidelity, not the written policy.
Q: What signals show that access review governance is not working?
A: Look for incomplete sign-offs, repeated fallback reviewer use, remediation failures, and certifications that finish as reports rather than entitlement changes. If reviewers complete decisions but the access state does not change, the control is producing documentation instead of enforcement.
Q: Who should be accountable when an access review stalls or misses remediation?
A: Accountability should sit with the certification owner for workflow completion, with application and identity owners for accurate reviewer mapping, and with operations teams for remediation execution. If any of those roles are undefined, the review process will drift into exception handling instead of controlled governance.
Technical breakdown
Certification setup and reviewer mapping
A certification is the container for an access review cycle: it defines scope, assigns reviewers, and sets the timing for review and remediation. The operational risk starts before review work begins, because reviewer identity must be deterministic. Role-based reviewers, named fallbacks, and multi-level sequencing all depend on clean ownership data in the directory, HRMS, or app metadata. If app owner or manager data is missing, the certification can still launch, but the governance model becomes fragile and exceptions accumulate quickly.
Practical implication: validate ownership and fallback mappings before launch so the certification does not depend on ad hoc manual intervention.
Self-review, delegation, and sign-off mechanics
Access review tools usually separate decision-making from completion status. A reviewer can approve or revoke records and still fail to sign off, which leaves the certification incomplete even when the visible work looks done. Self-review handling adds another control layer, because allowing a person to review their own access undermines separation of duties. Delegation only works if the pending record can be reassigned without breaking the chain of accountability, which means the process needs explicit controls for reassignment targets and completion states.
Practical implication: enforce auto-reassign or other separation-of-duties handling and monitor completed-but-not-signed-off reviews as a distinct failure state.
Remediation playbooks and audit evidence
Review decisions only matter if they trigger the right remediation action. Playbooks convert a revoke or modify decision into a deprovisioning, ticketing, or permission-change workflow, and that is where integration readiness becomes essential. API-based remediation can fail because of permissions, rate limits, disconnected integrations, or unpublished playbooks. Evidence generation is the final control output: auditors need to see what was reviewed, who approved it, what changed, and whether the process completed on schedule.
Practical implication: test playbook execution and evidence export before the quarter closes so remediation failures do not become audit gaps.
NHI Mgmt Group analysis
Quarterly access review failure is usually an execution problem, not a policy problem. The guide makes clear that organisations can document the certification process and still fail at the operational layer if reviewer ownership, fallback logic, or sign-off handling is inconsistent. That is a classic IGA weakness: control intent exists, but the workflow does not survive day-to-day exceptions. Practitioners should treat access review execution as a governed process with measurable failure states, not as an annual compliance ritual.
Identity review quality depends on upstream identity data, not just reviewer discipline. When app owner, manager, or department data is missing, the certification still needs to route somewhere, and the fallback path becomes the real control. That means access review accuracy is constrained by directory hygiene, HRMS fidelity, and application metadata quality. In practice, reviewer process maturity cannot outrun poor identity ownership data, which is why lifecycle governance and access certification must be managed together.
Remediation is the point where access review becomes a control, not a report. A review that ends in approved decisions but broken playbooks, failed API actions, or incomplete remediation is only documentation. The guide shows that evidence, action, and completion status are all part of the same governance chain. Practitioners should judge access review maturity by whether decisions actually change entitlement state inside the same quarter.
Access review drift: the recurring gap between documented certification policy and the messy operational reality of reviewer assignment, sign-off, and remediation. This guide demonstrates that drift appears when teams assume the process will run itself once the workflow is configured. The implication is that access reviews need ongoing governance, not just a quarterly calendar reminder.
Quarterly certifications expose whether IGA is integrated or merely configured. If the organisation can launch a review but cannot reliably revoke, modify, or evidence outcomes, the control is not operationally complete. That distinction matters for audit, but it also matters for security because stale access survives wherever remediation is manual or inconsistent. Practitioners should use certification completion rates and remediation success as a maturity signal, not just a compliance checkbox.
From our research:
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which shows why review quality depends on upstream identity data, not just reviewer discipline.
- NHI Lifecycle Management Guide is the next resource to use when review findings need to feed into provisioning, rotation, and offboarding control design.
What this signals
Access review drift: quarterly certifications only improve governance when reviewer routing, sign-off, and remediation are measured as operational outcomes rather than assumed because a workflow exists. Teams should expect exceptions whenever ownership data is incomplete or remediation depends on fragile integrations.
The practical signal is whether the organisation can close the loop between certification decisions and entitlement change without manual stitching. If that loop breaks, the access review becomes a compliance artefact instead of a control, and the next quarter starts with the same stale access still in place.
For practitioners
- Validate reviewer ownership before each certification Check that app owners, reporting managers, and fallback reviewers are present and correct before launching the review. Missing ownership data creates routing exceptions that turn a governed workflow into a manual chase.
- Enforce separation of duties on self-review records Use auto-reassign or a named alternate reviewer when the assigned reviewer would be certifying their own access. Self-review should be treated as an exception that requires explicit policy handling, not a default convenience.
- Track sign-off as a separate completion state Monitor records that are fully reviewed but not signed off, because those certifications are still open even when the visible work appears done. Use targeted reminders and force sign-off only when all actions are already complete.
- Test remediation playbooks before the quarter closes Confirm that revoke and modify actions work through the connected integrations, including API permissions and fallback ticketing. If playbooks fail late, the review ends as evidence without enforcement.
- Archive evidence with the certification outcome Keep the decision record, remediation status, and export package together so auditors can see what changed and when. Evidence is strongest when it ties the reviewer action to the entitlement change.
Key takeaways
- Quarterly access reviews fail most often at execution boundaries, where reviewer ownership, sign-off, and remediation must work together.
- The article shows that a certification can look complete while still leaving access unchanged if sign-off or playbook execution fails.
- IAM teams should treat access review quality as an operational control metric, not just an audit schedule requirement.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01 | Access review execution depends on accurate identity and access accountability. |
| NIST Zero Trust (SP 800-207) | N/A | Quarterly reviews support continuous verification of access decisions. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Remediation failures and stale access are classic non-human identity governance gaps. |
Map certification ownership and evidence to PR.AA-01 and verify review completion each cycle.
Key terms
- Certification: A certification is a governed access review instance that asks assigned reviewers to validate whether existing access should remain, change, or be removed. In practice, it is the control wrapper around reviewer assignment, decision recording, remediation, and evidence capture for a defined scope of users, groups, or applications.
- Sign-Off: Sign-off is the explicit completion action that closes a reviewer’s responsibility for a certification. It is not the same as finishing individual decisions. Without sign-off, the process can appear complete while remaining open in governance terms, which is why many access review failures are really completion-state failures.
- Remediation Playbook: A remediation playbook is the predefined action path that turns a review decision into an operational change, such as revoking access, modifying permissions, or opening a ticket. It is the mechanism that converts governance intent into entitlement state change, usually through integrations or manual tasks when automation fails.
- Fallback Reviewer: A fallback reviewer is the named person who receives a certification task when the primary reviewer cannot be resolved or should not review the record. It protects the process from missing ownership data, but it also becomes a governance signal when fallback routing happens too often, because that indicates upstream identity metadata is weak.
What's in the full article
Zluri's full guide covers the operational detail this post intentionally leaves for the source:
- Exact click-paths for each certification step, including setup, launch, and completion.
- Reviewer-view screenshots and field-by-field configuration details for applications, scopes, and columns.
- Remediation playbook setup examples for revoke and modify actions across integrated applications.
- Error-handling notes for incomplete reviews, failed playbooks, and evidence generation.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on 2026-03-10.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org