The SOC 2 audit request list, explained
Between 80 and 160 line items arrive in a spreadsheet, written in criteria language. Half of them are asking for the same six populations in different words.
The request list, often called the PBC list for "prepared by client", is the spreadsheet your auditor sends at the start of fieldwork. Expect 80 to 160 line items for a first Type 2 covering the security criterion, delivered two to four weeks before fieldwork starts, with a due date that assumes you already have everything. Most of it is not new work. Roughly a third asks for documents you wrote during readiness, a third asks for configuration captures, and the remaining third asks for populations and samples, which is where teams lose their two weeks.
80 to 160 Line items, first Type 2, security only
2 to 4 weeks Notice before fieldwork begins
6 Populations behind most of the sample requests
What does the list actually look like?
Five columns, usually: a reference number, the criterion, the request in the auditor's words, a status, and a place for your response or file name. The request column is written in control language rather than in the language of your systems, which is the entire difficulty. "Evidence of logical access provisioning approval for a sample of new users" means "send me the ticket where somebody approved each of these five people getting access".
| Section | Items | What most of them are | Where it comes from |
|---|---|---|---|
| Entity level and governance | 10 to 18 | Org chart, policies, board or management meeting records, risk assessment | Documents you already wrote |
| Access and identity | 15 to 30 | User lists, MFA configuration, access reviews, joiner and leaver samples | Identity provider plus tickets |
| Change management | 10 to 20 | Change population, sampled merges, branch protection, pipeline runs | Repository and pipeline, and see CC8 |
| Operations and monitoring | 15 to 25 | Alert rules, scan reports, patch evidence, backup and restore, encryption | Cloud and tooling captures |
| Incident management | 5 to 12 | Plan, incident log, sampled write-ups, tabletop record | Your log, which must not be empty |
| Vendor management | 8 to 15 | Register, risk ratings, reviewed reports, contracts | Vendor register |
| People and HR | 10 to 20 | Hire and departure populations, training records, agreements, acknowledgements | HR system plus your own records, contractors included |
| Description and assertion | 4 to 8 | System description, management assertion, subservice organization treatment | Written by you, not the auditor |
| Typical total | 80 to 160 | Higher with additional trust services categories, roughly plus 20 to 40 percent each | |
The six populations behind most of it
Sample requests all resolve to a small number of complete lists. Produce these six from saved queries before the list arrives and the response time on a third of the spreadsheet drops to minutes.
- Everyone who joined during the period
- Employees and contractors, with start dates. The contractor half is what gets missed, and an incomplete population is a worse finding than a missing control.
- Everyone who left during the period
- With departure dates and the timestamp access was removed. This is the most sampled population in a SOC 2 and the easiest to fail.
- Every production change deployed
- Exported from the system that deploys, not from release notes. Covered in detail on change ticket evidence.
- Every grant of production access
- Including temporary and break-glass grants, which are the ones without a ticket behind them.
- Every incident logged
- Including the ones you judged minor. A log with nothing in it across six months reads as a log nobody keeps, not as a quiet period.
- Every vendor added or changed
- From the register, with the risk rating and what data each one touches.
Where the two weeks go
Not in finding evidence. It goes in reconstructing populations that were never queryable, then in the second round of requests generated when the auditor notices a name in one list that is missing from another. Build each population as a saved query during readiness and both problems disappear.
Comparing firms for this? Tell us what you need and it goes to the ones in the directory that do this work. No charge, and no phone number required.
Requests that are commonly misread
| The request | What to actually send |
|---|---|
| "Listing of all users with access to the in-scope systems" | A dated export per system, with status and role, not a screenshot of a page one |
| "Evidence of quarterly user access review" | The completed review showing reviewer, date, systems covered, decisions made and the access actually removed afterwards |
| "Population of changes during the period" | The full merge or deploy export for the exact date range, in a file, with a note of how it was produced |
| "Evidence that the control operated" | Something dated inside the period. A current screenshot proves design, not operation |
| "Management review of the risk assessment" | Meeting notes or a signed approval with a date, not the assessment document again |
| "Termination checklist for selected individuals" | The completed checklist per person, with the access removal timestamp from the system rather than a tick box |
| "Evidence of backup restoration testing" | The test record, what was restored, by whom and the outcome. Backup success logs are a different request |
| "Vendor SOC 2 reports for critical vendors" | The reports plus your note of what you reviewed and concluded. Holding the report is not the control |
| "System description" | Your narrative, written by you, signed by management. The auditor cannot write it and will not edit it |
The pattern in that table is that every request wants a dated artifact produced by a system rather than an assertion produced by a person. The evidence collection page is the routine that makes that automatic, and the evidence tracker produces the list for your own scope.
How to work the list
- Read it end to end before answering anything, and mark every item you cannot produce. That list is the real news, and it should reach your team on day one rather than on day nine.
- Answer the populations first. Samples cannot be drawn until they exist, so every day a population is late is a day of fieldwork that does not happen.
- Use their reference numbers as file names. An auditor working through 140 items across three clients will not hunt for your naming convention, and mismatched names generate follow-up requests.
- Answer in one channel. A shared folder or their portal, never email attachments, because the second round of requests is usually caused by an attachment nobody could find.
- When you cannot produce something, say so in the sheet with what you have instead. An early "we do not have this, here is the compensating record" is a conversation. The same message in week three is an exception.
- Expect a second and third round. Twenty to forty follow-up items is normal.
Working the list is most of fieldwork. Getting through SOC 2 fieldwork sets out the liaison, the tracker and the turnaround targets week by week.
Is the list a fair test?
Partly not. Request lists are reused between clients and frequently ask for artifacts that do not apply to a twenty-person remote company: physical security walkthroughs, data centre visitor logs, formal change advisory board minutes. The right response to those is not to invent something, it is to reply with why the control is not applicable in your environment and what operates instead. Auditors expect that reply and adjust the list.
What is fair is the insistence on complete populations. It looks like bureaucracy and it is the only thing making the sample mean anything. A sample drawn from a list you curated proves nothing.
What is a PBC list in a SOC 2 audit?
PBC stands for "prepared by client". It is the auditor's spreadsheet of every document, export, screenshot and sample they need from you, organized by criterion. It arrives before fieldwork and it is the main working document of the whole engagement.
How long do we get to respond?
Usually two to four weeks between receiving the list and the start of fieldwork, then rolling deadlines during fieldwork for follow-ups. Firms differ, and asking for the list early is almost always granted, since it costs them nothing and makes their schedule more likely to hold.
Can we see the request list before we sign with an auditor?
Ask. Many firms will share a sample list during the sales process, and one that will not is worth a second look, because the list is the clearest picture of how much work the engagement puts on you.
What happens if we cannot provide an item?
The auditor evaluates whether another record covers the control. If none does, it becomes a testing exception described in the report along with your management response. One or two exceptions with responses is common and survivable, and the version that damages a report is a pattern of them in one area.
Does a compliance platform answer the request list for us?
It answers part of it, mostly the configuration captures and user lists, and some firms accept exports directly from the platform. It does not produce your system description, your incident write-ups, your access review decisions or your vendor reviews, and those are the items that take the time. See evidence without a platform for the other side of that.
Get help working the list
Firms that do readiness work will run the request list with you, and it is the cheapest part of an engagement to buy on its own.
Get matched