# User Access Reviews: From Certification to Verified Removal

Canonical: https://www.governatlas.com/guides/user-access-review
Author: GovernAtlas editorial
Published: 2026-10-18

Original editorial recommendations. Model-assisted research with primary-reference review. Not a certification, legal determination, product ranking or claim of performed testing. Company payment does not influence editorial findings.

A practical user access review method: define the campaign, assign accountable reviewers, handle service accounts and exceptions, and trace revocations to the enforcing system. Includes a private, downloadable decision-to-enforcement record.

## When a reviewer says revoke, what actually changes?

A completed access certification records a decision. It does not, by itself, prove that the application removed a permission or ended an existing session. Keep population, decision, fulfillment and observed access as separate evidence, then reconcile them before closing the review.

## What is a user access review—and when is it useful?

A user access review asks an accountable person whether an identity should retain a defined permission. The identity may be an employee, contractor, service account or agent; the permission may be a group membership, application role or entitlement on a particular resource. Certification is the recorded decision. Remediation is the work that follows a change or removal decision. Those records should be connected, but they answer different questions.

Use a review when the business needs to reassess access that is already present: a role changes, a contractor engagement ends, a sensitive application changes owner or a scheduled control requires re-examination. Do not invent a universal quarterly cadence. Set timing from the organization’s obligations, sensitivity and change rate, and name the person responsible for that policy. A periodic review also needs event-driven handling for departures and urgent risk; waiting for the next campaign is an operating decision with consequences.

An identity provider, an IGA platform, a privileged-access broker and an application authorization service can contribute different parts of this process. Buying a second tool is not always the first step. If the immediate problem is an unowned source, an unclear policy or a manual ticket that nobody closes, define that gap before comparing dashboards. Our linked product dossiers describe documented scope, not a ranking or certification of these approaches.


## Build a population you can reconcile

Start with one application and a dated manifest of accounts and entitlements. Record the collection source, last successful synchronization, stable account identifier and whether the permission is direct, inherited or role-derived. Compare the manifest with a native application export or another authorized reference. A campaign can look complete while excluding a resource, collecting stale data or reviewing directory groups instead of application-level permissions.

Keep unmatched and duplicate accounts visible. Do not automatically assign a shared account to the employee with the closest name. A service account needs an accountable owner and a purpose, while a contractor may need a sponsor and engagement end date. An agent identity may also require a bounded task and a relationship to the person who authorized it. Missing ownership is work to resolve, not a reason to remove the item from the denominator.

Write down exclusions before launching the campaign. Separate an intentional exclusion from a failed collection or unsupported permission type. The SailPoint documentation, for example, distinguishes certifiable access from other access data; its migration and phased-availability notes also make tenant and engine context material. This is an implementation-specific example, not a claim that all products share the same boundary.

- Application, resource, edition and collection time
- Stable identity/account/entitlement relationships
- Direct and inherited permission paths
- Known exclusions, failed sources and ownership gaps

## Assign reviewers who can explain the decision

Choose the reviewer because they can judge the business need, not because they happen to receive the notification. An application owner may understand a technical role while a manager understands the person’s duties; some decisions need both. Set fallback ownership for inactive or missing reviewers. Define what happens when the proposed reviewer is also the subject of the review, and test the configured behavior rather than assuming every platform prevents self-review.

Zluri’s configuration guide explicitly describes primary and fallback reviewers and configurable self-review handling. That is useful evidence of a decision the buyer must make. It does not establish which option a particular deployment has enabled. In a trial, seed an inactive owner, a missing owner and a self-review case, then preserve the actual assignment and escalation trace.

Give the reviewer enough context to disagree with a recommendation: the permission’s meaning, the owner, collection time, relevant usage period and known exceptions. A missing last-used event is not proof that access was never needed. An AI recommendation is an input to the decision; retain the signals, the reviewer’s rationale and any disagreement. Do not turn a confidence indicator into an automatic business authorization without an approved policy.


## Keep retain, remove, change and exception distinct

Record the selected entitlement and a decision reason that another reviewer can interpret. ‘Retain’ means the reviewer has accepted the defined access under the stated policy; it does not certify every permission the account might acquire through another path. ‘Change’ should identify the replacement scope. ‘Remove’ starts a fulfillment obligation. An exception needs an owner, rationale, expiry or review trigger and a record of what access remains possible.

Avoid replacing the original decision when an exception is approved later. Preserve both events and the authority for the change. If an owner cannot decide because evidence is stale, the status should remain unresolved. Silence, a reminder deadline or campaign closure should not silently become evidence that access was appropriate. Confirm timeout and automatic-decision behavior in the selected configuration.

For a synthetic pilot, include one justified retained entitlement, one revoked entitlement, one reduced permission and one unresolved item. Ask a second reviewer to reconstruct the decisions from the export alone. If the explanation depends on a presenter narrating an undocumented rule, the record is not yet a useful handover artifact.


## Trace removal past the ticket and into the target

Record at least four milestones separately: the review decision, the fulfillment request, the target’s acknowledgment and an authorized observation of effective access. A successful API response may mean that a job was accepted rather than completed. A closed ITSM ticket may document an operator’s action without showing the resulting permission. The target observation is what connects the intended change to the operation the organization needs to control.

Use a disposable account and synthetic resource. Observe a permitted operation before removal, then attempt the same bounded operation afterward. Compare a new session with an existing session or issued token, because membership removal and session termination need not have identical semantics. Record timestamps and the policy’s permitted propagation window; do not promise instant revocation unless the configuration and actual evidence support that specific statement.

Include an inherited grant or an alternate authorized path. Removing a direct role does not settle whether a nested group, second role or shared credential still grants access. Keep the original observation, explain the remaining path and assign a follow-up owner. For detailed operation-level checks, use our data-access-governance guide and access matrix alongside the review record below.


## Rehearse the incomplete review

In a sandbox, interrupt a connector after a removal decision. Inspect how the system represents an accepted request, failed change, retry and unresolved permission. Define who responds and whether the campaign can close with remediation outstanding. Retry handling should preserve the original decision and avoid turning duplicate jobs into apparently separate successful removals.

For a disconnected application, retain the manual fulfillment path explicitly. SecurEnds’ documentation describes connectors, APIs, ITSM, tickets and other integration paths; those are different ways to route work, not interchangeable proof of automated enforcement. Ask which path the proposal uses for each application, what credentials it requires and what evidence the operator must attach before closure.

Test a late-arriving entitlement after the campaign snapshot. Decide whether it belongs in a delta review, a later campaign or an urgent event workflow. Preserve the snapshot and the later change rather than editing history to make the original population appear complete. The same principle applies to an owner change or a new role hierarchy during a long campaign.


## Close with an evidence packet and a bounded conclusion

Reconcile the campaign population with decisions and follow-up actions. Explain exclusions, unresolved ownership, exceptions and remediation that is still open. A percentage completed is useful only when its unit and denominator are defined: accounts reviewed, entitlements decided and removals confirmed are different counts. Keep them separate instead of compressing them into one green status.

Retain source and snapshot identifiers, reviewer authority, decision rationale, fulfillment references, target observations and the time of each material event. Store sensitive evidence in your approved system and put only non-sensitive references in the worksheet. The tool below keeps entries in this open page, offers a plain-text download and clears them on reset or reload. It neither connects to your applications nor verifies that a removal succeeded.

Finish with a conclusion limited to the tested population, application, release and observation window. Name the next review trigger and the owner of every remaining gap. An auditor or control owner may require additional evidence; this editorial method does not determine legal compliance or audit acceptance. The practical outcome is an explainable chain from business intent to observed access, including where that chain remains incomplete.


## Primary references and scope

- [SailPoint — Certifications Overview](https://documentation.sailpoint.com/saas/help/certs/index.html): Campaign stages, certifiable access and legacy/new-engine boundaries. Tenant applicability must be checked.

- [Zluri — Setting Up Access Reviews](https://help.zluri.com/docs/setting-up-access-reviews-in-zluri): Reviewer roles, fallback assignment and configurable self-review handling; not a statement about a particular deployment.

- [SecurEnds — Identity Governance and Administration](https://www.securends.com/identity-governance-administration-iga/): Documented collection, correlation, fulfillment and evidence workflow. No independent outcome or completeness finding.

- [C1 — Identity Governance](https://www.c1.ai/products/iga): Documented lifecycle, review and remediation scope. The proposed tests and worksheet are original GovernAtlas methods.

Interactive worksheets on the canonical HTML page are user-entered tools, not observed product test results. They are not reproduced here as research findings.

Suggested citation: GovernAtlas editorial. User Access Reviews: From Certification to Verified Removal. 2026-10-18. https://www.governatlas.com/guides/user-access-review

Corrections: https://www.governatlas.com/corrections
Methodology: https://www.governatlas.com/methodology