The auditor PBC list, explained (with example)

“PBC” stands for “prepared by client,” a term audit firms carried over from financial auditing, where the schedules a client assembles for the auditor are literally prepared by the client. In a SOC 2, ISO 27001, or HITRUST engagement, the PBC list is the master request list issued before fieldwork: every policy, org chart, system export, population, and record the auditor needs you to produce, each with an ID, a description, and the period it must cover — delivered as a shared spreadsheet or a request queue in the firm’s audit portal.

It’s worth separating the PBC list from the evidence your GRC platform tracks all year. Platform tests are continuous and framework-shaped; the PBC list is engagement-shaped — this auditor, this period, this sampling approach. The two overlap heavily, and that overlap is your leverage: in a well-run program, most PBC rows resolve to evidence that already exists somewhere.

Expect the initial list two to six weeks before fieldwork, at or shortly after the kickoff call — and expect it to grow. Auditors work in waves: the first wave requests documents and full populations (every hire in the period, every production change, every vendor). From those populations the auditor selects samples and issues a second wave — the onboarding records for these five hires, the tickets for these ten changes. A trickle of “open items” follows through fieldwork as testing raises questions.

Organization mirrors the control domains: governance and policies, human resources, logical access, change management, operations and monitoring, vendor management, business continuity. Each row carries the request, the coverage period, and columns for owner, status, and delivery date. However the firm formats it, that spreadsheet becomes the engagement’s shared source of truth — the report date moves at the speed of its slowest row.

The list looks administrative and lands operational. Every row fans out to a system owner — access listings need a platform engineer, the change population needs whoever owns the pipeline, the restore test needs infrastructure — and without coordination the auditor’s spreadsheet quietly becomes a six-week work queue for your most senior people, delivered as ad-hoc pings. The two failure modes that hurt most: evidence pulled twice because nobody recorded where it came from, and populations delivered late, which delays sampling, which delays everything queued behind it.

Stalled PBC responses are also the most common way audit timelines slip — auditors can’t test what hasn’t arrived, so fieldwork extends and open-item lists compound. If you’re reading this with the first wave already overdue, the triage playbook in behind on audit evidence is the companion piece to this page.

The strongest position is the boring one: the list arrives and nearly everything on it is already sitting in your GRC platform or systems of record, collected continuously across the period. That’s the difference between PBC season as a six-week disruption and PBC season as an export exercise — and it’s the operating model Agency runs for clients. Our engineers own the tracker, pull the artifacts, quality-check each one against what the request actually asks, and handle the auditor’s follow-ups; your team gets pulled in only for the handful of items that truly need engineering hands.

That year-round discipline is the substance of managed compliance services: when evidence stops being seasonal, the request list stops being a fire drill. The auditor still sends sixty rows — they just get answered from stock instead of from sprints.