The PBC list is where most SOC 2 audits get painful
PBC stands for Prepared By Client. It's the list of evidence your auditor sends you at the start of fieldwork — or, if you're prepared, a list you build yourself before the auditor asks.
Most companies get the PBC list on a Monday and spend the next two weeks in fire-drill mode: digging through Slack for screenshots, trying to reconstruct access reviews that were never formally documented, begging vendors for reports that may no longer be available.
This guide covers what goes on the PBC list, what format the auditor expects, how auditors sample evidence, and how to build your evidence collection process so the next audit is a non-event.
How SOC 2 auditors actually use evidence
The auditor's job is to test whether each control in your control matrix was designed appropriately (Type I) and operating effectively over the audit period (Type II). "Operating effectively" means it ran consistently, not just once.
For population-based controls (things that happen for every event — every PR review, every offboarding, every access provision), auditors use statistical sampling. They'll ask you to produce the full population of events and then select a sample:
- Population of 25-50: auditor may select all or a large sample
- Population of 51-100: sample of 15-25
- Population of 101-250: sample of 30-40
- Population over 250: sample of 40-60
This matters because if you have an exception (a PR merged without review, an offboarding that took 3 days instead of same-day), the auditor may or may not sample it. But if you're building evidence, you need to assume they'll find the worst case. Clean up exceptions as they happen — don't count on sampling luck.
Evidence by criterion: what auditors expect
CC1 — Control Environment
Auditors are testing whether management sets the right tone and whether there's a functioning governance structure. Evidence here is mostly policy-level.
- Code of conduct: The document itself, plus acknowledgement records showing all staff signed it (HR system export or DocuSign records). Auditors will ask "when did you last update it?" — it should have been reviewed within 12 months.
- Org chart: Current org chart showing security roles and reporting lines. At minimum, it should show who the CISO/Head of Security reports to.
- Management review minutes: Evidence that management regularly reviews security performance. Even quarterly 30-minute meetings with documented security discussion counts. Export the meeting notes.
CC2 — Communication
- Security awareness training: Training completion report from your platform (KnowBe4, Wizer, Google Forms training quiz, etc.) showing that >90-95% of staff completed training within the period. Include new-hire training records showing training within 30 days of start date.
- Policy acknowledgements: Evidence that staff have read and acknowledged core policies. HR system records, DocuSign, or annual policy acknowledgement emails with response tracking work here.
CC3 — Risk Assessment
- Risk register/assessment document: A risk register or risk assessment document with a visible date. The auditor wants to see it was reviewed within the last 12 months and covers relevant threats (data breach, availability, vendor failure, etc.).
- Risk assessment methodology: How you assess risk (likelihood × impact matrix). Even a simple 5×5 matrix described in your methodology document satisfies this.
CC4 — Monitoring Activities
This criterion generates the most discussion about "what counts." The short answer: you need periodic testing evidence, not just configuration evidence.
- Pen test report: Full penetration test report from a qualified third-party tester. Must be within 12 months of the audit. Include remediation tracking showing how findings were addressed.
- Vulnerability scan reports: Credentialed scan reports run at least quarterly. Export the report (PDF or CSV) with the scan date visible. Show the remediation of any critical/high findings.
- Monitoring dashboards: Screenshot of SIEM or monitoring tool showing security events are being reviewed. If you use AWS CloudWatch/GuardDuty, export evidence that alerts are configured and reviewed.
CC6 — Logical and Physical Access (most-tested criterion)
This is where the auditor spends the most time. Expect detailed sampling across multiple sub-criteria.
| Sub-Criterion | Evidence Required | How to Export/Get It |
|---|---|---|
| CC6.1 — Access controls in place | IdP/SSO user list, RBAC configuration | Export from Okta/Azure AD/Google Workspace; IAM policy screenshot |
| CC6.2 — Access provisioning | New user provisioning tickets/records (sampled) | JIRA/ServiceNow tickets for new hires; access request approval records |
| CC6.3 / CC6.5 — Access removal | Termination access removal records (sampled) | Offboarding checklist completions; same-day revocation ticket with timestamp |
| CC6.1 — Quarterly access review | Quarterly access review with approval (sampled) | User list export + manager approval email/ticket; show users reviewed and any removed |
| CC6.6 — External access controls | Firewall/security group configuration | AWS security group export; VPN configuration screenshot; network diagram |
| CC6.7 — Encryption in transit | TLS enforcement configuration | Load balancer TLS policy screenshot; SSL Labs scan report; redirect configuration |
| CC6.1 — Encryption at rest | Database/storage encryption configuration | RDS encryption screenshot; S3 default encryption settings; KMS key policy |
| CC6.8 — Malware prevention | EDR/AV deployment coverage | EDR admin dashboard showing coverage %; MDM compliance report |
CC7 — System Operations
- Patch management records: Export showing that critical vulnerabilities were patched within your defined SLA (typically 24-48h for critical, 7d for high). Auditors will cross-reference against known CVE disclosure dates.
- Incident log: Your incident register covering the audit period. Even zero-incident periods need a log entry — "no security incidents in Q3" is an acceptable record.
- IRP tabletop exercise: Meeting notes from your annual IRP test. Include attendees, scenario, discussion points, and any improvements identified.
CC8 — Change Management
- PR/commit records: Auditors will ask for a list of production deployments during the period and sample specific PRs to verify they had code review and passing CI/CD checks. Export from GitHub/GitLab.
- Branch protection screenshot: Configuration showing branch protection is enforced (require PRs, no direct commits, status checks required, no force push).
- CI/CD pipeline logs: Evidence that automated checks ran and passed for production deployments. GitHub Actions run history export.
- Emergency change log: If you had emergency changes (changes that bypassed normal process), show they were logged and had retroactive review.
5 evidence mistakes that generate audit findings
1. Current-state only evidence for period controls
A screenshot of your MFA settings taken today doesn't show MFA was enforced throughout the 12-month audit period. For controls that must operate continuously, you need evidence that they were in place throughout — configuration with timestamps, period-start evidence, or audit trail exports.
2. Unterminated population lists
Auditors want to see the full population before selecting a sample. If you can't produce a complete list of all offboardings during the period, or all PRs merged to main, the auditor can't properly sample. Keep running logs, not just point-in-time records.
3. Self-approved changes
If your PR records show the same person authoring and approving code, the auditor will flag this as a violation of CC8.1 (no self-approval). This is one of the most common SOC 2 findings. Enforce no-self-approval in your branch protection rules before the audit period starts.
4. Policy documents without effective dates or approval records
An undated policy document doesn't satisfy the auditor's need to confirm it was reviewed within the period. All policy documents should have: version number, effective date, review date, approver. Review annually and update the date even if no content changed.
5. Training completion below 95%
An auditor who sees 82% training completion will ask what happened to the other 18%. If the answer is "they didn't complete it," that's a finding. If the answer is "these 3 people were on leave and completed it within 30 days of return," that's an acceptable exception. Document exceptions as they happen, don't reconstruct them during audit fieldwork.
Building an always-ready evidence library
The goal is to operate so that when the auditor asks for evidence, you can produce it in under an hour — not spend two weeks reconstructing it. The practices that make this possible:
- Named evidence owners: Every control has a person responsible for collecting evidence when it runs
- Standardised file naming: e.g.,
CC6.3-offboarding-2026-Q2.csv— criterion, type, date - Evidence folder structure: Organised by TSC criterion, with a subfolder per quarter
- Event-driven collection: When an access review happens, the owner exports the evidence immediately — not 3 months later
- Annual PBC pre-build: Before the audit starts, build your own PBC list and verify you have evidence for every item
Use the free SOC 2 Remediation Tracker to manage control status, assign owners, and track evidence collection. For the initial gap assessment, use the SOC 2 Gap Assessment Generator. For the management assertion letter your auditor needs from management, see the SOC 2 Management Assertion Letter Generator.