What auditors actually ask for in an access review

The ask, in one sentence

A person answering questions in r/soc2 about SOC 2 Type II evidence collection put it plainly: "the auditor wants to see who reviewed, when, what the outcome was, and that it happens on a defined cadence" (r/soc2). That is four separate things, and an access review that only produces one or two of them — a list of who has access, say, with no reviewer and no timestamp — will not satisfy an auditor even if the underlying access is completely correct.

Why a list of users is not enough

A reply in a r/SaaS thread on what auditors actually focus on in a SaaS SOC 2 audit makes the same point from the other side: "A list of users isn't enough. A quarterly access review with sign-off is… If you can't show it happened, for an auditor it didn't happen" (r/SaaS). The same thread describes what a team did before they had a tool for it: block two hours every quarter, screen-share through every high-risk app with the engineering lead, and record sign-off in a ticketing system. It worked, and it is exactly the shape of evidence below — just produced by hand.

Mapping each ask to an artifact

• Who reviewed. A named reviewer per row or per system, not "the security team" as a group.
• When. A timestamp on the decision, not just the date the review was scheduled to start.
• What the outcome was. Approve, revoke, or don't-know, per entitlement — not a single pass/fail for the whole review.
• Defined cadence. Evidence that this is the fourth review in a row on a quarter, not the first one ever run, timed to coincide with an audit.

Two more things belong in the pack even though they are asked for less often: follow-through (did the revocation actually happen, and when) and exceptions (which rows are still open, and why).

What a pack has to print to stand alone

An auditor who receives a spreadsheet exported at some unknown point, with no way to tell whether it was edited afterward, has to ask follow-up questions before they can rely on it. A pack that stands on its own without those questions prints, at minimum: a generation timestamp, a hash of its own contents, and a plain statement of how it was produced. That is not about looking rigorous for its own sake — it is what lets the auditor skip the question of whether the document in front of them is the same one that existed on the date it claims.

Proving cadence across more than one review

A single, well-documented review answers "who, when, what outcome." It does not, by itself, answer "does this happen on a defined cadence" — that only shows up once an auditor can see the same review, for the same systems, repeated on a consistent schedule over time. This is why keeping every past review intact matters more than making any single one perfect: an auditor looking at four consecutive quarterly packs, each with its own date and its own complete set of decisions, is looking at exactly the evidence the cadence question is asking for. Delete or overwrite the old ones and there is nothing left to show a pattern with.

Exceptions are evidence too

It is tempting to treat an open exception — a row nobody has resolved yet — as something to hide before the auditor sees it. The opposite is usually true. An auditor who sees a review with zero open exceptions, ever, across every quarter, tends to ask harder questions about whether the review is actually catching anything. A small number of visible, dated, tracked exceptions with a plan attached reads as a review that is doing real work, not one that has been quietly cleaned up beforehand.

If this is your first review, and there is no history yet

The cadence question is unanswerable the first time you run a review — there is no history to point to yet, and that is fine to say plainly. What matters from that point on is starting the record now and keeping every review after it, so that a year from now there are four consecutive, dated packs to show instead of one review and a promise that more are coming.

Questions

Does an auditor need to see every row, or just a sample?

Most audits sample. But you cannot know in advance which rows will be sampled, so the record has to be complete for all of them, not only the ones you expect to be checked.

Is a screen-shared, ticket-recorded review acceptable evidence?

Based on the account above, yes — the format matters less than whether it captures reviewer, timestamp, outcome and cadence. A tool makes that easier to sustain quarter after quarter; it is not the only way to get there.

Does this replace Vanta, Drata, Entra P2 or SailPoint?

No. Those platforms do far more than access reviews. This is about the narrower question of what an access review itself has to produce to be usable as audit evidence, whichever platform or spreadsheet runs it.

Next step

AttestProof's evidence pack is built directly against this list: named reviewer, timestamp, outcome and cadence per entitlement, plus a sha256 hash and generation time printed on every pack, so the document answers the follow-up question before it gets asked.