The moment your auditor sends the PBC (Provided By Client) list, most SaaS teams realise they've been thinking about SOC 2 backwards. They spent months writing policies — and then discovered that auditors want evidence that the policies were actually operating.
This guide covers exactly what SOC 2 auditors look for, organised by Trust Service Criteria control area, with specific collection steps for the tools most SaaS companies use.
How SOC 2 Evidence Works
SOC 2 auditors don't check everything. They sample. For a Type II audit over 12 months, auditors will typically:
- Select 15–25 user access provisioning/deprovisioning events and ask for evidence of approval
- Sample 5–10 production deployments and ask for code review evidence
- Review 2–3 vendor assessment records
- Check that security training was completed by all staff (all employees, no sample)
- Verify that monitoring alerts fired and were addressed during the period
This means consistency matters more than perfection. An auditor who sees 11 months of clean evidence and 1 month of gaps will note the exception period. An auditor who sees 12 months of consistently documented (even if imperfect) controls will pass you.
Type I vs Type II: Different Evidence Requirements
| Aspect | Type I (point-in-time) | Type II (operational — 6-12 months) |
|---|---|---|
| What auditors check | Are controls suitably designed as of audit date? | Did controls operate effectively throughout the audit period? |
| Evidence required | Current state documentation and configuration | Time-stamped records showing consistent operation |
| Policies | Must be current and approved | Must be current + evidence of staff acknowledgement during period |
| Access reviews | Evidence of process design | Completed access reviews during audit period (quarterly) |
| Training | Training programme exists | Completion records for all employees during the audit period |
| Incidents | IRP exists and is designed correctly | Incident log + evidence of process followed for any incidents |
| Vulnerability scanning | Scanning tool configured | Periodic scan results + evidence of remediation tracking |
Evidence by Control Area
CC1: Control Environment — HR, Policies, Tone at the Top
What auditors check: that your organisation takes security seriously, communicates it to employees, and holds people accountable.
| Evidence Item | Format | How to Collect |
|---|---|---|
| Org chart / team list | Spreadsheet or PDF | HR system export or manual list with roles |
| Security policy acknowledgements | Spreadsheet with name, date, document version | DocuSign report, Notion sign-off log, or LMS export |
| Background check policy + evidence | Policy PDF + completion records | Background check provider report (Checkr, HireRight, etc.) |
| Security awareness training completion | Completion report by employee | KnowBe4 / training platform export; or Google Form completion log |
| Employee offer letter template | PDF (redacted) | Template used, redacted to remove personal data |
Small-team reality check: If you're a 5-person startup, auditors know you don't have a dedicated HR team. A 1-page security responsibilities document signed by all team members is a reasonable equivalent to a formal security handbook. Document it properly and apply it consistently.
CC6: Logical and Physical Access Controls — The Heaviest Section
CC6 is where most evidence requests live. Auditors look for proof that access is granted on need, reviewed regularly, and revoked promptly when no longer needed.
| Evidence Item | Format | How to Collect — GitHub / AWS / GCP |
|---|---|---|
| MFA enforcement | Screenshot with timestamp | GitHub: Org → Settings → Authentication security → "Require two-factor authentication"; AWS: IAM → Account settings; GCP: Admin console → Security → 2-step verification |
| User access list (production) | Spreadsheet: name, role, access level, date granted | AWS IAM: Users list export; GitHub: Org → Members export; GCP: IAM → Permissions export |
| Access provisioning records | Ticket/email/Slack thread showing approval | Filter GitHub Issues or Linear tickets tagged 'access request'; export Slack thread |
| Access termination records | Date, employee, who revoked, systems | Offboarding checklist with completion date; IDP (Okta/Google Workspace) deactivation log |
| Quarterly access review | Spreadsheet with date, reviewer, changes made | Export current user list → review for continued need → document changes → save with date |
| Privileged access list | Named list with justification | AWS: IAM → filter for admin policies; GitHub: org owners list |
| Encryption at rest | Screenshots of settings | AWS: S3 bucket properties → server-side encryption; RDS encryption enabled; GCP: Cloud Storage encryption settings |
| Encryption in transit (TLS) | SSL Labs test result | Run ssllabs.com/ssltest on your domain; screenshot A/A+ grade; HSTS header evidence |
CC7: System Operations — Logging, Monitoring, and Incident Response
Auditors want to see that you'd know if something went wrong, and that you'd respond to it correctly.
| Evidence Item | Format | How to Collect |
|---|---|---|
| Centralised audit log configuration | Dashboard screenshot with timestamp | AWS: CloudTrail → Trails → active trail screenshot; GCP: Admin Activity logs enabled; or Datadog / Logtail dashboard |
| Security alert rules | List of configured alerts with conditions | Export alert rules from CloudWatch / PagerDuty / Datadog; screenshot of alert configurations |
| Sample security alert notification | Screenshot of real alert | Screenshot an alert email or Slack notification that fired during the audit period |
| Vulnerability scan results | Dated report PDF or screenshot | Snyk: Project → export report; GitHub: Security → Dependabot alerts export; AWS Inspector: export findings |
| Vulnerability remediation tracking | Spreadsheet or ticket system export | GitHub Issues / Linear / Jira: filter tickets tagged 'security' or 'vulnerability'; export to CSV |
| Penetration test report | PDF (executive summary + findings, redacted) | Provided by pen test firm; include letter of engagement and final report; retest evidence if critical findings |
| Incident register | Log with date, severity, description, resolution | Even a Google Sheet is fine: Date | Severity | Description | Root Cause | Resolution Date | Owner |
| Incident response evidence | Communication records, timeline | Slack thread, email chain, post-incident review document for any significant incidents |
CC8: Change Management — Code Review and Deployment Controls
Auditors want to see that changes to production go through a controlled, reviewed process — not that a developer can push directly to main at 2 AM.
| Evidence Item | Format | How to Collect |
|---|---|---|
| Branch protection rules (GitHub) | Screenshot of settings | GitHub: Org repo → Settings → Branches → Branch protection rules → show required reviewers, status checks |
| Sample pull requests with review | PDF or screenshot of 3–5 PRs | GitHub: filter closed PRs; export or screenshot showing review approval before merge |
| CI/CD pipeline configuration | Pipeline config file or screenshot | GitHub Actions workflow file; Vercel deployment settings; test/staging gates in pipeline |
| Deployment log | List with date, deployer, environment | GitHub: Deployments tab export; Vercel: deployments history export; AWS CodeDeploy log |
| Separation of duties | Evidence or risk acceptance | Show that self-merge is disabled in branch protection, OR document a risk acceptance if exception made |
CC9: Risk and Vendor Management
| Evidence Item | Format | How to Collect |
|---|---|---|
| Vendor inventory | Spreadsheet: vendor, purpose, data accessed, risk tier, last reviewed | Manual build; review all SaaS subscriptions + cloud providers |
| Vendor SOC 2 reports (critical vendors) | PDF (one per critical vendor) | AWS: aws.amazon.com/artifact; GCP: cloud.google.com/security/compliance; Stripe: stripe.com/docs/security |
| DPAs with data processors | Signed DPA PDF per processor | Most modern vendors provide click-through DPA via their privacy portal; download and file |
| Annual vendor review records | Dated spreadsheet or meeting notes | Annual review document: vendor list reviewed on [date] by [person], changes noted, SOC 2 reports checked |
| Risk register | Spreadsheet: risk, likelihood, impact, owner, treatment | Manual build; reviewed at least annually; show date of last review |
Evidence Organisation: The PBC Folder Structure
Most auditors will provide a PBC (Provided By Client) list. Organise your evidence in advance so you can respond quickly. A standard structure:
- 1-Policies/ — all policy PDFs, version-controlled, dated
- 2-Access-Management/ — user lists, access reviews, MFA screenshots, provisioning/offboarding records
- 3-Monitoring-Logging/ — log config screenshots, alert rules, sample alerts
- 4-Vulnerability-Management/ — scan results, pen test report, remediation tracking
- 5-Change-Management/ — branch protection screenshots, sample PRs, deployment log
- 6-Vendor-Management/ — vendor register, SOC 2 reports, DPAs
- 7-HR-Training/ — training completion logs, background check policy, acknowledgement records
- 8-Incidents-BCP/ — incident register, IRP, BCP/DRP, backup test records
Name files clearly: MFA-Enforcement-GitHub-2026-05-30.png is better than screenshot.png. Auditors receive evidence from multiple clients simultaneously — clear naming helps everyone.
The 5 Most Common Evidence Gaps
- Access reviews not performed during the audit period: The policy exists but quarterly reviews weren't actually done. Fix: calendar a quarterly access review, treat it like a board meeting.
- Policy acknowledgements missing: Policies exist but there's no record that staff signed them. Fix: use DocuSign, Notion, or even a Google Form with name + date + document version.
- Vulnerability scanning is reactive, not periodic: You fix vulnerabilities when they come up, but there's no evidence of a regular scan schedule. Fix: set up Dependabot weekly scans + export a monthly report.
- Pen test not done or too old: The most common gap. Type II auditors expect an annual pen test. Most SaaS companies budget $10K–$25K for external pen tests. Providers: Cobalt, Synack, Detectify, or local security firms.
- No incident register: Nothing happened this year — great. But the absence of a register means auditors can't verify that. Fix: start an incident log today. Add a "no incidents" entry if nothing happened.
Build Your SOC 2 Compliance Stack
- SOC 2 Evidence Pack Generator — personalised evidence collection checklist by control area
- SOC 2 Gap Assessment Generator — evaluate control readiness before starting audit
- Information Security Policy Generator
- Incident Response Plan Generator
- BCP / DRP Plan Generator
- Data Retention Policy Generator
- Vendor Risk Assessment Generator
- SOC 2 Gap Analysis Guide
- ISO 27001 vs SOC 2 for SaaS
⚠️ This article is for informational purposes only. SOC 2 audit requirements vary by firm and Trust Service Criteria selection. Your auditor's PBC list takes precedence over this guide. Consult your audit firm for their specific requirements.