Access Review Evidence for Auditors: What to Prepare

Jordan did not find out about the access review request from a neat audit plan. It arrived as a forwarded email with a subject line that looked harmless: "Vendor security questionnaire follow-up." Three messages later, the question was less harmless:

"Can you send evidence that user access is reviewed periodically?"

The permissions existed somewhere. The HR list existed somewhere. The system owners had approved access in Slack, tickets, or memory. There were exports from Microsoft 365, a CRM admin screen, a finance system, and a few vendor portals. None of that was the same as access review evidence.

That is the gap auditors, customer security teams, and cyber insurers usually probe. They are not asking whether you can open an admin console and take a screenshot. They want a dated record showing who reviewed which access, when the review happened, what was in scope, what decision was made, and what follow-up remained.

Access review evidence is operational documentation that a review was performed and signed off. It can support an audit conversation, security questionnaire, cyber insurance response, or management review. It is not a compliance certification, legal advice, or a guarantee that an auditor will accept every part of your control environment.

This guide shows what to prepare, how to avoid overclaiming, and how to assemble a pack that looks like a maintained routine rather than a last-minute archaeology project. CertPilot's Access Reviews module appears near the end as one way to keep the register and evidence trail together.

The quick answer

A useful access review evidence pack should include:

• the review period and cadence;
• the systems and people in scope;
• the reviewer or accountable owner;
• the access records reviewed;
• the decisions made for keep, change, remove, or action required;
• the completion date and sign-off;
• any follow-up actions or exclusions;
• the exported evidence artifact, such as an Access Review Register PDF.

The weak version is a screenshot of a permissions page. The stronger version is a dated, scoped, owned review record that shows the review happened and produced decisions.

What auditors and insurers are really checking

The wording changes by audience, but the underlying questions are consistent.

An auditor may ask whether a user access review control exists. A customer security team may ask for proof that privileged access is periodically checked. A cyber insurer may ask whether access is reviewed and whether problem access is remediated. Different words, same practical concern: does somebody periodically check whether people still have appropriate access?

Translate the request into these operational questions:

• Do you have a review cadence, or is access checked only after something goes wrong?
• Can you show the last completed review period?
• Who reviewed the access?
• Which systems and accounts were included?
• Which access levels were approved, changed, removed, or flagged?
• What happened to exceptions?
• Can you produce the same evidence again next quarter?

That last question matters more than teams expect. A reviewer can usually tell the difference between a maintained process and a pack built overnight from exports. One recent review may answer a questionnaire. A run of completed reviews says the habit exists.

What counts as access review evidence

Access review evidence is the dated, attributable record that a periodic access check was performed. It should show the population in scope, the systems reviewed, the access levels checked, the decisions made, and the sign-off that closed the review.

This is the access-specific version of IT governance evidence. It is proof of a routine, not proof that every source system is perfect.

Strong evidence usually includes four layers.

First, the scope layer: the period, cadence, systems, user population, and exclusions. If contractor access was included, say so. If vendor portals outside the Systems Catalog were not included, say so. Stated scope is more credible than implied total coverage you cannot back.

Second, the register layer: the people, accounts, systems, and access levels reviewed. This may come from a spreadsheet, a maintained access register, or a CSV import. It should be readable enough that someone can connect a person to a role and a system.

Third, the decision layer: keep, change, remove, no access, or action required. Evidence without a decision is only an inventory.

Fourth, the completion layer: who completed the review, when, for what period, and with what remaining actions or notes.

A screenshot of an admin console is weak because it usually fails all four layers. It proves that a screen existed at one moment. It often does not prove who reviewed it, whether the whole population was covered, whether any decision was made, or whether the review closed.

A simple evidence pack structure

If someone asks for access review evidence tomorrow, build the pack in this order.

1. Scope statement

Start with a short paragraph that states what the review covered.

Example:

"Q2 access review for CRM, finance, support desk, email administration, and shared vendor portals known to IT as of 2026-06-30. Population includes active employees, contractors, shared accounts, and service accounts recorded in the access review register. Systems outside the Systems Catalog and accounts not known to IT are outside this review period. Review completed by Jordan Lee on 2026-07-10."

This paragraph prevents a common audit problem: the reviewer assumes the pack proves more than it does. Clear scope protects the reader and protects your credibility.

2. Reviewer and owner record

Name the person who completed the review and, where useful, the owners who contributed.

For access reviews, one person often coordinates the evidence while several people answer questions. The people manager may know whether the employee still needs access. The system owner may know whether the access level is appropriate. IT may know whether the account exists and how the role maps to the system.

Do not flatten those roles into one vague approval. If the evidence says "reviewed by IT," the next question is usually "who in IT, and what did they review?"

3. System and population list

Include the systems in scope and the population reviewed.

For each system, capture the system name, purpose, owner, criticality, and lifecycle status where known. For each person or account, capture name, account identifier, team, status, and manager or accountable owner where useful.

This is where a maintained People & Accounts register and Systems Catalog make the access review less painful. If the person list is stale before the review starts, the evidence pack will inherit the staleness.

4. Access lines and decisions

Each access line should answer one practical question:

Should this person keep this level of access to this system for the next review period?

Good decision values are boring on purpose:

• Keep: access remains appropriate.
• Change: access is still needed, but the level should change.
• Remove or no access: access is no longer needed.
• Action required: the reviewer cannot decide without follow-up.
• Out of scope: the item does not belong in this review cycle, with a note.

The key is to record a decision. A raw export says what access exists. A completed review says what somebody decided about it.

5. Exceptions and follow-up

Separate exceptions instead of burying them in a long list.

Common exceptions include admin access, shared accounts, service accounts, contractors, former employees, unknown owners, stale systems, and access levels that do not map cleanly to read/write/admin. If a reviewer only has ten minutes, these are the rows they need to see first.

For each exception, record the follow-up owner and current status. If the change must be made in the underlying system, say that plainly. The evidence should not imply that the report removed access automatically.

6. Completion sign-off

Close the pack with the completion record: reviewer, date, period, cadence, snapshot counts, and notes. If the review remains open, say that it is open. Do not pretend a draft is a completed review.

This completion layer is the part many teams miss. They spend time cleaning rows but forget to preserve the event that proves the review happened.

What makes evidence defensible

Defensible access review evidence has four properties.

It is dated. The review has a completion date and a defined period. "We do reviews" is an assertion. "The Q2 review was completed on 10 July and covered April through June" is a record.

It is owned. A named reviewer or accountable owner signed off. Anonymous evidence invites the question "who actually checked this?"

It is scoped. The pack says which systems, people, access types, and exceptions were included. It also says what was not covered.

It is durable. The completion record does not silently change after the fact. An editable spreadsheet can still be useful, but the final sign-off should be preserved as a point-in-time record.

A review pack with all four properties feels like a real operating routine. A pack missing one of them may still help, but it gives the reviewer an obvious place to probe.

Current exports are not the same as completed evidence

A present-day permissions export answers a different question.

It says what the system shows now. It does not prove that somebody reviewed the access last quarter, that exceptions were handled, or that a reviewer signed off. If an auditor asks for evidence that the review happened, a current export is supporting material, not the evidence itself.

This distinction matters when teams try to recover from missing history. If you have no completed review record, do not backfill one and pretend it existed. Build a current review, document the gap, and use the recovery workflow in Auditor Asked for Access Review Evidence You Don’t Have: What to Do Next.

Example: what a lean IT team can send

A practical pack for a 140-person company might look like this.

• Cover note: Q2 review, completed 2026-07-10, quarterly cadence, coordinated by IT Operations.
• Scope: CRM, finance system, support desk, email admin roles, project management workspace, and the five vendor portals recorded in the Systems Catalog.
• Population: active employees, active contractors, shared accounts, and service accounts known to IT.
• Register export: people, account identifiers, systems, access levels, owners, last reviewed dates, and review result.
• Exception list: four admin accounts retained with notes, two contractor accounts marked for removal, one unknown owner assigned to Finance for confirmation.
• Completion record: reviewer, period, cadence, next due date, snapshot counts, and action-required count.
• Follow-up note: removals must be completed in the source systems by the named owners.

That is enough for a serious conversation. It does not claim perfection. It shows what was checked, who checked it, what remains unresolved, and where the evidence stops.

How CertPilot fits

CertPilot is useful when the problem is not "we need another screenshot" but "we need the review record to survive the quarter."

In Access Reviews, teams maintain the access register and matrix manually or by CSV import. The Systems Catalog provides context for each system. Review fields capture access level, review result, action-required status, last-reviewed date, and notes. Completing a review writes an immutable completion record with reviewer, period, cadence, next due date, note, and snapshot counts.

The Access Review Register PDF packages that maintained data into a report for management, client evidence, or audit preparation. The sample reports gallery shows the fake-data format before you produce your own.

This is also where manager access review packets help. The manager packet is the decision aid before sign-off. The Access Review Register PDF is the evidence artifact after the review has been recorded.

What CertPilot does not claim

This boundary belongs in the evidence pack if the audience might misunderstand the tool.

CertPilot does not certify NIS2, ISO 27001, SOC 2, GDPR, or any other framework. It does not guarantee an audit outcome. It does not replace a qualified auditor or lawyer.

CertPilot Access Reviews do not connect to Google Workspace, Microsoft 365, HR systems, identity providers, or SaaS admin consoles today. Records are customer-entered or imported by CSV. CertPilot does not discover accounts automatically and does not remove access from source systems.

It is not employee monitoring. The register records access and review decisions. It does not read emails, documents, chats, files, browser history, prompts, or activity logs.

Those limits do not weaken the evidence. They make the evidence honest. A reviewer is more likely to trust a pack that states what it proves and what it does not prove.

Checklist before you send access review evidence

Before sending the pack, check these items:

• The review period and cadence are written.
• The systems in scope are listed.
• The people and account population is described.
• The reviewer or accountable owner is named.
• Access levels are readable, not just raw role IDs.
• Decisions are recorded for keep, change, remove, no access, or action required.
• Exceptions are visible.
• Follow-up actions have owners.
• The completion date is captured.
• The pack states important exclusions.
• The pack does not imply certification, legal advice, connector sync, or automatic access removal.

If those are true, you have a defensible operating record rather than a pile of exports.

How to answer the request without sounding defensive

The evidence pack is only half the job. The message around it matters too.

A good response is plain and bounded. It should say what period the review covers, what systems were included, who completed it, what artifact is attached, and what the artifact does not claim.

Example:

"Attached is our Q2 access review evidence pack. It includes the completed-review summary, the systems and account population in scope, the access decisions recorded for the period, and the action-required items still being followed up in source systems. The review was completed by IT Operations on 2026-07-10 and covers the systems listed in the scope note. This is operational access review evidence; it is not a compliance certification or legal opinion."

That answer is stronger than a defensive paragraph about how busy the team is. It gives the reviewer a useful artifact and a clear boundary.

If the request comes through a questionnaire, avoid one-word answers when the question asks "do you perform periodic access reviews?" A better answer is short but specific:

"Yes. Access reviews are run quarterly for the systems listed in the access review register. The latest completed review covered Q2 2026 and was completed on 2026-07-10. Evidence includes the review scope, access register, decisions, exceptions, and completion sign-off."

If part of the estate is out of scope, say so in the same answer. A narrow truthful answer is safer than a broad answer the evidence cannot support.

Related access review resources

If you need to build the operating routine before preparing evidence, start with How to Run a Quarterly Access Review. If reviewers need better inputs, use the manager access review packet. If your access matrix is still being assembled by hand, read User-System Access Matrix Without an IAM Connector. For management framing, see Show Management User Access Is Under Control.

Frequently asked questions

Is an Access Review Register PDF enough to pass an audit?

No single document "passes" an audit. An Access Review Register PDF is evidence that a customer-run access review was performed, scoped, and signed off. It can support an audit conversation, but CertPilot does not certify compliance or guarantee an outcome.

What evidence do cyber insurers usually want?

They usually want to know whether access reviews happen, how often they happen, when the last one was completed, who reviewed it, and whether problem access is acted on. A dated completion record plus the access register answers those questions better than a screenshot.

Can I use a current permissions export as evidence?

Use it as supporting detail, not as the completed review evidence. A current export shows what access exists now. It does not prove that a previous review happened or that someone made decisions during that period.

Where does CertPilot get the access data?

From records your team enters or imports by CSV. CertPilot does not connect to Google Workspace, Microsoft 365, HR systems, identity providers, or SaaS admin tools today.

What if we do not have older access review evidence?

Do not invent a past review. Document the gap, run a current review, preserve the completion record, and set the next cadence. If the request is active, use the recovery guide for missing access review evidence and be clear about what is historical and what is current.