What goes in the auditor's evidence binder (and what doesn't)

What goes in the auditor's evidence binder

A SOC 2 Type II audit goes well or badly mostly based on what the auditor finds when they open the evidence folder. If the artifacts are organized, dated, and unambiguous, the audit goes fast and surfaces few findings. If the artifacts are scattered, undated, or require interpretation, the auditor has to dig — which costs you in hours billed and in their willingness to give you the benefit of the doubt on edge cases.

Here's the working list of what to put in the binder, by Trust Service Criterion, in the format that auditors actually accept.

Common Criteria (CC) — required, the bulk of the audit

CC1 — Control Environment

• Org chart (current, dated within the audit period)
• Code of conduct, signed by every employee
• Background check vendor + sample of completed checks (5-10)
• HR onboarding/offboarding policy + 5-10 sample tickets

CC2 — Communication and Information

• Internal information security policy (single PDF, signed by exec leadership)
• Customer-facing security commitments (link to your trust page + SLA)
• Evidence of annual policy review (signed acknowledgment)

CC3 — Risk Assessment

• Risk assessment document, dated within the audit period
• Risk register with scored risks and mitigations
• Evidence of changes to controls during the year based on the risk assessment

CC4 — Monitoring

• Vulnerability management policy
• Last 4 quarters of vulnerability scans (CyberGrid Continuous customers get these auto-archived)
• The annual pen-test report
• Evidence of remediation of any high/critical findings within the SLA

CC5 — Control Activities

• Change management policy
• 10-20 sample production change tickets with PR + reviewer evidence
• Evidence of segregation of duties (the change author and the deployer aren't the same person)

CC6 — Logical and Physical Access

• Access control policy
• Quarterly access review evidence (one per quarter, with reviewer signature and date)
• MFA enforcement evidence (Okta/JumpCloud report showing 100% MFA on critical systems)
• Sample of 10 onboardings + 10 offboardings with timestamps showing SLA compliance
• Privileged access list (who has prod admin) + justification per person

CC7 — System Operations

• Backup policy + 4 quarters of backup success logs
• Restore test evidence (at least one in the audit period)
• Incident response plan
• Sample of 1-3 incidents from the audit period (or evidence of an incident exercise if you had none)

CC8 — Change Management

• See CC5 — overlaps significantly

CC9 — Risk Mitigation

• Vendor management policy + vendor inventory
• SOC 2 reports from your critical subprocessors (AWS, GitHub, etc.)
• Evidence you reviewed each vendor's compliance at onboarding + during the audit period

Availability (A) — if in scope

• Uptime SLA + actual uptime numbers (4 quarters)
• DR plan + evidence of annual DR test
• Capacity planning documentation
• Failover evidence (synthetic test or real incident)

Confidentiality (C) — if in scope

• Data classification policy
• Customer data retention + destruction policy
• Sample of customer offboardings with evidence of data destruction within SLA
• Encryption-at-rest evidence (cloud provider config screenshots)

Privacy (P) — if in scope (less common)

• Privacy policy
• DPIA (Data Protection Impact Assessment)
• Sample of DSAR (Data Subject Access Request) handlings
• Cookie consent flow evidence

Processing Integrity (PI) — if in scope (rare for SaaS)

• Data validation evidence
• Calculation accuracy testing
• Reconciliation evidence

The format that auditors prefer

A folder structure that consistently produces clean audits:

SOC2-Type-II-2026/
  00-Overview/
    audit-window.txt           (start and end dates)
    scope-document.pdf
    org-chart-2026-Q2.pdf
  01-Policies/
    information-security.pdf
    access-control.pdf
    change-management.pdf
    ... (one PDF per policy)
  02-CC1-Control-Environment/
  03-CC2-Communication/
  ... (one folder per CC)
  10-Availability/
  11-Confidentiality/
  99-Subprocessor-SOC2/
    aws-soc2-2026.pdf
    github-soc2-2026.pdf
    ...

Every file should be a PDF (not a Word doc, not a screenshot — PDF). Every file should be named with a date or quarter. Every file should be readable on its own without needing your verbal explanation.

What separates a 2-week audit from a 6-week audit

• Pre-organized evidence: if the auditor has to ask for an artifact, you've already lost a week of calendar time. If they download the artifact from the folder, you've saved it.
• Single point of contact who knows where everything lives: typically the head of engineering or a dedicated security engineer. Spreading auditor questions across the company adds 2-3 days each.
• GRC platform integration: Vanta/Drata/Secureframe can produce the evidence folder above semi-automatically. The auditor still wants to verify the artifacts but doesn't have to chase them.
• Pre-scoped engagement: if you and the auditor agreed on the scope and the criteria 4 weeks before the audit starts, day 1 is productive. If you're still negotiating scope in week 1 of the audit, you've added a week.

The companies that get clean Type II reports with no findings consistently are the ones who treat the evidence binder as a continuously-maintained artifact rather than a once-a-year fire drill. The GRC platforms automate this for you if you let them — most of the resistance comes from teams who haven't yet trusted the automation.