The SOC 2 evidence list
What the auditor asks to see.A Type II audit is an evidence exercise: the auditor samples your observation window and asks you to prove controls operated. This is what the request list looks like in practice.
Access control
User access lists for in-scope systems with roles; completed quarterly access reviews with recorded decisions (who reviewed, what changed); onboarding and offboarding records for sampled hires and departures — including proof access was revoked within your stated window; MFA enforcement configuration from the identity provider.
Change management
Sampled changes traced end to end: ticket or PR, review approval, CI checks, deploy record. The auditor picks the changes — your pipeline either enforced the policy on every merge or it didn’t. Emergency-change records with after-the-fact approval get sampled separately.
Security operations
Vulnerability scan reports across the window with remediation tracked against your severity SLAs; the annual penetration test report plus remediation and retest evidence; monitoring and alerting configuration; sampled incident records showing detection, response, and post-mortem per your incident response plan.
Infrastructure and data
Encryption configuration for data at rest and in transit; backup configuration plus a completed restoration test; logging configuration and retention; network security rules for production.
People and vendors
Security training completion records for sampled employees; background check records where policy promises them; signed acceptable-use acknowledgments; vendor register with completed reviews for sampled critical vendors (what a good review contains).
Governance
Approved policies with dated executive sign-off and annual review records; the current risk assessment with treatment decisions; board or leadership minutes where security commitments were made.
What good looks like
Every item above answers in one of two shapes: a system-generated record (exported from your platform in minutes) or a decision document (written by a human when the decision happened). Programs fail when they try to reconstruct either kind retroactively — the timestamps tell on you. Our platform modules exist to make the first shape automatic and the second shape a workflow instead of a scramble.
SOC 2 framework guide
What SOC 2 is, Type I vs Type II, what auditors actually check, realistic timelines and costs, and how to get audit-ready — with platform or with help.
SOC 2 Compliance Services
Hands-on SOC 2 compliance services: gap assessment, control implementation, evidence collection, and audit support — platform included, experts driving.
How much evidence does a Type II audit involve?
Auditors sample rather than inspect everything — expect requests across every control area, with samples drawn throughout the observation window. A well-automated program answers most requests in minutes; a manual one loses weeks to screenshot archaeology.
What happens if evidence is missing for part of the window?
Gaps become exceptions in the report — visible to every customer who reads it. One or two minor exceptions with remediation notes are survivable; patterns of missing evidence undermine the report's value. This is why drift needs fixing when it happens, not at audit time.
Can evidence collection be fully automated?
Most technical evidence, yes — access lists, configurations, scan results, change records. The judgment artifacts can't be: risk assessments, access-review decisions, incident post-mortems, vendor evaluations. Automation collects; people decide and document deciding.
What SOC 2 actually costs — SOC 2 cost breakdown: audit fees, platform subscriptions, pen tests, and the labor nobody budgets for — with realistic ranges and where teams overspend.
The SOC 2 policy set — The complete SOC 2 policy list — what each policy must cover, who approves it, and why template packs fail audits when nobody tailors them.