The SOC 2 PBC list: 26 requests and how to answer each
Here is the evidence request list itself, not a definition of it. Each item shows what to send and what gets it returned.
A SOC 2 PBC list is the set of evidence requests your auditor sends when fieldwork starts. PBC means prepared by client. Each numbered line is an export, a document or a screenshot you owe, and the examination waits until it arrives. Below are all 26 requests, with what to send and what gets a response returned.
The requests themselves are plain. The answers are where time goes. A reply that looks complete but misses the test sends your file to the back of the auditor's queue, and that costs days of calendar each time. So read the right hand column of each table first. It is the part that saves you the most.
Why you have to produce it yourself
The name draws a line between the auditor's work and yours. That line exists for independence. An auditor who assembled your evidence would be testing their own work.1 So every item is something only your company can generate. You can ask the auditor what would satisfy a request. You cannot ask them to produce it.
That is also where the cost question starts. Somebody on your side has to pull these exports. Some teams pay an outside consultant to do it. Here is one published estimate of what that route costs:
- Comp AI states that a vCISO or compliance consultant might charge $150 to $400 an hour, which can total $20,000 to $50,000 for a full SOC 2 prep engagement. Source, checked 2026-07-30.
Most of the list is exports and screenshots from tools you already run. An engineer with admin access and this page can answer nearly all of it.
Four defects that send evidence back
Scan the last column below and the same four problems repeat. None is a security weakness. Each one costs a round trip.
- A document where an export was asked for. Retyped data proves only the typing.
- No date or scope in the artifact. The auditor cannot tie it to the period.
- A subset instead of the full population. Picking the sample is the auditor's job.
- Timestamps in the wrong order. An approval after the change is no approval.
All 26 requests by control area
The wording is representative, not copied from one firm. Numbers run straight through so you can assign and chase each line by number. One caveat: we scope Security only, and a Security examination does not test availability commitments. Items 24 to 26 still come up, because recovering from a security incident sits inside the common criteria,3 but how deep they go depends on your scope.
Access control
| No. | Request | Send this | Returned when |
|---|---|---|---|
| 1 | List every user with production access as of period end, with name, role and the date access was granted | An export from the identity provider or cloud console, with the tool name and export date showing | A hand built spreadsheet. With no source or date, it only proves someone typed it |
| 2 | Show the latest user access review: who ran it, when, and what changed because of it | The review record plus the tickets or console entries for each removal it caused | A review that changed nothing. No removals at all looks like no review happened |
| 3 | Show that multi factor authentication is enforced for everyone using the production console | The settings page showing enforcement and the group it covers | A screenshot of your own MFA prompt. It shows you use it, not that it is required |
| 4 | For the sampled leavers in the period, show that access was removed and when | The offboarding ticket plus a timestamped deprovisioning log or directory record | A ticket closed as done with no system record. Done is a status, and the test needs a date |
| 5 | List current privileged and admin accounts, service accounts included, with a reason for each | The export, with a named human owner beside each service account | Service accounts missing. The auditor spots them in item 1 and asks again |
Change management
| No. | Request | Send this | Returned when |
|---|---|---|---|
| 6 | Provide every production change in the period, with its ID, date and requester | A full period export from the pipeline or ticketing tool, with the row count | A filtered list. Choosing the sample is the auditor job, so a trimmed list is not a population |
| 7 | For the sampled changes, show review and approval before deployment | The pull request or ticket with an approver, and a merge time later than the approval | An approval timestamped after the deploy. Sequence is the whole test |
| 8 | Show that only authorized people can deploy to production | An exported permission list from the repository or pipeline showing who can deploy | The written policy in place of the setting. The policy describes; the setting proves |
| 9 | Explain the emergency change process and show evidence for any emergency changes in the period | The written procedure, plus a ticket and after the fact approval for each emergency change | Answering none when item 6 shows a late Saturday deploy |
Monitoring and vulnerabilities
| No. | Request | Send this | Returned when |
|---|---|---|---|
| 10 | Provide the latest vulnerability scan of production, with its date and scope | The untouched scanner report with target range, date and counts by severity | A dashboard screenshot with no scope. Nobody can tell what was scanned |
| 11 | For sampled critical and high findings, show remediation and the close date | A rescan or ticket showing the fix, closed within the window your policy sets | A close date with no discovery date. Without both ends the window cannot be tested |
| 12 | Show that security events are logged and watched, including alert setup and alerts fired in the period | The alert rules plus real alerts with timestamps and the response logged for each | Rules that never fired. That shows intent, not a running control |
| 13 | Show that logs are kept for the period your policy states | The retention setting plus a query returning a real record from the oldest date you claim | The setting alone. A configured value and data still on hand are two different facts |
Incident response
| No. | Request | Send this | Returned when |
|---|---|---|---|
| 14 | Provide all security incidents in the period, or written confirmation that there were none | An export of the incident register, or a dated statement from the named owner if empty | A spoken none or a line buried in email. It must be a dated artifact |
| 15 | For each incident, give the ticket, timeline, root cause, and proof of resolution and communication | The incident record with detection time, actions, and who was told and when | A postmortem missing the detection time, the field the test depends on |
| 16 | Show that the incident response plan was tested or exercised in the period | The tabletop agenda, attendees, date and resulting findings | An exercise held before the window opened. The date decides coverage |
Vendors and subservice organizations
| No. | Request | Send this | Returned when |
|---|---|---|---|
| 17 | List third party vendors and subservice organizations, with the data each one handles | A vendor register showing data type and where each vendor sits against your system boundary | A list of everything you pay for. Scope here is data access, not spend |
| 18 | For sampled vendors, give the latest SOC 2 report or equivalent and proof it was reviewed | The report itself plus a dated note of who read it and what they concluded | A link to a trust page. A link is not a report, and a download is not a review |
| 19 | For vendors added in the period, show the risk assessment done before onboarding | The assessment record, dated before the contract or first data transfer | An assessment dated after go live. The control is preventive, so the date is the test |
People
| No. | Request | Send this | Returned when |
|---|---|---|---|
| 20 | List all employees and contractors hired in the period, with start dates | An HR system export for the period with contractors included | Contractors left off. If they can reach production, they belong in the list |
| 21 | For sampled new hires, show a background check completed around the start date | The screening provider record with the candidate identifier and date | A confirmation email with no name or date, which matches nobody in the sample |
| 22 | Show that each sampled employee accepted the security policy and code of conduct | A signed acknowledgment or a system record with each person acceptance date | A company wide announcement. Acknowledgment has to be per person |
| 23 | Show security awareness training completion for the period, with dates | The training platform completion report for every current employee | An enrollment list. Enrolled is not completed, and the column headers show it |
Backup and continuity
| No. | Request | Send this | Returned when |
|---|---|---|---|
| 24 | Show that production backups run on schedule and are monitored | The backup job settings plus run records for the period, failures included | Successes only. A year with zero failures looks edited |
| 25 | Show a restore from backup tested in the period, with date and result | A restore test record naming who ran it, what came back and how long it took | A claim that restores are tested regularly with no dated instance |
| 26 | Provide the continuity or disaster recovery plan and proof of its latest review or test | The current plan with a version date, plus an exercise record from inside the period | A solid plan last reviewed two years ago. The review date is the finding |
When each part of the list arrives
The list comes from the CPA firm doing the examination, not from a software vendor. It shows up in two waves and then produces a third. Knowing which wave you are in tells you what you can answer fast.
- Planning wave
- Short, and early. Policies, an org chart, your system description, the scope boundary. You either have these or you do not, so it is an early warning that costs nothing.
- Fieldwork wave
- The long one, sent once the period is fixed. Populations, samples, exports and screenshots. For a Type 2 it waits until the period closes, since the auditor samples from a complete population.
- Follow up wave
- Whatever the first two did not settle. Its size depends entirely on how well you answered the fieldwork wave.
For a Type 2 the timing is fixed. The population must span the whole 3-month observation window before sampling can start,2 which is why the observation period sets the earliest possible start of the examination.
What a slow answer really costs
Auditors work in blocks of time. When your response comes back incomplete, your file goes down and another client's comes up. You are not waiting for a reply. You are waiting for their next free block. The rework takes twenty minutes. The requeue takes days, and two of them can stretch a short examination into a month. How long SOC 2 takes shows where that month lands.
It works in your favor too. A complete, well formatted first reply keeps your file on the desk, and the follow up shrinks to a few clarifications. Same controls, same evidence, shorter calendar.
Missing evidence is worse than slow evidence. It becomes a test the auditor could not perform, and it lands in the report as an exception or a scope limitation that your buyers will read.2 What happens when an examination finds exceptions shows how that looks.
Answering it in one pass
None of this takes special skill. A handful of habits decides whether the follow up is four lines or forty.
- One named owner per line. Assign them the day the list lands. A line owned by a team is still open in week three.
- Export, never retype. Send the raw system output with the tool and date visible. The messy export beats your tidy copy.
- Show date and scope in every screenshot. Capture the whole window, clock and account name included, instead of cropping to one setting.
- Send full populations. Filtering first looks helpful and reads as selection.
- Answer what was asked. If item 12 wants fired alerts and you only have the rules, say so. A flagged gap gets discussed. A quiet swap gets returned.
Fixing weak controls before the list arrives removes whole rows from it. Five common control failures covers the ones to check first, and the access review template handles item 2.
The software is $199 a month, cancel any time, or $2,189 a year, pay for eleven months, get twelve. Audits go through our preferred pricing program, and we negotiate the fee on your behalf, including every Type 2, and you see the price in your account before you book, so a second round of requests does not change it. A slow reply costs you calendar, not money.
cybersoftware is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.
Your next step
See how many of these 26 lines you could answer today. The free readiness assessment takes about 15 minutes and returns a readiness assessment, score, gap list and one AI sample policy, so the gaps show up before an auditor asks. Then compare plans on the pricing page.
Questions
What does PBC stand for in SOC 2?
When do I get the PBC list?
Why does an auditor send evidence back?
What if we cannot produce an item?
Can software answer the PBC list for us?
Sources
Get audit-ready without a compliance team
The readiness assessment is free, with no payment and no card. When you are ready, the software is $199 a month, cancel any time, and audits go through our preferred pricing program. You can be audit-ready starting at about a week.
Start with a free readiness assessmentcybersoftware is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.