A SOC 2 evidence request is an auditor's line-item list of documents, screenshots, logs, and configuration exports that prove a control is operating, not just written down. You answer it by mapping every requested item to the Trust Services Criteria it supports, pulling artifacts dated inside the current audit period, and assigning one named owner per item before the review window opens. Auditors reject evidence that is undated, screenshotted months ago, or missing the system context that shows who took the action and when.
HiDocument is a document analysis tool that summarizes, extracts data from, and lets you chat with PDFs, Word files, and images, including in bulk. Compliance teams use it to work through evidence folders faster during audit season, which is the workflow this article walks through.
What is a SOC 2 evidence request?
A SOC 2 evidence request, often called a PBC list ("provided by client"), is the spreadsheet or portal checklist your auditor sends at the start of fieldwork. Each row names a control, the evidence type needed to test it, and the date range it must cover. For a Type II report, evidence has to span the entire audit period, typically 3 to 12 months, not a single point in time.
The request usually groups items by control family: access management, change management, vendor management, incident response, and monitoring. A mid-size SaaS company can expect 60 to 150 individual line items on a first-year Type II audit, dropping as the control set matures in later years.
What evidence do auditors actually ask for?
The AICPA's Trust Services Criteria define five categories: security, availability, processing integrity, confidentiality, and privacy. Security is the only mandatory category; the other four apply only if you scoped them into the audit. Each category maps to a different flavor of evidence.
| Trust Services Criteria | Typical evidence requested | Common source |
|---|---|---|
| Security (Common Criteria) | Access review logs, MFA enforcement screenshots, offboarding tickets | Identity provider, HR system |
| Availability | Uptime reports, backup test logs, incident postmortems | Monitoring platform, on-call tool |
| Processing integrity | Data validation rules, error-rate reports, change approval records | Application logs, ticketing system |
| Confidentiality | Encryption configuration exports, data classification policy, NDA records | Cloud console, contract files |
| Privacy | Consent records, data subject request logs, retention schedule | Privacy platform, policy documents |
How do you organize evidence before the audit starts?
Waiting for the PBC list to arrive before you start collecting is the single most common reason audits run long. Build the evidence trail as you go instead.
- Pull last year's PBC list (or a SOC 2 readiness checklist) and pre-map every item to the system that produces it.
- Assign one named owner per control, not a team — a shared inbox does not answer an auditor's follow-up question.
- Set a recurring calendar reminder to capture point-in-time evidence (access reviews, backup tests) on the same day each month.
- Store evidence in a folder structure that mirrors the control list, dated in the filename, not just the file metadata.
- Run a mid-period self-check: pull three random controls and confirm the evidence on file would satisfy a stranger reading it cold.
What goes wrong when evidence isn't ready?
Auditors flag the same handful of problems every cycle. A screenshot with no visible date or system URL gets rejected on sight — the auditor cannot confirm when or where it was taken. Evidence that covers only the last week of a twelve-month period leaves gaps the auditor has to write up as exceptions. Access review spreadsheets that list who has access but not who approved the review are treated as incomplete. And evidence spread across five different tools with no index means every request turns into a scavenger hunt, which is where audit timelines actually slip.
How do you handle evidence requests without drowning in PDFs?
A first-year SOC 2 evidence request commonly arrives as 80 to 150 separate files — exported logs, signed policies, ticket threads saved as PDFs, vendor SOC 2 reports you have to review yourself. Reading each one manually to confirm it covers the right date range and the right control is where compliance teams lose days. HiDocument's bulk mode lets you upload a folder of evidence at once and get a per-file summary of what each document actually shows, so you can confirm coverage before you hand the batch to the auditor instead of after they reject it. Document chat is useful for the specific case of a 40-page vendor SOC 2 report you were handed as evidence of a subprocessor's controls — you can ask it directly which Trust Services Criteria the report scopes in, rather than reading the whole thing.
See HiDocument's plans if you're weighing whether a document tool is worth adding to an existing audit workflow.
Is it worth paying for a document tool just for audit season?
The honest objection is that audit season is a few weeks a year, and most teams already have a GRC platform tracking control status. That's a fair point if your GRC tool actually reads the evidence for you — most don't; they store files and let a human open each one. The gap HiDocument fills is narrower: getting through a stack of evidence files fast enough to catch a coverage gap before the auditor does, and Pro's 10-file bulk limit is sized for exactly that kind of batch, not a full document management system. If your evidence set is under a dozen files a cycle, the free tier's 10 analyses a month likely covers it without a subscription.
What's the fastest way to start organizing evidence today?
Pick one control family — access management is usually the largest — and pull every piece of evidence for it from the current audit period into a single folder. Create a free HiDocument account and upload that folder; the summary view will tell you within a few minutes whether every file has a visible date, system source, and approver, which is exactly what the auditor checks first. HiDocument does not replace legal or audit judgment — it is a document tool, not your auditor or your counsel, so treat its summaries as a first pass, not a final answer.
For the records-management side of the same audit — how long you're required to keep the evidence itself — see our document retention schedule guide. And if you're building the underlying control program rather than just responding to one audit, our piece on building a compliance program for a growing startup covers the sequencing.
Frequently Asked Questions
What is a PBC list in a SOC 2 audit?
PBC stands for "provided by client." It is the spreadsheet or portal checklist an auditor sends listing every control, the evidence type needed to test it, and the date range that evidence must cover. Most teams receive it at the start of fieldwork, though pre-mapping it earlier speeds up the audit.
How far back does SOC 2 Type II evidence need to go?
Type II evidence must cover the entire audit period the report is scoped to, commonly 3 to 12 months, not a single snapshot. A Type I report only needs evidence as of one point in time, which is why Type I audits move faster but carry less assurance for customers.
Why do auditors reject screenshots as evidence?
Auditors reject screenshots that lack a visible date, system URL, or user context because they cannot confirm when or where the action happened. A usable screenshot shows the date, the system name, and enough surrounding detail to tie it to a specific control and time period.
Do all five Trust Services Criteria apply to every SOC 2 audit?
No. Security, called the Common Criteria, is the only mandatory category. Availability, processing integrity, confidentiality, and privacy are added only if the company scopes them in, based on what its customers and contracts actually require.
How many evidence items does a typical first SOC 2 audit require?
A mid-size company's first Type II audit commonly involves 60 to 150 individual evidence line items across all in-scope control families. That number usually drops in later-year audits once controls and evidence collection are routine.
Can a vendor's own SOC 2 report count as evidence in your audit?
Yes, when a vendor handles data on your behalf, its SOC 2 report is often accepted as evidence of that subprocessor's controls. Your auditor will still expect you to show you reviewed the report and confirmed it covers the relevant Trust Services Criteria.