Compliance Artifacts

The auditor PBC list, explained (with example)

A PBC list — “prepared by client” list — is the itemized request list your audit firm sends before fieldwork: every document, listing, and record you owe them, numbered and grouped by control domain. Here’s when it arrives, what’s on it, and how to run the response without turning your engineers into full-time evidence clerks.

Talk to a Compliance Engineer

Last updated July 26, 2026

What a PBC list is

“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.

When it arrives, and how it’s organized

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.

What a PBC list looks like

Excerpt — initial PBC request list for a SOC 2 Type II (condensed)

A. Governance and organization. A-1: current organization chart showing security reporting lines. A-2: information security policy set, with approval dates and owners. A-3: minutes or records from the most recent management review of the security program.

B. Human resources. B-1: full population of hires and terminations during the period, exported from the HR system. B-2: security awareness training completion records for the period. B-3: signed acceptable use acknowledgments for selected personnel (samples to follow).

C. Logical access. C-1: user access listings for in-scope systems — production cloud, identity provider, code repository — showing roles and admin flags, system-generated with visible timestamps. C-2: completed access review records for each quarter in the period. C-3: offboarding evidence for selected terminations (samples to follow).

D. Change management. D-1: full population of production changes for the period, from the deployment pipeline or ticketing system. D-2: change tickets showing approval and testing for selected changes (samples to follow).

E. Vendor management. E-1: vendor inventory with criticality ratings. E-2: the most recent security review or SOC report evaluation for selected critical vendors.

F. Operations and resilience. F-1: backup configuration and a completed restore test from the period. F-2: incident tickets for the period, with post-incident reviews where applicable. F-3: business continuity and disaster recovery plan, plus evidence of the most recent test.

Why PBC season derails teams

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.

Running the response without derailing engineering

One coordinator, one tracker, and every row mapped to a source before anyone collects anything.

Normalize the list into one tracker

Import the auditor’s spreadsheet as-is and add four columns: owner, evidence source, internal due date, delivery status. Keep the auditor’s IDs — every conversation for the next two months references them.
Assign one owner per row — a person, not a team

Name an individual for each item, plus a single coordinator who is the only person the auditor contacts. Engineers answer the coordinator in scheduled batches, not the portal at random hours.
Map every row to its evidence source before collecting

Most rows resolve to a GRC platform export, a system report, or a document that already exists. Marking sources first eliminates duplicate pulls and surfaces the genuinely missing items while there’s still time to fix them.
Sequence by what unblocks the auditor

Populations first — sample selection waits on them. Documents next, per-sample evidence last. Set internal due dates a week ahead of the auditor’s so someone reviews before anything ships.
Review before you upload

Confirm each export shows the system, the date range, and the complete population; redact secrets; check that the artifact answers the request that was actually asked. Sloppy uploads breed follow-up rows.
Batch questions and flag gaps honestly

Collect clarifications into one weekly thread, and mark not-applicable or missing items with a short rationale instead of silence. Auditors handle disclosed gaps far better than discovered ones.

Answering the list from evidence that already exists

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.

Frequently asked questions

What does PBC stand for in an audit?

“Prepared by client” — some firms say “provided by client.” Either way it names the same artifact: the master list of documents, populations, and records the client owes the audit firm, tracked item by item through the engagement.

When should we ask for the PBC list?

At engagement signing, and no later than kickoff. Firms can share at least a preliminary list early, and every week you hold it before fieldwork is a week of collection you control rather than react to. If an auditor can’t produce any list until fieldwork begins, push back.

Can we mark PBC items as not applicable?

Yes — with a one-line rationale. “No production changes to this system during the period” or “handled by our subservice organization” are normal answers, and a few per engagement is expected. What burns credibility is silence, or an N/A that turns out to mean nobody checked.

How is the PBC list different from the tasks in Vanta or Drata?

Platform tests are continuous and generic to the framework; the PBC list is specific to this auditor, this period, and this sample selection. The platform usually holds most of the raw material, but the list dictates format, populations, and dates — treat the platform as the warehouse and the PBC list as the order form.

What happens if we miss PBC due dates?

Fieldwork stalls in sequence: late populations delay sample selection, late samples delay testing, and open items pile into the final weeks — which is how report dates slip past the deals waiting on them. Chronic lateness also invites deeper skepticism; an auditor who waits three weeks for an access listing starts wondering why it took three weeks.

Keep going

SOC 2 Framework ISO 27001 Framework Audited Compliance SOC 2 System Description

Hand us the request list

Agency engineers run the PBC tracker, pull the evidence, and manage the auditor’s follow-ups — your team stays on the roadmap. Top-ranked Vanta & Drata partner · 1,000+ companies served since 2021 · 4.9/5 on G2.