The access review that survives an ISO 27001 audit

Access reviews are among the most frequently sampled controls in an ISO 27001 Stage 2 audit, and among the most common sources of nonconformities. The root cause is almost always the same: the organisation conflates a list of users with a review of access. These are different things, and an auditor can tell them apart immediately.

This post explains what an access review actually needs to demonstrate, and how to structure one that holds up to scrutiny.

The list versus the review

An access list is a snapshot. It shows who has access to a system at a point in time. Producing an access list is not difficult - most systems can export one in seconds. But the list itself proves nothing about whether the access is appropriate, whether it has been checked, or whether the person who has access still needs it.

An access review is a process applied to that list. It asks, for every entry: is this access still required, is it proportionate to the person's role, who approved it, and when was that approval made? The output of a review is a set of decisions - retain, reduce, revoke - with reasons and a record of who made each decision.

When an auditor asks for access review evidence, they are asking for the process output, not the list. An organisation that hands over a spreadsheet of users with no annotations, no decisions, and no sign-off has produced a list. An auditor will note that.

The four questions every access review must answer

A defensible access review must be able to answer four questions for every account in scope:

1. Who has access, and to what?

This sounds basic but it has teeth. "Who" means named individuals and service accounts, not just role groups. "To what" means specific systems, specific permission levels, and specific data classifications where relevant. A review that covers the application but not the database, or that covers human accounts but not service accounts, has gaps an auditor is trained to look for.

2. Why does this access exist, and is it still justified?

Approved access from a joiners process six months ago may no longer be justified if the person has moved roles. The review needs to verify that each entry maps to a current, legitimate business need. A helpful habit is to require the reviewer to confirm that each account corresponds to an active employee or system function before marking it retained.

3. Who approved the decision?

The review must be signed off by someone with the authority to make access decisions for the system in question - typically the system owner or data owner, not the IT administrator who exported the list. An administrator performing a self-review of a system they manage is a segregation concern that auditors notice.

4. When was the decision made?

The review record needs a date. Undated reviews cannot be placed in a review cycle, which means they cannot be demonstrated to meet any stated cadence. If the policy says quarterly reviews and the only record available has no date, the cadence claim cannot be verified.

What a complete access review record looks like

Illustrated against a representative SaaS organisation reviewing access to a production AWS account:

• Review date: stated at the top of the document.
• System in scope: AWS production account, including all IAM users, roles with console access, and service account keys.
• Reviewer: named individual with the title and system owner designation.
• Reviewed against: HR active employee list as of the review date.
• Findings: for each account - retain (with business justification), reduce (with specific permission change required), or revoke (with reason, e.g. employee departed 2026-08-01).
• Actions raised: for every revoke decision, a linked ticket showing the access was actually removed, with the date it was completed.
• Sign-off: a second named person confirming the review is complete and actions have been verified closed.

The last element is the one most often missing. A review that identifies access to be revoked and stops there has documented a problem it did not solve. That is arguably a worse audit position than a review that found nothing wrong, because it shows an open gap the organisation knew about.

Scope: the systems that must be in scope

One of the most common access review gaps is scope. Teams review the application and overlook:

• The underlying database or storage layer.
• Cloud console access (AWS IAM, Azure RBAC, GCP IAM) separately from the application.
• Version control systems (GitHub, GitLab) with access to production secrets or deployment pipelines.
• Monitoring and logging platforms where security-relevant data is held.
• Third-party SaaS tools that hold personal or sensitive business data.
• Shared mailboxes and distribution lists where these are considered in scope.

If the ISMS scope covers the data held in these systems, the access review scope should cover the systems themselves. Gaps in scope are a finding under Annex A 5.15 and often raise questions about the scope statement itself.

Cadence and the policy connection

The review cadence needs to be stated in a policy or procedure, and the actual reviews need to match it. If the procedure states quarterly reviews of privileged access and the evidence shows one review in twelve months, that is a clear nonconformity.

A proportionate approach: privileged and administrative access reviewed quarterly; standard user access reviewed at least annually, with a review also triggered by any significant joiners, movers, or leavers event. The trigger-based review is important because a once-a-year schedule can leave departed employees with active credentials for months if the leaver process is not connected to access management.

Every review record should reference the policy and cadence it satisfies. A reviewer who knows to include this information saves the auditee from having to reconstruct the connection during the audit.

The difference between a working review and an audit-ready one

Many organisations run access reviews that are substantively sound - people are genuinely checking accounts, decisions are being made. The problem is documentation. Decisions made in a meeting without minutes, changes communicated by Slack without a linked ticket, or reviews completed informally without a sign-off record cannot be presented as audit evidence.

The transition from a working review to an audit-ready one is primarily a documentation exercise. Agree in advance on the template or format the output will take. Confirm that every action raised in a review is traceable to a closed ticket before the review is signed off. Store the review record in a location named in the evidence map so it can be found within thirty seconds during Stage 2.

The review process itself is rarely the problem. The record of the review is where organisations come unstuck.

Where Kellwick fits

Kellwick provides independent ISO 27001 advisory, including a review of access management evidence before Stage 2. Kellwick reviews what you have against what an auditor will expect to see, and identifies specific gaps in scope, documentation, or cadence before they become findings. Request a readiness assessment to see where your access review evidence stands ahead of certification.