How-To7 June 2026 7 min read

How to Collect SOC 2 Evidence: Tools and Process

SOC 2 evidence collection determines your audit outcome. Learn what types of evidence are needed, how to collect them, and how to organise them for your auditor.

Key Takeaways

SOC 2 evidence must be contemporaneous — collected at the time the control operates, not reconstructed after the fact.
Three evidence types: system-generated (logs, configurations), process evidence (completed checklists, meeting notes), and third-party evidence (vendor SOC 2 reports, penetration test results).
Automation tools can collect 50–70% of evidence automatically from cloud integrations.
Each control needs at least one evidence item; critical controls need multiple items from across the observation period.
Auditors will request evidence via a PBC list — respond within 2–3 business days to keep fieldwork on schedule.

In this guide

Evidence Types
Evidence by SOC 2 Criterion
Collection Process
Automating Collection
Organising for Auditors
Responding to PBC Lists

Evidence Types

System-generated evidence: logs, configuration screenshots, automated scan results. Examples: CloudTrail log showing MFA-protected API calls, Security Hub compliance score, Okta user report with MFA status, GitHub branch protection settings screenshot.

Process evidence: records of human activities that controls require. Examples: completed quarterly access review spreadsheet, incident ticket and post-incident report, change management Jira ticket with required approvals, vendor security review record.

Third-party evidence: external validation of controls or your vendors' controls. Examples: your penetration test report, your vendors' SOC 2 reports (evidence that you manage vendor risk under CC9.2).

Evidence by SOC 2 Criterion

CC6 (Logical and Physical Access): IAM user list with MFA status, access review records, terminated employee offboarding tickets, SSO configuration screenshots, privileged account inventory.

CC7 (System Operations and Monitoring): CloudTrail configuration, GuardDuty alert history, Security Hub findings report, incident response test records, vulnerability scan results.

CC8 (Change Management): change management policy, sample change tickets showing required approvals (4–6 samples is typical for auditor testing), deployment pipeline configuration showing required approval gates.

CC9 (Risk Mitigation): vendor risk register with assessment dates, vendor SOC 2 reports or questionnaire responses, business continuity plan, backup test records.

Collection Process

Assign evidence ownership. Each control should have an owner responsible for collecting and maintaining evidence. Do not leave evidence collection to one person — distribute ownership across engineering, operations, and HR.

Collect on a schedule. Some evidence is collected continuously (logs), some is collected at each event (change tickets), and some is collected on a schedule (quarterly access reviews, annual penetration tests). Build calendar reminders for scheduled collection activities.

Store with context. Each evidence item should include: what it demonstrates, the collection date, who collected it, and how to interpret it. A screenshot with no context is harder for auditors to evaluate than one with a caption explaining which control it supports.

Automating Collection

Cloud infrastructure evidence can largely be automated. AWS Security Hub provides a continuous compliance score with exportable findings. CloudTrail generates logs automatically. GuardDuty findings are available via API. GitHub audit logs export via API.

Compliance automation tools like AuditPath integrate with these sources and pull evidence automatically — eliminating the manual screenshot-taking that consumes hours of engineering time during audit preparation.

Process evidence (access reviews, change approvals, vendor reviews) still requires human activities, but templates and calendar automation can make the collection more systematic.

Organising for Auditors

Structure your evidence library by control, not by date or source. Auditors navigate by control number (CC6.2, CC8.1, etc.) — they will ask "show me evidence for CC6.2" and need to find it quickly.

Use a compliance tool (AuditPath) or a structured shared folder with folders for each control. Within each control folder: a brief description of the control, the most recent evidence item, and historical evidence items for the observation period.

Label each evidence file clearly: [CC#]-[control-name]-[date]-[brief-description]. Example: CC6.2-access-review-Q2-2026-completed.xlsx. Avoid ambiguous file names — they create confusion during audit fieldwork.

Responding to PBC Lists

A PBC (Provided by Client) list is the auditor's evidence request list sent at the start of fieldwork. It typically contains 40–80 line items referencing specific controls and asking for evidence. Respond within 2–3 business days to avoid delaying your audit.

Before fieldwork begins, pre-populate as much as possible in your compliance tool or shared folder. Then when the PBC arrives, you can often respond by pointing to already-organised evidence rather than gathering it under time pressure.

If you cannot provide an item: communicate immediately, explain why, and propose an alternative. Auditors can work with compensating controls if you communicate proactively.

Frequently Asked Questions

How far back does SOC 2 evidence need to go?

For Type II, evidence must cover the entire observation period (typically 6–12 months). Auditors will sample across the period — evidence from only the last month is insufficient. Start collecting and storing evidence from the first day of your observation period.

Can we reconstruct evidence after the fact?

Not for most controls. Auditors are trained to identify retroactively created evidence. For Type II, the evidence must have been created at the time the control operated — not recreated before the audit. This is why starting your evidence collection programme from day one of the observation period is critical.

How many evidence samples do auditors typically request?

Sampling size varies by control and observation period length. For a 12-month period, auditors typically sample 5–25 items per control depending on frequency and risk. For quarterly access reviews, they will request all 4 quarters.

Do vendor SOC 2 reports count as evidence?

Yes. Collecting current SOC 2 reports from your key vendors (AWS, Okta, GitHub, Stripe, etc.) serves as evidence for CC9.2 (vendor risk management). Store these reports in your evidence library and note their review date.

What if we switch compliance tools during the observation period?

Export and preserve all evidence from your old tool before switching. Import or reference it in your new tool. Your auditor should be informed of the tool change and can accommodate it in the testing approach.