What Evidence Will Your Auditor Ask For? The Request List, Explained

Auditors request evidence in three layers for every control in scope: design evidence (the approved policy, the architecture diagram, the control description), configuration evidence (the settings export, the console screenshot, the identity provider policy), and operating evidence (the ticket, the log, the signed access review). A SOC 2 Type I needs the first two layers as of a single date. A Type II needs the third layer spread across the entire observation window, which is why a Type II request list is not a longer version of a Type I list but a different document.

The list itself has a name you will hear on the kickoff call: the PBC list, for "prepared by client". Understanding what it is asking for, layer by layer, is most of what separates a two-week fieldwork from a two-month one.

Key takeaways

• Auditors request evidence in three layers for every control in scope: design (the approved policy and control description), configuration (the settings export), and operating (the ticket, the log, the signed review).
• A Type I needs the first two layers as of a single date. A Type II needs the third across the entire observation window, which makes its request list a different document rather than a longer one.
• Nearly every unpleasant surprise lives in the gap between layer two and layer three. The configuration is fine and the control ran most of the time. "Most" is the problem.
• The population is the thing, not the sample. Know which system is the authoritative source of each recurring control's population, and produce it as a dated, system-generated export rather than a maintained spreadsheet.
• Ask your examiner for their standard request list before you sign, and ask what their process is when they find an exception. That last answer varies more between firms than anything else on the list.

Why the three layers exist

Each layer answers a different question, and an examiner cannot skip any of them.

Design evidence answers: does a control exist, and if it operated as described, would it meet the criterion? This is documentary. Your access control policy says accounts are disabled within one business day of termination. Your change management policy says production changes require an approval from someone other than the author. The examiner reads these and forms a view on whether the described control, if it ran, would do the job.

Configuration evidence answers: is the system actually set up the way the policy claims? This is a point-in-time technical artifact. MFA enforcement in the identity provider. Branch protection on the repository. Encryption settings on the database. Retention on the log store. It proves the control is implemented, not that it operated.

Operating evidence answers: did the control run, every time it was supposed to, across the whole period? This is the layer that produces exceptions. Tickets with dates. Review records with signatures and dates. Deploy approvals attached to the change. Quarterly reports that exist for all four quarters rather than three.

Nearly every unpleasant surprise in a first examination lives in the gap between layer two and layer three. The configuration is fine. The control ran most of the time. "Most" is the problem.

What actually appears on the list

A first-year SOC 2 request list for a single-product SaaS company reliably contains the following, grouped the way examiners tend to group it.

Governance and scope. The system description (for SOC 2, the narrative that becomes Section 3 of the report), the organisation chart, the list of in-scope systems and environments, the list of subservice organisations you rely on, board or leadership minutes showing security oversight, and the risk assessment with its methodology.

Policies, with evidence of approval and review. Not just the documents: the examiner wants the approval date, the approver, and the record that each policy was reviewed within your stated cycle. A perfect policy with no approval record is a document, not a control.

Access. The full user roster per in-scope system, the full list of joiners and leavers for the period pulled from HR rather than from IT, provisioning and deprovisioning tickets, privileged-access lists, and every periodic access review with its date and the reviewer's sign-off.

Change management. The complete population of production changes for the period, the ticket or pull request for a sample of them, evidence of approval and testing, and evidence that emergency changes followed the documented emergency path.

Operations and monitoring. Vulnerability scan output and the remediation record, the penetration test report, backup job records and at least one restoration test, alerting configuration, and incident tickets with timelines.

People. Background check records for the period's hires, security awareness training completion by person, and signed acknowledgment of the policies.

Vendors. The vendor inventory, the risk tier for each, the assessments performed during the period, and the SOC 2 or ISO 27001 reports you collected from critical vendors. If you have not built that program yet, our vendor risk management guide is the place to start, because this is the section that most often gets deferred and then blocks the report.

The population is the thing, not the sample

Here is the mechanic that catches teams out. For most operating controls, the examiner does not ask for everything. They ask you for the complete population of occurrences, then draw a sample from it and test those items. The sample is what you spend your week on. The population is what decides whether any of it counts.

If you cannot demonstrate that the list of terminations you handed over is complete, nothing sampled from it supports a conclusion, because a list that quietly omits three contractors is not evidence about your offboarding control. The same applies to the change population, the new-hire population, and the incident population. Examiners test completeness deliberately: they will reconcile your termination list against payroll, your change list against the deploy log, your user list against the identity provider rather than against your spreadsheet.

The practical instruction that follows is short. For every recurring control, know today which system is the authoritative source of its population, and be able to produce that population as a system-generated export with a date on it. A list someone typed into a spreadsheet is the weakest artifact you can hand an examiner, and it invites exactly the completeness testing you do not want. We cover how sample sizes get set, and why no standard fixes them, in how audit sampling works.

Screenshots, exports, and what counts as good evidence

Not all artifacts are equal, and the ranking is stable across frameworks.

The strongest evidence is a system-generated export or report that carries its own metadata: who ran it, from which system, on what date, covering what period. Second best is a screenshot that happens to include the system clock, the logged-in user, and enough context to identify the environment. Weakest is a cropped screenshot of a settings panel with no date, no URL, and no indication of which of your three environments it came from, which is the single most common thing we see resubmitted.

Four habits remove most of the friction:

• Capture at source, with context. Full window, visible date, identifiable environment. A cropped image saves nobody time once it comes back as a follow-up question.
• Name files so a stranger can route them. Control reference, system, period, artifact type. Examiners work through hundreds of files and every ambiguous filename becomes an email.
• Collect as you go. Evidence produced in the month it describes is normal operations. Evidence assembled eight months later is archaeology, and the gaps you find are real gaps you can no longer close.
• Keep one index. A single register mapping control to owner to evidence artifact to source system. This is the artifact a compliance platform genuinely gives you for free, and it is the thing you will rebuild by hand if you skip it.

What the platform covers, and what it does not

Compliance automation earns its keep here. Anything with an API (identity, cloud configuration, device management, code review, HR) is monitored continuously and better than a human would. That is layer two, plus a slice of layer three, and it is real work removed from your team.

What it does not produce is the human-authored layer: the system description, the risk assessment, the vendor assessments, the board oversight record, and the judgment calls about scope. It also does not chase the review that did not happen. We laid out that boundary in detail in our platform-versus-consultant piece, and the request list is where the boundary becomes concrete: roughly the top half of the list above comes out of the tool, and roughly the bottom half comes out of somebody's calendar.

The four questions to ask before fieldwork opens

Ask your examiner these in writing, ideally before you sign, and certainly before the observation window closes:

1. Send us your standard request list for our scope, now, not at kickoff. You want to see it while you can still fix what it asks for.

2. For each recurring control, which population will you request, and from which system do you expect it to come?

3. What is your preferred evidence format, and will you accept exports from our compliance platform directly through its auditor portal?

4. When you find an exception, what is your process: do we get a chance to provide additional evidence before it is written up, and how does that work?

The fourth question is the one people forget, and the answer varies more between firms than anything else on the list. It also pairs with the question of what an exception costs you once it is written up, which we cover in can you fail a SOC 2 audit, and with the discipline of writing the plan that closes the finding.

Where Top Floor fits

Running the evidence process is the least glamorous and most reliably useful thing an outside team does. When we run it, your engineers answer questions rather than assemble artifacts, and the request list stops being a surprise document that arrives in month nine. If you have somebody internal who genuinely owns the compliance calendar and enjoys this work, you do not need us for it, and we would rather say that now than after an engagement you did not need. What that person needs from you is authority to chase people, not just responsibility for the outcome.

Frequently asked questions

What is a PBC list?

PBC stands for "prepared by client". It is the itemised list of documents, exports, screenshots, and records the audit team asks you to produce, usually issued at kickoff and updated through fieldwork as samples are drawn. A good examiner will share their standard list for your scope before the engagement letter is signed. Ask for it early: the list is the most concrete description available of what the examination will actually require from you.

How much evidence does a Type II need compared with a Type I?

A Type I needs design and configuration evidence as of a single date, so it is largely documents and settings exports. A Type II needs, in addition, operating evidence spread across the entire observation window: every occurrence of each recurring control, drawn from a complete population, with dates. That third layer is why a Type II costs more, takes longer, and is where exceptions come from. Nothing about a Type I prepares you for the volume of a Type II.

Why does the auditor want the whole population and not just our samples?

Because the sample only supports a conclusion if the population it came from is complete. If your termination list omits contractors, testing 25 items from it proves nothing about your offboarding control. Examiners reconcile the populations you provide against an independent source (payroll for terminations, the deploy log for changes, the identity provider for users), so the safest habit is to produce every population as a dated, system-generated export rather than a maintained spreadsheet.

Can we reuse this evidence for our next framework?

Much of it, yes. Access reviews, change records, training completion, vendor assessments, and backup testing satisfy corresponding requirements in several frameworks at once, provided you tag each artifact to every requirement it supports at the moment you collect it. Retrofitting the tags later is the expensive path. We work through the mechanics, and the limits, in reusing evidence across frameworks.