The PBC list is the auditor's list of everything they need from you. PBC stands for "provided by client" or "prepared by client", depending on the firm. For a first SOC 2 or ISO 27001 audit it can run to a long spreadsheet, and it arrives with dates attached.
The content of the requests is fairly predictable. What decides whether fieldwork takes two weeks or six is how the list is handled: who owns it, how requests get routed, and what gets checked before anything is sent. This article covers that handling, from the day the list arrives to the day the last item closes.
What arrives, and when
Most firms send the request list before fieldwork, often in two parts. The first part covers things that do not depend on sampling: policies, the system description, organization charts, vendor lists, configuration evidence, and populations. The second part comes after the auditor selects samples from those populations, and asks for evidence for each selected item.
That split matters for planning. The first wave is mostly documents you should already have. The second wave is where time goes, because each sampled item is its own small retrieval job. If the firm runs interim testing partway through the period, expect the same cycle twice. The way the auditor picks those items is covered in how auditors sample controls.
Ask for the list as early as the firm will share it. Some send a standard template during planning, which lets you check your evidence against it weeks ahead.
Triage the list before you answer anything
Resist the urge to start sending files the day the list arrives. Spend the first hour sorting it.
Assign every request an owner. One named person, not a team. The owner finds the evidence; the coordinator sends it.
Mark each request by readiness. Ready now, needs retrieval, needs creation, or unclear. "Needs creation" should be rare. If a request needs something created that should have existed during the period, flag it to the coordinator at once.
Group requests by owner and system. Six requests that all need exports from the identity provider are one session, not six.
Question the unclear ones on day one. Send the auditor a single message with every clarification question, rather than one at a time over two weeks.
Agree dates. Confirm the due date for each wave and push back early on any that cannot be met.
The tracker
A shared tracker is the single most useful tool in fieldwork. A spreadsheet works. A portal designed for it works better. Either way, it needs these fields:
Request ID, using the auditor's numbering so both sides refer to the same item.
Request text, copied exactly from the auditor's list.
Control or criterion the request relates to.
Owner, a named person.
Status: open, in progress, submitted, accepted, follow-up requested.
Due date, and the date submitted.
Files submitted, with names.
Auditor comments and follow-up questions.
The coordinator owns the tracker and is the only person who marks an item submitted. Requests that reach several inboxes, answered by several people in slightly different ways, are the most common cause of avoidable delay in fieldwork.
Before anything is sent
Every submission gets a short check by the coordinator. Five questions catch most problems.
Does it answer the request as written? Sending something adjacent in the hope it will do generates a follow-up request, and follow-ups are what stretch fieldwork.
Does it show the date and the source? A screenshot without a visible timestamp, or an export with no indication of which system produced it, will come back.
Does it cover the period or sample asked for? An access list from today does not answer a request for the population as of a date in the period.
Is it consistent with what you said before? If the walkthrough described three approvers and the evidence shows four, explain the difference in the submission rather than waiting for the question.
Does it contain anything it should not? See the next section.
Name files so they explain themselves
Use one convention for every file: the request ID, a short description, and the date of the evidence. For example, PBC-042_change-approvals_sample-07_2026-03-14.pdf. An auditor reviewing several hundred files should never have to open one to learn what it is.
Keep sensitive data out of the evidence
Auditors are bound by confidentiality, and their firms protect client data. You are still responsible for minimizing what you send.
Customer data rarely needs to leave your systems. Most controls can be evidenced with record IDs, metadata, or redacted extracts.
Personal data about employees, such as HR records for onboarding samples, should be limited to what the request needs. Agree with the auditor what fields are necessary.
Delivery belongs in the auditor's secure portal or an agreed shared repository, not email attachments.
Redaction must be real. A black box drawn over text in a document that still contains the text underneath is not redaction.
If a request seems to require sensitive data, ask the auditor what they need to see. Often a live demonstration on a screen share satisfies the request without any file changing hands.
When a request cannot be met
Sometimes the evidence does not exist. A quarterly review has no record for one quarter. An onboarding sample is missing its signed acknowledgment. A population cannot be produced because the system that held it was replaced.
Say so as soon as you know, in writing, through the coordinator. Explain what exists instead, if anything: a related record, a later instance of the control, or a different control that addresses the same risk. The auditor decides whether any of it is relevant. You do not.
Never create a record during fieldwork to stand in for one that should have existed during the period. A late record dated honestly, with an explanation, can be discussed. A record made to look contemporaneous is a misrepresentation, and it puts every other submission in doubt.
Reading a follow-up
When a submission comes back, read the follow-up as a description of what the auditor needs, not as a rejection. The usual reasons are predictable: the date is not visible, the population does not cover the full period, the evidence shows a different control, or the sample item was confused with another. Answering the exact question in one reply closes most follow-ups.
Run fieldwork as a weekly rhythm
A short status call, at least weekly, keeps the list moving. Use the tracker as the agenda: items overdue, items with follow-ups, items where the auditor's question is unclear. Owners who know their open requests will be read out tend to close them.
Prepare owners for the interviews and demonstrations that come with some requests, as described in preparing control owners for auditor interviews.
When the list closes, keep the tracker. Next year's list will look very similar, and a closed tracker with file names, owners and auditor comments is the best starting point for it. If you are still preparing for a first SOC 2, the SOC 2 readiness page covers what should be in place before the list arrives.
How TrustLynce helps
The auditor portal holds requests, evidence and findings in one place, with an owner and status for each request and a record of what was submitted. Auditors work in their own room rather than across several inboxes.