SOC 2 evidence collection: what auditors want to see per criterion
Evidence is the proof that your controls work. Without evidence, a control is not effective for an auditor, even if it works perfectly in practice. “If it isn’t documented, it didn’t happen.” A backup that has never been tested does not exist as far as the auditor is concerned. This page shows, per Trust Services Criterion, what auditors expect, how to automate that evidence, and which mistakes teams make most often. Also read the audit process to understand how the auditor uses your evidence.
For Type I, you collect evidence at one point in time (snapshots). For Type II, you collect evidence over the full observation period, usually six months. Start as soon as your controls are live. You cannot go back in time and collect it later.
Evidence per Trust Services Criterion
Security (mandatory for everyone)
Security is the mandatory criterion. Below are the most requested evidence categories.
| Control | What the auditor wants to see | How to collect it |
|---|---|---|
| Multi-factor authentication | Monthly screenshots of MFA settings in AWS, GitHub, Google Workspace. Logs of MFA-protected logins. | Compliance tooling, or monthly manual screenshots plus exported audit logs |
| Access management | Access matrix (who may do what). Quarterly access reviews with notes and approval. | Keep a spreadsheet; minute the review meetings |
| Onboarding | Per new employee: HR form, IT ticket, training confirmation, NDA, approval for account creation | Export from HRIS and ticketing system; training platform |
| Offboarding | Per leaver: notice from HR to IT, account disabled log with timestamp within 24 hours, hardware return | Export the IAM audit log per leaver |
| Logging | SIEM dashboard screenshots. Proof that logs are kept for at least 90 days. Sample alerts with follow-up. | SIEM runs automatically; retention policy as a screenshot of the configuration |
| Encryption | Screenshots of encryption-at-rest settings (S3, RDS). TLS scan results. Key management configuration. | AWS console screenshots; save SSL Labs scan results |
| Vulnerability management | Weekly scan reports (26 over six months). Follow-up notes per high or critical finding. | Scanner exports automatically; create a ticket per finding |
| Incident response | IRP document approved by management. Tabletop exercise minutes. Incident log (even if empty). | Document in the wiki; save meeting minutes |
| Change management | Per change: ticket, peer review, approval, deploy log. Sample of 15-20 changes over the observation period. | Git history, Jira export, CI/CD logs |
Availability (optional, but often chosen)
| Control | What the auditor wants to see | How to collect it |
|---|---|---|
| Backups | Automatic backup schedules configured. Quarterly restore tests with results. | Cloud backup dashboard; restore test minutes |
| Uptime monitoring | Monthly SLA reports. Downtime log with root cause per incident. | Export from the uptime tool; keep incident minutes |
| Capacity planning | Monitoring dashboard screenshots. Quarterly capacity reviews. | Export the dashboard; meeting minutes |
| DR plan | DR document approved. Annual DR exercise with results. | Document in the wiki; save exercise minutes |
Confidentiality (optional)
| Control | What the auditor wants to see | How to collect it |
|---|---|---|
| Data classification | Policy with classification levels. Examples of classified data. | Policy document; tagging configuration |
| DLP | DLP configuration screenshots. Alert log with follow-up per alert. | DLP tool exports; a ticket per alert |
Privacy (optional)
| Control | What the auditor wants to see | How to collect it |
|---|---|---|
| Privacy policy | Current policy with date. Cookie consent screenshots. | Website screenshot with date; document |
| DSR handling | Sample of five requests (access, erasure). Response times within 30 days. | Export from ticketing system; keep email confirmations |
How to automate evidence collection
Collecting evidence by hand for a Type II report takes 200 to 300 hours. That is one to two hours a week of taking screenshots, exporting logs and maintaining folders. Most teams forget halfway through, or the screenshots are not consistent enough.
Compliance platforms such as Vanta, Drata or Secureframe connect to your infrastructure through APIs and collect evidence daily. See compliance tooling for a comparison of those platforms.
Whatever you automate, some evidence you always collect by hand:
- Meeting minutes of access reviews and capacity reviews
- Results documents from tabletop exercises and DR tests
- Training completions per employee
- Management response to incidents
These cannot be automated. Make it easy on yourself by creating templates and filling them in directly after each review or test.
Folder structure for evidence
Consistency matters just as much as completeness. An auditor who receives 200 files without structure asks more questions than an auditor who finds twenty folders with clear names.
A workable structure:
SOC2-Evidence/
├── Policies/
├── Access-Controls/
│ ├── Q1-2026-access-review/
│ ├── Q2-2026-access-review/
│ ├── Onboarding/
│ └── Offboarding/
├── Vulnerability-Management/
│ ├── Weekly-Scans/
│ └── Pentest-2025/
├── Change-Management/
├── Incident-Response/
│ ├── IRP-document/
│ └── Tabletop-2025/
├── Backups-en-DR/
└── Training/File names should be descriptive. 2026-03-15-Q1-access-review-minutes.pdf is better than meeting_notes_final_v2.pdf.
Common mistakes in evidence collection
Starting to collect too late Controls are live in month three of the project, but evidence collection only starts in month five. Your observation period starts when you begin collecting evidence. Starting earlier is the only way to avoid missing periods. Start on day one.
Screenshots without a date A screenshot of the MFA setting without a visible date is of little value. Make sure the browser URL, the system clock or the file name shows the date clearly.
Throwing away empty incident logs If there have been no incidents for six months, that is good news. But the auditor wants to see an empty incident log. It proves you keep the log, not just that nothing went wrong.
Patches without proof of follow-up The vulnerability scanner finds a high-severity vulnerability. You patch it. Good. But where is the ticket that shows you picked it up, tested it and closed it? Without that traceability, the auditor sees a finding with no follow-up.
Access reviews without notes “We did the review” is not enough. The auditor wants to see who attended, which accounts were reviewed, which rights were removed or changed, and who approved the outcome. A meeting without minutes is a meeting that, as far as the auditor is concerned, did not take place.
Evidence not organised per control Dumping everything in one folder makes the audit slower and more expensive. Every extra day of fieldwork costs €2,000 to €3,000. Organised evidence shortens the audit.
Evidence and the readiness assessment
Four to six weeks before the formal audit, ideally you run a readiness assessment. That is the moment to review your evidence: is everything present, consistent and provable? You can still fill in or fix missing evidence at that point.
More information
- The audit process: how the auditor uses your evidence in control testing
- Common controls: what each control involves and which evidence goes with it
- Readiness assessment: verification of your evidence before the formal audit
- Compliance tooling: automate evidence collection
- AICPA Trust Services Criteria : the official criteria and requirements