SOC 2 · Last updated 31 July 2026 · 9 min read

The SOC 2 PBC list, request by request

Every page about evidence requests defines the term and stops. This one prints the list, in the wording an auditor uses, with the reason each item comes back.

A SOC 2 PBC list is the evidence request list your auditor sends at the start of fieldwork. PBC stands for prepared by client. Every line is a document, an export or a screenshot you owe the examination, and the examination does not move until they arrive.

The list itself is below, numbered, grouped by control area, in the wording an auditor uses. The last column is the one nobody publishes: the defect that gets a response sent back. Read that column first.

Search this and you get definitions. What the acronym means, why auditors use one, a promise that the right platform makes it painless, then a demo button. The list is almost never on the page. So here it is. The requests are short and obvious once you see them. What costs you is the response, because an answer that is technically responsive and still fails the test is the most expensive thing you can send.

What prepared by client actually means

The name is doing real work. It marks the line between what the auditor produces and what you produce, and that line is not administrative. An auditor who assembled your evidence would be examining work they had a hand in. Independence does not survive that.¹

So the list reads like homework because it is homework. Every item is something only your company can generate, and nobody on the audit side may fill a gap on your behalf. You can ask what would satisfy a request. You cannot ask them to make it.

Who sends it, and when it lands

The list comes from the CPA firm performing the examination rather than from a platform. It arrives in two waves and generates a third. Knowing which one you are in tells you what is safe to answer quickly.

The planning request: Short, and it lands before fieldwork opens. Policies, an org chart, your system description, the boundary of what is in scope. Mostly documents you either have or do not have, which makes it cheap early warning about the ones you do not.
The fieldwork request: The long one, sent once the examination period is fixed. Populations, samples, exports and screenshots. For a Type 2 it cannot be answered until the period has closed, because the auditor selects from a population that has to be complete.
The follow up request: Everything the first two rounds did not settle. This is the wave you are making small, and its size is set by how the fieldwork request was answered.

For a Type 2 the timing is not negotiable. The population has to cover the full 3-month observation window before anyone can sample from it,² which is why the observation period sets the earliest date an examination can start rather than the date you would like.

The list, request by request

Twenty six requests follow, grouped the way auditors group them. The wording is representative rather than any single firm template, and the numbering runs straight through so a line can be assigned and chased by number instead of by description.

One caveat covers the whole table. Polara G.R.C. scopes Security only, and a Security only examination does not test availability commitments. Requests 24 through 26 still get asked, because recovering from a security incident sits inside the common criteria,³ but how deep they go moves with your scope.

Access control

No.	The request	What satisfies it	Why it comes back
1	Provide a complete listing of all users with access to the production environment as of the period end date, with name, role and date granted	A system generated export from your identity provider or cloud console, with the tool and date visible	A spreadsheet typed by hand. No source, no generation date, so it evidences your typing
2	Provide evidence of the most recent user access review, including who performed it, when, and what changed as a result	The review artifact plus the tickets or console records showing every removal it produced	A review with no follow through. One that found nothing and removed nobody reads as never performed
3	Provide evidence that multi factor authentication is enforced for all users of the production console	The configuration page showing enforcement scope and the group it applies to	A screenshot of your own login prompt. It proves you use MFA, not that everyone must
4	For the sample of employees terminated during the period, provide evidence that access was revoked and the date of revocation	The offboarding ticket plus a deprovisioning log line or directory record with a timestamp	A ticket marked done with no system record behind it. Done is a status; the test needs a date
5	Provide the current listing of privileged and administrative accounts, including service accounts, with the business justification for each	The export, with a named human owner beside every service account	Service accounts left out. The auditor finds them in the export from request 1 and asks again

Change management

No.	The request	What satisfies it	Why it comes back
6	Provide the complete population of changes deployed to production during the period, with change identifier, date and requester	An export from the pipeline or ticket system covering the whole period, with the row count	A filtered list. Selection is the auditor job, so a population you narrowed first is not a population
7	For the selected sample of changes, provide evidence of review and approval prior to deployment	The pull request or ticket showing an approving reviewer, with the merge timestamp after the approval	An approval dated after the deploy went out. Order of operations is the entire test
8	Provide evidence that the ability to deploy to production is restricted to authorized personnel	The repository or pipeline permission listing, exported, showing who can deploy	The written policy instead of the setting. A policy is a claim about the setting; the setting is the evidence
9	Describe your process for emergency changes and provide evidence for any that occurred during the period	The written procedure, plus the ticket and retroactive approval for each emergency change	An answer of none, when the population in request 6 shows a Saturday night deploy

Monitoring and vulnerability management

No.	The request	What satisfies it	Why it comes back
10	Provide the results of the most recent vulnerability scan of the production environment, including scan date and scope	The unmodified scanner report showing the target range, the date and finding counts by severity	A dashboard screenshot with no scope on it. The auditor cannot tell what was scanned
11	For a sample of critical and high findings, provide evidence of remediation and the date each was closed	A rescan or ticket showing the finding resolved, with a closure date inside the window your policy commits to	Closure evidence with no discovery date. Both ends are needed or the window cannot be tested
12	Provide evidence that security events are logged and monitored, including alert configuration and alerts triggered during the period	The alert rule configuration plus real alert instances with timestamps and the response recorded against each	Configuration with no firings behind it. A rule that never fired shows intent, not an operating control
13	Provide evidence that logs are retained for the period stated in your own policy	The retention setting, plus a query returning a real record from the oldest date you claim to hold	The setting on its own. Configuring a value and still holding the data are different assertions

Incident response

No.	The request	What satisfies it	Why it comes back
14	Provide the complete population of security incidents during the period, or written confirmation that none occurred	The incident register export, or a dated statement from the named control owner if it is empty	A verbal none, or a line in an email thread. The confirmation has to be a dated artifact
15	For each incident, provide the ticket, the timeline, the root cause and evidence of resolution and communication	The incident record carrying detection time, actions taken, and who was told at what point	A postmortem with the detection time missing, which is the field the test turns on
16	Provide evidence that the incident response plan was tested or exercised during the period	The tabletop agenda, the attendee list, the date, and the findings it produced	An exercise held before the period opened. Coverage is decided by date, and the date is outside the window

Vendor and subservice management

No.	The request	What satisfies it	Why it comes back
17	Provide the current listing of third party vendors and subservice organizations, with the data each one processes	The vendor register naming the data type and where each vendor sits relative to your system boundary	A procurement list of everything you pay for. Scope here is data access, not spend
18	For a sample of vendors, provide the most recent SOC 2 report or equivalent assurance obtained, and evidence that it was reviewed	The report itself plus a dated review note recording who read it and what they concluded	A link to the vendor trust page. A link is not a report, and downloading one is not reviewing it
19	Provide evidence of the risk assessment performed before onboarding, for vendors added during the period	The assessment record, dated before the contract or the first flow of data	An assessment dated after go live. The control is preventive, so the date is the whole test

People and HR

No.	The request	What satisfies it	Why it comes back
20	Provide the complete population of employees and contractors hired during the period, with start dates	An export from your HR system covering the period, with contractors listed alongside employees	Contractors left out. If they hold production access they belong in the population
21	For the selected sample of new hires, provide evidence that a background check was completed around the start date	The screening provider completion record, carrying the candidate identifier and the date	A confirmation email with no name and no date on it, which identifies nobody in the sample
22	Provide evidence that each sampled employee acknowledged the information security policy and the code of conduct	The signed acknowledgment, or a system record showing the acceptance date per person	A company wide announcement or a shared link. Acknowledgment is per person or it is not acknowledgment
23	Provide evidence of security awareness training completion for the period, with completion dates	The training platform completion report listing every current employee and the date each finished	An enrollment list. Enrolled is not completed, and the column headers give it away

Backup and continuity

No.	The request	What satisfies it	Why it comes back
24	Provide evidence that backups of production data run and are monitored, including the schedule	The backup job configuration plus success records covering the period, with failures left in	Successes only. A log with no failure in it across a year reads as a curated log
25	Provide evidence that a restore from backup was tested during the period, with the date and the outcome	The restore test record naming who ran it, what was restored, and how long it took	A statement that restores are tested regularly, with no single dated instance behind it
26	Provide the business continuity or disaster recovery plan and evidence of its most recent review or test	The current plan carrying a version date, plus the exercise record from inside the period	A good plan last reviewed two years ago. The document is fine, and the review date is the finding

The pattern under all twenty six

Look down the last column and the same four defects keep appearing. A document where a system export was asked for. An artifact with no date on it. A subset where the whole population was needed. A timestamp in the wrong order. None of them are security problems, and all of them cost a round trip.

Why the first response sets the length of the engagement

An auditor works engagements in blocks. When your response comes back incomplete, your file goes down and somebody else comes up, so what you wait for is not a reply. You wait for the next block of their time.

That gap is the real cost of a round trip. The rework is twenty minutes. The requeue is days. Two of those can turn a short examination into a month of calendar, and the calendar is usually what your customer was asking about. How long a SOC 2 takes lays out where the examination sits in the sequence.

It runs the other way too. A complete, correctly formatted first response keeps your file in front of the auditor, and the follow up shrinks to a handful of clarifications rather than a second full pass. Same controls. Same evidence. Different calendar.

Most of an auditor’s hours on a small engagement go into chasing evidence that was never organized, not into judging your controls.

There is a worse outcome than rework. Evidence that never arrives does not quietly disappear. It becomes a test the auditor could not perform, and that lands in the report as an exception or a scope limitation where your buyers read it.² What happens when an examination finds exceptions covers how those look on the page.

How to answer it once

None of this is clever. It is a handful of habits that decide whether the follow up request is four lines or forty.

Assign one named owner per numbered line on the day the list arrives. A request owned by a team is owned by nobody, and it will be the one still open in week three.
Export, never retype. If the auditor asked for a listing, send the system output with the tool and generation date visible. A tidier spreadsheet you built by hand is weaker evidence than the messy export behind it.
Put the date and scope inside every screenshot. Capture the whole window, including the clock and the account or environment name, rather than cropping to the setting you want to show.
Send populations complete and let the auditor select. Filtering before you send looks helpful and reads as selection, which is the one job that is not yours.
Answer the request that was written. If item 12 asks for triggered alerts and you have only the configuration, say that plainly instead of sending the configuration and hoping. A flagged gap gets discussed. A quiet substitution gets returned.

Most of these requests map to controls that fail for ordinary reasons. Five control failures covers the ones that come up repeatedly, and fixing them before the list arrives removes whole rows from it.

Where this sits in what you pay

Type 1 is $4,000 one time, and that covers the first examination and the engagement fee for the independent partner auditor, so a second round of evidence requests never produces a second invoice. Type 2 is $600 per month on a 12-month term, and each examination is $5,000. What a slow response costs you is calendar, not money.

Polara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.

Questions

What is a PBC list in a SOC 2 audit?

PBC stands for prepared by client. It is the numbered list of documents, exports and screenshots the CPA firm performing your examination asks you to produce. An auditor cannot create your evidence and remain independent, so every factual artifact about your company has to come from you. The list is that obligation written down.

When does the auditor send the PBC list?

Usually twice. A short planning request arrives before fieldwork opens and covers scope, policies and system boundaries. The main request arrives once the examination period is fixed. For a Type 2 it cannot be fully answered until the observation period has closed, because the auditor samples from a population that has to be complete.

Why does evidence get rejected in a SOC 2 audit?

Almost always for a reason that has nothing to do with your security. The common ones are a spreadsheet typed by hand where a system export was asked for, a screenshot with no date or scope visible, a filtered list where the auditor needed the whole population, and an approval timestamped after the change it approved.

What happens if you cannot produce a requested item?

Say so early and say so in writing. Evidence that never arrives becomes a test the auditor could not perform, and that lands in the report as an exception or a scope limitation rather than quietly disappearing. Telling the auditor in week one leaves room to offer something equivalent. Telling them at the end does not.

Does a compliance platform answer the PBC list for you?

It can assemble and index most of it, and it can pull system exports directly, which removes the largest category of rework. It cannot answer for you. Someone at your company still confirms that each artifact is what it claims to be, because the assertion about your own system is yours to make.

Sources

AICPA Code of Professional Conduct AICPA. Independence, integrity, commissions and referral fees. Checked 1 August 2026.
Statements on Standards for Attestation Engagements AICPA. The attestation standards a SOC 2 examination is performed under. Checked 1 August 2026.
TSP Section 100, Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy AICPA. The criteria themselves, including the common criteria every SOC 2 report covers. Checked 1 August 2026.

Get audit-ready without a compliance team.

$4,000 one time for SOC 2 Type 1, with the first examination and the auditor engagement fee included. audit-ready starting at about a week.

Get started