Populating an Evidence Request List for SOC 2 Fieldwork
Organize your evidence request by mapping each item to its Trust Services Criterion.
A SOC 2 evidence request list, whether the audit firm calls it a PBC list or an IRL, is the itemized set of documents and records the auditor needs before signing off on a report. It shows up the day fieldwork starts, and it effectively becomes the project plan for everyone who touches security, IT, or compliance for the next several weeks. The list looks chaotic at first glance because it spans governance, technical controls, HR records, and vendor contracts all at once. It stops looking chaotic the moment someone maps each line item back to its Trust Services Criterion, because that mapping is what the auditor used to build the list in the first place.
That's the organizing idea behind everything below: the request list is a control-by-control checklist dressed up as a folder full of PDFs.
How Type I and Type II audits shape what the list asks for
Type I asks a narrow question: does the control exist, and was it designed to work on the day someone looked at it? Evidence for a Type I report is thin by comparison, mostly policies, procedure documents, and a handful of samples proving a control was in place. Nobody's asking whether the control ran for a year. Nobody's asking whether it ran twice.
Type II asks the harder question, and it asks it about a stretch of time, usually six to twelve months. Every control needs evidence across that entire window, not a screenshot from one Tuesday in March. Auditors can't check every single event that happened during the period, so they sample: they pull a population (every access change, every deployment, every vulnerability scan) and test a subset drawn from it. That's why population listings matter so much. If the full universe of events is wrong or incomplete, the sample drawn from it is worthless no matter how clean the sampled items look.
The practical shift for teams prepping a Type II is thinking in cadence. What ran monthly? What ran quarterly? What ran once a year, and does a record exist for that one time it ran? And when something broke mid-period and got fixed, Type II wants the fix documented, ticket or commit, sitting right next to the finding that triggered it. A gap without a documented repair reads very differently to an auditor than a gap that shows the team caught and closed it.
How the Trust Services Criteria map to evidence categories
Five criteria exist: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Only Security, referred to as the Common Criteria, is mandatory. Everything else is a scoping choice, and scoping choices are where evidence volume either stays manageable or balloons.
The Common Criteria runs from CC1 through CC9. CC1 through CC5 cover governance and risk: board oversight, risk assessment, monitoring, control activities. CC6 through CC9 cover the operational stuff: access, system operations, change management, and vendor risk. Before fieldwork starts, mapping every planned evidence item to its CC family turns the list from an intimidating pile into a sorted stack. CC6 alone tends to be the heaviest single group in the whole framework, which gets its own section below because it deserves one.
Add Availability, Processing Integrity, Confidentiality, or Privacy to the scope, and each one layers its own evidence requirements on top of the Common Criteria foundation. Scoping decisions made months before fieldwork begins are the real determinant of how many files end up in the evidence portal.
Worth noting: the criteria text itself hasn't changed since 2017. The AICPA's 2022 update revised the points of focus, the interpretive guidance auditors use to judge whether a control meets the bar, to account for cloud infrastructure, supply chain exposure, and increasingly, AI-related risk. The rules stayed the same. The bar auditors hold evidence to shifted.
Design evidence: the policy and procedure layer every control needs
Unlike ISO 27001, SOC 2 has no mandated document list. There's no checklist of exact titles an auditor demands. In practice, though, a coherent policy suite shows up in nearly every audit: access control policy, incident response policy and plan, data classification and handling policy, vendor management policy, change management procedures, and a business continuity and disaster recovery plan.
Having the document isn't the finish line. Each policy needs a record of formal review, meaning a date and a named approver, plus evidence that the people governed by it actually acknowledged it. An unsigned policy or one that hasn't been revisited since a prior calendar year gets treated as a design gap. The auditor's logic is straightforward: if the organization hasn't formally adopted the document, the control it describes isn't designed effectively, no matter how good the language reads on the page.
This layer of evidence satisfies a Type I audit on its own. For Type II, it's the floor. The ceiling is proving the policy actually governed behavior for months on end.
CC6 evidence in practice: access provisioning, reviews, and deprovisioning
CC6 carries the biggest evidence load in the Common Criteria, and the reason is structural: it's a cluster of sub-controls, each demanding its own trail of artifacts across the full observation period.
Unique user identification needs an account listing showing nobody's sharing a generic login. Role-based provisioning needs access request and approval records tied to the employee's job role at the moment they were onboarded. Multi-factor authentication needs configuration evidence, and for Type II, proof MFA stayed enforced continuously rather than getting toggled on for a screenshot and off again. Periodic access reviews need signed attestations from managers; verbal confirmation that "yeah, we checked" does not count, and unsigned reviews are one of the most common findings in this entire domain. Deprovisioning needs offboarding tickets for sampled departed employees showing access got pulled within the policy's stated window, and physical access needs badge logs or door-system exports covering the period.
Before an auditor ever asks, running a terminated-user report against the active account list is worth the twenty minutes it takes. Finding a former employee with live VPN access during fieldwork extends the audit; finding it the week before does not.
CC8 and CC9 evidence: change management trails and vendor risk records
CC8 wants a traceable line from pull request to approval to test result to deployment. Automation tools capture the commits and the CI/CD logs without much effort, but the human decision points, who approved it, who signed off on testing, how an exception got handled, are what CC8 is actually testing. Emergency changes need retroactive approval recorded in the ticket itself. A Slack thread saying "yeah go ahead, we'll document later" doesn't count as evidence because it can't be surfaced the way a ticket can. Auditors sample across the full period, so a change process that ran cleanly in January and fell apart by September will surface in the sample regardless of how good January looked.
CC9 covers vendors and third parties, and the evidence spans the whole relationship: initial due diligence, contract language requiring security controls, and ongoing monitoring for as long as the relationship runs. Most auditors expect an annual pull of SOC 2 reports or ISO 27001 certificates from critical vendors, and a missing report for the observation year is a common gap teams don't catch until fieldwork is underway. Third-party breaches make up a significant share of overall breach activity, which is exactly why CC9 evidence isn't treated as paperwork theater. For companies running or buying AI models, CC9 now increasingly touches model behavior monitoring, retraining governance, and the risk profile of whatever LLM provider sits in the stack. Auditors are asking about this more with each cycle.
Governance, people, and continuity controls: the evidence categories teams most often under-document
CC1 through CC5 want proof that leadership actually looks at security, not just that a policy says leadership should. Board minutes, a risk committee charter, a documented reporting cadence, something showing the topic reached a room with decision-making authority in it. Risk assessments need a date and a formal approval, and a register from two years ago doesn't satisfy a current observation period no matter how thorough it was when written.
People controls trip teams up in quieter ways. Background check records for new hires, training completion tied to named individuals rather than an aggregate pass rate (training acknowledgment tracking is one of the more frequently cited exceptions in this area), and performance evaluations as evidence that personnel oversight is ongoing rather than theoretical.
Incident response and continuity planning have a similar trap: a plan that's never been tested is a design-only control. Auditors want tabletop exercises and disaster recovery tests with documented outcomes, who ran it, what happened, what got fixed afterward. Backup restoration needs proof the restore completed, not just proof a backup job fired on schedule. A backup that runs every night for a year and has never once been restored is a control nobody has actually verified.
How auditors stage population requests and sample selections
Auditors work in two moves. First, the population request: every single instance of a given control activity during the period, every access change, every change ticket, every scan. Second comes the sample, pulled from that population, where the auditor tests individual items and expects supporting evidence for whichever ones got picked.
A control only counts as having operated effectively if it ran consistently across the whole period. One undocumented gap in an otherwise spotless recurring control can still generate an exception. Incomplete logs or missing tickets are the most common reason auditors send a follow-up request, because a gap in the population makes the auditor question whether the whole population can be trusted.
The practical move here is checking every item in a population listing for retrievable backup evidence before submitting it. A clean population of forty items beats a messy population of two hundred where sixty of them raise questions. And auditor expectations on this front have shifted: for anything a system can log continuously, periodic snapshots increasingly read as thin. Continuous monitoring output, SIEM logs, automated scan reports, is the preferred evidence now wherever it's available.
Naming, folder structure, and version control for evidence submissions
Most audit firms run a shared portal, a secure folder or dedicated platform where files get uploaded against a numbered request list. Organizing that folder by CC family before fieldwork even starts (something like /CC6_Access/, /CC8_Change_Management/, /CC9_Vendor_Risk/) with subfolders by sub-control saves both sides a lot of email.
File naming matters more than it sounds like it should. An export named export_final_v2.csv tells the auditor nothing; they have to open it to find out what it is, and multiply that across a few hundred files and the delay adds up fast. A filename that includes the system, the date range, and the record type reads as organized on sight and cuts down on follow-up questions almost entirely.
Version control matters for the same reason: every document needs a clear date so the auditor can confirm it actually falls inside the observation window. Retention policy should stretch across the full observation period at minimum, and ideally align with whatever customer contracts or continuity requirements already demand, which for a lot of companies means multiple years of retrievable records. A single central repository with access controls prevents the very specific headache of two teams submitting two different versions of the same document through two different channels.
The exceptions that most often delay report issuance
Incomplete evidence and access-related issues delay a meaningful share of SOC 2 reports every cycle, and they show up as patterns, not flukes.
The AICPA recognizes three kinds of exception, and each one gets fixed differently. A design deficiency means the control was never built to do its job, no MFA requirement on production accounts, say, and fixing that means building the control, not hunting for missing paperwork. An operating deficiency means the control exists but didn't run consistently, a quarterly access review that got skipped one quarter, and remediation means showing the control has since run reliably. An instance exception is a single failure inside an otherwise consistent control, one change ticket missing an approval signature, and the auditor's real question is whether that's isolated or a sign of something systemic underneath.
The gaps that keep showing up, cycle after cycle: access reviews completed but never attested in writing, terminated employees still holding active accounts past the policy window, training records showing enrollment but not completion, emergency changes with no retroactive approval trail, vendor SOC 2 reports nobody collected for the year in question, and DR tests with no documented result. None of these are exotic. All of them are avoidable with a checklist run a few weeks before fieldwork starts.
When a sampled item fails, the auditor's next move is figuring out whether it's a one-off or a pattern. A pattern finding does far more damage to the report than a single clean miss, which is exactly why the instance-versus-systemic distinction matters so much during remediation conversations.
Where automation fits, and where it doesn't
Automation earns its keep on the parts of this process that are mechanical: pulling account listings, capturing CI/CD logs, exporting badge data, generating population lists straight from the source system instead of someone building a spreadsheet by hand. Continuous monitoring tools that auditors increasingly favor over point-in-time screenshots are, by definition, automated; a SIEM either logs the event or it doesn't, and nobody has to remember to take a screenshot on the right Tuesday.
Automation has limits, though. The human decision points don't disappear. Someone still has to approve the access request, sign the review attestation, and authorize the emergency change after the fact. The auditor is testing whether a person actually looked, actually approved, and actually left a record of having done so, not whether a system exists that could theoretically catch a problem. Automation shrinks the pile of manual evidence gathering, but the list of things a human being needs to sign off on stays exactly as long. Mistaking one for the other is how a team ends up with a beautifully automated pipeline and a stack of unsigned access reviews sitting right next to it.
