SOC 2 evidence collection: what auditors actually want
Most SOC 2 prep guides treat evidence collection as a generic chore. It is not. Auditors want very specific artifacts for very specific controls, and the difference between a clean audit and a painful one usually comes down to whether you collected the right thing in the right format at the right cadence.
Here is what auditors actually request, broken down by control area, and how to collect it without burning out your team.
What counts as evidence
Evidence is anything that proves a control is operating as designed. In practice, that means one of four things:
- System-generated logs (access logs, audit logs, deployment logs)
- Configuration exports (IAM policy snapshots, branch protection settings, MFA status reports)
- Records of human activity (approvals, reviews, training completions, incident postmortems)
- Screenshots of system state, used only when the first three are unavailable
Auditors prefer the first two. Logs and configuration exports are tamper-resistant, timestamped, and easy to verify against the source system. Screenshots are evidence of last resort because they are trivially fakeable and almost always reflect a single point in time.
Evidence by control area
CC6.1: Logical access controls
Auditors want proof that access is restricted to authorized users and that controls are enforced consistently.
Collect:
- Identity provider user lists with role assignments (Okta, Azure AD, Google Workspace exports)
- MFA enforcement reports showing every user has MFA enabled
- Failed login attempt logs for production systems
- Privileged access logs (sudo, root, admin role usage)
- Session management settings (timeout, re-authentication policies)
Cadence: continuous monitoring with quarterly point-in-time exports.
CC6.2: User provisioning and deprovisioning
This is where most companies stumble. Auditors will ask for a sample of new hires and terminations from the audit period and trace them through the provisioning and deprovisioning workflow.
Collect:
- HRIS records (BambooHR, Rippling, Gusto) showing hire and termination dates
- Ticketing records showing access requests, approvals, and grants
- Deprovisioning checklists showing every system was disabled within the SLA (usually 24 hours for terminations)
- Quarterly access review records confirming current users still need their access
The auditor will pick five to ten people at random. If even one is missing a deprovisioning timestamp, that becomes a finding.
CC7.1: Vulnerability management
Auditors want to see that you find vulnerabilities, prioritize them, and fix them on a defined timeline.
Collect:
- Vulnerability scan results (Snyk, Dependabot, Tenable, Qualys) with timestamps
- Remediation tickets showing the vulnerability lifecycle from discovery to fix
- Patching SLA documentation (critical within 7 days, high within 30 days, etc.)
- Penetration test report from a licensed third party (annually)
Show the trend. Auditors love seeing a vulnerability count drop over time. They get suspicious when it stays flat.
CC7.2: Incident detection and response
The auditor will ask for an inventory of all incidents during the audit period, even minor ones.
Collect:
- Incident records with timestamps, severity, root cause, and resolution
- Postmortem documents for severity 1 and 2 incidents
- Runbook references showing the response was documented in advance
- Evidence the security team was notified within the defined SLA
- Quarterly tabletop exercises or incident response drills
If you had zero incidents during the audit period, that is itself a finding. No company has zero incidents. It means you are not detecting them.
CC8.1: Change management
This is the GitHub control. Auditors want to see that code does not reach production without review and approval.
Collect:
- Branch protection settings on production repositories (required reviews, status checks, no direct pushes to main)
- Pull request samples showing reviewer approvals
- Deployment logs tying commits to production releases
- Change advisory board records for high-risk changes (if you have a CAB)
- Emergency change records for hotfixes that bypassed normal flow
Auditors will sample five to ten production deployments and trace each one back through the PR, the review, and the deployment log. If the chain breaks, it becomes a finding.
CC9.1: Vendor management
Third-party risk is increasingly scrutinized. Auditors expect a vendor inventory and ongoing monitoring.
Collect:
- Vendor inventory with risk classification (critical, high, medium, low)
- SOC 2 reports or security questionnaires from critical vendors
- Annual vendor reassessments
- Data processing agreements for vendors handling customer data
- Records showing offboarded vendors had their access removed
Common mistakes
The biggest mistake is treating evidence as a point-in-time snapshot instead of continuous monitoring. SOC 2 Type II covers a six to twelve month window. Auditors will sample dates across that window. If you only have evidence from the week before the audit, you will fail.
The second biggest mistake is over-collecting. Teams that screenshot everything end up with 4,000 files, none of them organized, and spend the audit week searching for the right one. Less is more if it is the right less.
The third mistake is letting evidence go stale. A backup configuration export from January is useless in October if backups silently broke in March.
How a fractional CISO helps
Keeping evidence fresh across an entire audit period is a standing job, not a one-time push. This is where a fractional CISO earns their keep. Xorabyte sets up automated collection against your cloud providers, identity provider, and code hosting, then maps each control to the evidence source that actually satisfies it. Instead of scrambling the week before fieldwork, you have evidence accumulating on a schedule and a security leader watching for the controls that quietly drift.
When a control's state changes, someone who understands the audit reviews it, classifies it, and routes it to the right owner. That is the part tooling alone cannot do, and it is the difference between a clean audit and a week of exceptions.
If you want a security leader to set this up and run it for your stack, book a call. We will walk through your systems and show which evidence types automate cleanly and which still need human review.
Related reading
- SOC 2 readiness assessment checklist
- SOC 2 Trust Service Criteria explained
- SOC 2 scope definition guide
- How to prepare for a SOC 2 audit
Want a security leader to run this?
Xorabyte is a fractional CISO for startups who can answer a blocked security questionnaire, so a blocked deal or an audit stops being your problem to carry alone. Book a call and you will leave with a clear path, not a sales pitch.