The SOC 2 evidence list: what auditors ask you to produce
Auditors test SOC 2 controls by asking for artifacts that prove they actually operated. Here is the evidence typically requested by control area, why Type 2 raises the bar, and how automation cuts the manual load.
How evidence requests actually work
A SOC 2 examination is an evidence exercise: the auditor maps each control to one or more Trust Services Criteria, then asks you to prove the control operated as described. Requests usually arrive as a structured list, often called a PBC ('provided by client') list, organized by control area. For a Type 1 report the auditor looks at design and a point in time, so a current configuration screenshot or a single approval can suffice. For a Type 2 report the auditor tests operating effectiveness across a period, commonly three to twelve months, and will sample events from across that window. The practical implication is that you cannot assemble Type 2 evidence the week before fieldwork; the artifacts have to exist as a byproduct of running the business throughout the period.
Access, identity, and authentication
Logical access is the most heavily evidenced area, mapping to common criteria around access controls (the CC6 family). Expect to provide a current user list from your identity provider, MFA enforcement settings and configuration, password or authentication policy settings, and proof that privileged access is restricted and reviewed. Periodic access reviews are a frequent sampling target: for a twelve-month Type 2 period an auditor commonly wants to see four quarterly reviews, each showing who reviewed, what systems were covered, what discrepancies were found, and how they were remediated. Joiner and leaver records are tested alongside this, so be ready to show a sample of onboarding events with manager approval and account creation, and offboarding events with deprovisioning timestamps that fall inside the SLA your policy promises.
Change management and the SDLC
Auditors want to confirm that changes to production are authorized, reviewed, and traceable, which maps to the CC8 change-management criteria. The typical artifacts are change tickets or pull requests showing a description, peer review or approval, and a link from the change to its deployment. In modern engineering shops this is often satisfied with branch-protection rules requiring approved PRs, CI/CD pipeline logs, and ticketing records from a tool like Jira or Linear. Expect the auditor to pull a sample of production changes from across the period and trace each one back to its approval. Separation between the person who writes a change and the person who approves or deploys it is a recurring point of focus, so be ready to explain how your workflow enforces it.
Monitoring, vulnerabilities, and resilience
The CC7 criteria around system operations drive requests for logging and monitoring evidence, alert samples, and your incident response records, including any incidents that occurred and how they were handled. Security testing typically shows up as recurring vulnerability scan results plus a penetration test report; note that a pen test is not strictly mandated by the AICPA, but auditors widely treat it as the expected evidence for ongoing risk evaluation and it is hard to demonstrate maturity without one. If your scope includes the Availability category, expect requests for backup configurations and, importantly, evidence of a restore or recovery test rather than just the existence of backups. Business continuity and disaster recovery plans, along with any test or tabletop results, round out this area.
Risk, vendors, people, and the policy trail
Governance evidence ties the program together. Auditors request your documented risk assessment and its results (CC3), your vendor and third-party reviews (CC9, which the 2022 revised points of focus sharpened around vendor-derived risk), and your policy set with proof of formal approval and employee acknowledgments. People controls include security awareness training completion records and, where applicable, background-check evidence for new hires. Across all of these, the auditor is checking that the artifact is dated within the period, attributable to a named owner, and consistent with the related policy. The cleanest programs treat every control as a question 'what artifact proves this happened, and when?' and make sure that artifact is generated automatically.
How automation reduces the effort
This is where compliance automation platforms earn their keep. Tools like Vanta, Drata, Secureframe, and Sprinto connect to your cloud providers, identity provider, code repositories, ticketing, and endpoint tools, then continuously pull configuration states and timestamps so that much of the access, MFA, change, and monitoring evidence is collected as it happens rather than reconstructed later. Leading platforms now advertise integration counts in the hundreds, and continuous monitoring flags drift the moment a control slips out of conformance. The realistic caveat is that automation covers the machine-readable controls well but cannot generate human artifacts for you: pen test reports, signed vendor reviews, training rosters, and the narrative of an incident still require human work. Used well, automation shrinks the PBC list to a manageable set of human deliverables and makes Type 2 sampling far less painful.