SOC 2 Evidence Collection: What Auditors Actually Want (With Examples)

Somewhere between signing the engagement letter and your first audit meeting, your auditor sends a spreadsheet with a few hundred rows called a PBC list — "Provided by Client." It names every artifact they expect from you: user access listings, change tickets, onboarding records, board minutes. For most first-time teams, this is the moment SOC 2® stops being abstract.

The good news: what auditors want is far more predictable than the list's length suggests. Evidence requests follow directly from the AICPA's Trust Services Criteria, and auditors evaluate every artifact against the same handful of properties. Once you understand those properties, you can stop guessing — and stop producing evidence that gets bounced back.

How auditors think about evidence

A SOC 2® examination is an attestation performed under the AICPA's standards: an independent CPA firm forms an opinion on whether your controls are suitably designed (Type I) and operating effectively over a period (Type II). Evidence is what that opinion stands on. For every control in your system description, the auditor asks one question: does this artifact prove the control operated as described?

That single question breaks down into four properties auditors check on nearly every artifact:

• Completeness. Does the evidence come from the full population of events, or a curated subset? A list of "some offboarded employees" proves nothing; a system-generated list of all terminations in the period does.
• Reliability of source. System-generated evidence (an export from your identity provider, a query result with visible parameters) carries more weight than manually assembled evidence (a spreadsheet someone typed up). The harder an artifact is to fabricate, the more the auditor trusts it.
• Timeliness. The artifact must show the control operating inside the audit period. An access review performed the week after your Type II window closed doesn't count toward it.
• Traceability. The auditor needs to connect the artifact to the control, the system, and the date — which is why undated, cropped screenshots are the single most common rejection.

Type I and Type II differ mainly in volume: Type I asks whether controls exist and are designed sensibly at a point in time, so policies, configurations, and one example of each process usually suffice. Type II asks whether they operated all period long, so the auditor samples real occurrences. We cover that split in detail in evidence requirements for Type I vs Type II.

Populations and samples: the part nobody warns you about

Here's the mechanic that surprises most first-time teams. For recurring controls in a Type II examination, the auditor doesn't ask you to send "a few examples." The request comes in two steps:

1. You provide the population — every occurrence of the event in the period: every new hire, every production change, every access review, every incident. Crucially, the population itself must be system-generated with visible criteria (the query, the filter, the date range), because the auditor first tests whether the population is complete.
2. The auditor selects the sample. From that population, they pick the items to inspect — you don't get to choose your best work. For each sampled item, you then produce the underlying artifacts.

This is why "we'll clean things up before the audit" doesn't work for Type II. If three offboardings out of forty were missed during the period, sampling will likely surface at least one, and the finding is about the period — it can't be fixed retroactively. The only reliable strategy is capturing evidence as a byproduct of doing the work, all period long. That's the core argument in our guide to maintaining SOC 2 compliance year-round.

What auditors request, by control area

The exact PBC list varies by auditor and by which Trust Services Categories are in scope, but for the Security (Common Criteria) category, the requests are remarkably consistent. Here's what they concretely look like.

Access control

• User access listings exported from your identity provider and key systems (production cloud account, database, code repository), showing every account and its role — with the export date and source visible.
• Access review records: the review itself (who reviewed which accounts, when), the reviewer's sign-off, and — the piece teams most often miss — proof that flagged access was actually removed, with a ticket or log entry showing when.
• Offboarding evidence: the auditor cross-references your HR termination list against system access. For sampled leavers, expect to show the deactivation timestamp in each system versus the termination date.

Change management

• The population of production changes — typically the list of merged pull requests or deployments in the period, pulled from your version control or CI system.
• For each sampled change: evidence of peer review and approval before merge, passing automated checks, and that the person deploying wasn't approving their own change (or a documented, risk-accepted exception).

Onboarding and HR

• For sampled new hires: signed policy acknowledgments, security awareness training completion (with date), and background screening where your policy commits to it — the auditor checks the artifacts against your own stated policy, not an external standard.

System operations and incident response

• Monitoring and alerting configurations (what triggers an alert, who receives it).
• For sampled alerts or incidents: the record of triage, resolution, and — if your policy promises it — a post-incident review. If you had zero incidents, expect the auditor to test that your detection would have caught one, not just take your word.

Risk and vendor management

• Your risk assessment for the period and the risk register showing treatment decisions.
• The vendor inventory, plus evidence of review for sampled critical vendors — typically that you obtained and actually reviewed their SOC 2® report or equivalent, not just filed it.

Why evidence gets rejected

Most bounced evidence fails on form, not substance — the control operated fine, but the artifact can't prove it. The recurring offenders:

• Screenshots without context. No visible date, no URL or system name, cropped so the filter criteria are hidden. If a screenshot is unavoidable, capture the full window including the address bar and timestamp.
• Exports with invisible criteria. A spreadsheet of users means little if the auditor can't see the query or filters that produced it — they can't verify the population is complete.
• After-the-fact artifacts. Approvals recorded once the audit started, access reviews back-dated into the period, policies whose revision history shows they were written last week. Auditors check metadata.
• Evidence that contradicts your own policy. If your policy says quarterly access reviews and you produce two for the year, that's an exception — even if two reviews would have been a perfectly defensible policy.

That last point is worth sitting with: auditors test you against what your system description and policies claim. Writing aspirational policies is the most self-inflicted way to fail evidence testing. Which controls to claim in the first place is its own problem — see evidence gathering vs control mapping.

Organizing evidence so the audit is retrieval, not archaeology

A few practices separate teams that close their evidence requests in days from teams that spend weeks:

• Index evidence by control, not by system. The auditor works control-by-control; if your artifacts are organized the same way, every request is a lookup.
• Capture at the moment of the event. The offboarding checklist filled in on the leaver's last day is evidence; the one reconstructed six months later is a liability.
• Prefer standing exports over one-off screenshots. A scheduled, parameterized report from your IdP or cloud account is reliable, repeatable, and satisfies the completeness test by construction.
• Automate the recurring pulls. Access listings, configuration states, and change populations are exactly the artifacts that can come straight from your infrastructure — this is what automated evidence collection does in AuditBadger, pulling evidence from AWS, GCP, GitHub, and Cloudflare and mapping it to the controls it supports.

The bottom line

Auditors aren't looking for impressive evidence; they're looking for boring, complete, system-generated, dated evidence that matches what your policies claim. Build the capture into the work itself, keep populations exportable with visible criteria, and the PBC list turns from a crisis into a checklist. If you're earlier in the journey and not sure your controls are ready to generate this evidence at all, start with a readiness assessment before you book the auditor.