The Access Review Your Auditor Cannot Rely On

By Author: Soham Biswas
Total Articles: 49
Comment this article

The quarterly access certification campaign closed on schedule. Every item on the list received a decision. The completion rate was 100%. The records are filed.

Then the auditor asks a follow-up question.

For the entitlements that were certified last quarter, can you show me what information the reviewer had when they made the decision? Can you show me which of the certified items carried an active SoD conflict at the time of review? For the access that was marked for revocation, can you show me when it was removed from the connected system?

In most organizations, these questions cannot be answered from the certification record. The completion rate is well-documented. The evidence that the review was meaningful is not there, because the process was not designed to produce it.

This is the most consistent pattern in access certification audit findings: not the absence of a review program, but a program whose outputs demonstrate completion without demonstrating that the control operated. Understanding the structural reason this happens, and what it takes to close the gap, is the practical argument this ...
... piece makes.

What Completion Actually Proves

A completed access review is evidence that an activity occurred. It is not evidence that the activity was meaningful, that it was informed, or that it produced any change in the organization's access posture.

When a certification campaign closes with full completion, the record documents that every designated reviewer received their list and marked every item within the campaign window. This is genuinely useful information. It confirms that the review process executed. It does not confirm that the review process produced the decisions and outcomes that justify treating it as a control.

The distinction between an activity and a control is the distinction auditors are testing when they ask the follow-up questions above. Under SOX ITGC, COBIT, and most internal controls frameworks, a user access review is evaluated not on its completion rate but on its operating effectiveness: whether the review was informed, whether findings were acted on, and whether there is a retrievable record demonstrating both. A completed review that cannot demonstrate all three has documented an activity and not operated a control.

The Structural Problem That Produces Rubber Stamps

The gap between completion and evidence is not primarily a people problem. It is a process and tooling problem that manifests predictably when reviewers are handed the wrong inputs.

Consider what a typical certification workflow asks a reviewer to do. They receive a list of technical role names for the users in their team, a binary certify/revoke option for each item, a deadline, and in most implementations, no additional context. They are asked to make a governance judgment about access they did not configure, for systems they may not use daily, with no information about what the access actually permits, whether it creates a risk, whether the user has changed roles since the access was granted, or whether the access has been used recently.

Under those conditions, certifying the list is the rational response. The reviewer cannot make a meaningful decision without meaningful information. When the process does not provide that information, the review produces a sign-off, not a judgment. The completion rate looks the same either way. The evidentiary value is fundamentally different.

This is also the mechanism that produces the specific audit finding most often associated with access reviews: a reviewer who approved access creating a significant SoD conflict, because the conflict was not surfaced in the review workflow. The reviewer was not negligent. The process gave them a role name and a checkbox. The conflict was invisible.

The Five Elements That Make a Review Audit-Ready

Closing the gap between completion and evidence requires that the review process be designed to produce evidence, not just completion. Five elements determine whether it does.

The first is context at decision time. Reviewers need to see what an entitlement actually permits the user to do, expressed in business language rather than technical role codes. They need to know whether the entitlement carries an active SoD conflict, what the risk classification is, whether the access has been used recently, and how the user's profile has changed since the access was granted. A reviewer with this information can make a real decision. A reviewer without it is being asked to certify something they cannot meaningfully evaluate.

The second is a governed decision record. The decision must exist in a workflow system that captures who made it, when, and what the outcome was. A spreadsheet that was emailed, filled in, and returned is not a governed record. It is a file. When that file is needed as evidence, reconstructing which version was final, who reviewed which items, and what happened after the decisions were made becomes a manual exercise that auditors do not find convincing.

The third is remediation tracked to completion. When access is marked for revocation, a workflow must route that action to an owner, track whether the removal occurred, and record the timestamp confirming it was completed. A revocation decision with no downstream tracking is a stated intent. It is not evidence the access was removed. For the auditor testing whether the control operated, the difference between a stated intent and a confirmed completion is the difference between a finding and a clean opinion.

The fourth is formally documented exceptions. When a reviewer determines that access should be retained despite a risk flag or conflict, the rationale must be captured in the governance record, the compensating control must be named, and a review date must be assigned. An undocumented exception does not disappear from the risk picture. It reappears in the next audit as an unexplained anomaly.

The fifth is an exportable trail. The complete record of the campaign, covering scope, reviewers, decisions, dates, remediation actions, and documented exceptions, must be producible for an auditor without manual reconstruction from multiple systems. If generating the evidence package requires correlating exports from a certification tool, a ticketing system, and a series of email threads, the evidence was not built into the process. It was assembled after the fact, which is precisely the reconstruction problem auditors are designed to detect.

What the Evidence Architecture Actually Requires

The five elements above are not additional work layered onto an existing process. They are design requirements for a process that produces evidence as a byproduct of operating normally.

A process designed this way surfaces context to reviewers because the system retrieves it automatically at review time. Decisions are captured in a governed workflow because that is the environment in which reviewers operate. Remediation is tracked because revocation actions are routed through the same system that recorded the decision. Exceptions are documented because the exception workflow is part of the process, not a separate manual step. The exportable trail exists because the system records every event as it occurs.

None of this requires more time from reviewers. It requires a process architecture that makes evidence production inseparable from the review operation itself.

The organizations that get this right do not have better-disciplined reviewers or more thorough compliance teams. They have processes designed to produce evidence rather than completion. The distinction is architectural, and it determines whether an access certification program functions as a control or functions as a ritual that documents itself.

For a structured treatment of what makes access governance produce evidence by design, including user access reviews, SoD enforcement, remediation workflows, and exportable audit trails, visit openiam.com/solutions/access-governance.