The SOC 2 Evidence Collection Checklist Your Auditor Won't Give You

When we ask GRC practitioners what the hardest part of SOC 2 Type II is, the answer is rarely the controls themselves. Most teams can design controls that would satisfy the Trust Service Criteria. The hard part is producing evidence that proves those controls were operating — continuously, for 12 months — in a format a third-party auditor can review without a guided tour of your infrastructure.

Your auditor will give you a PBC (Provided By Client) list at the start of fieldwork. That list tells you what they're requesting. What it doesn't tell you is which items teams consistently fail to produce, which formats create friction in the review, and which evidence requests can only be satisfied by something you needed to be capturing months before the audit started. That's what this post covers.

The Evidence Categories Every SOC 2 Type II Audit Touches

SOC 2 audits organized around the Common Criteria cluster evidence requests into consistent categories. Here's the breakdown of what appears in every substantive Type II review, with notes on where teams consistently struggle.

Access Control Evidence (CC6.x)

This is the largest evidence category in most Type II audits. The specific requests:

• User provisioning records: Evidence that access was formally requested and approved before it was granted. HR system entries, ticketing system records showing the approval chain. The gap here: access provisioned out-of-band (directly in AWS IAM or a SaaS admin panel without a corresponding ticket) leaves no provisioning evidence.
• Access review certifications: Completed access review records showing who reviewed which accounts, what decisions were made, and when. Auditors want to see a closed loop — accounts flagged for revocation should have corresponding removal evidence within your defined remediation window.
• Offboarding records: Documentation that departed employees and contractors had access revoked within your defined timeframe. The auditor typically selects a sample of terminated users and asks to see access removal timestamps from your identity provider.
• MFA enforcement evidence: Configuration exports from your identity provider showing MFA is required for in-scope user populations, not just enabled. "Enabled" and "enforced" are different things — auditors know the distinction.
• Privileged access logs: Evidence that privileged or administrative access is logged, and that log access is restricted to prevent tampering.

Change Management Evidence (CC8.1)

• Change tickets with approval records: Evidence that changes to production systems went through a documented approval process. Auditors sample specific production deployments and trace them back to an approved change ticket.
• Deployment pipeline records: CI/CD logs, code review approvals, and deployment timestamps. For engineering-heavy teams, this is usually available — the gap is often that it's not organized in a way that maps to specific change events the auditor is tracing.
• Emergency change records: Evidence of how out-of-band changes (hotfixes, incident response) were documented and retroactively approved. Every organization has these; what varies is whether they're tracked.

Incident Response Evidence (CC7.x)

• Incident register: A log of security incidents (including near-misses) during the observation period, with severity classification, response actions, and resolution documentation. Teams that had no formal incidents often leave this blank — which raises questions about whether incidents were identified rather than questions about whether they occurred.
• Security monitoring configuration: Evidence that your monitoring tools (SIEM, CloudTrail alerts, IDS alerts) were active and configured to alert on the event types your incident response policy addresses.
• Vulnerability management records: Scan results, findings, and remediation timelines. Auditors want to see that vulnerabilities discovered during the observation period were tracked to resolution within policy-defined timelines.

Vendor Risk Evidence (CC9.2)

• Subprocessor inventory with review dates: The list of vendors with access to in-scope systems, with documented dates of last review for each vendor's SOC 2 report or equivalent.
• Vendor SOC 2 reports: Current copies of reports for Tier 1 and Tier 2 subprocessors, with coverage dates that fall within or overlap your observation period.
• Vendor risk assessment records: Evidence that you reviewed vendor reports — not just collected them. A date-stamped note documenting what you found and whether any exceptions required compensating controls on your side.

Risk Assessment Evidence (CC9.1)

• Risk register: A current list of identified risks with owner assignment, severity rating, and treatment decision (accept, mitigate, transfer). Risk registers that haven't been updated in 9 months draw comment.
• Risk assessment process documentation: Evidence that the risk register was reviewed and updated during the observation period, not just created once during readiness work.

Logical and Physical Security Evidence (CC6.4 / CC6.5)

• Network segmentation records: VPC configuration exports, security group rules, or equivalent evidence showing that production environments are segregated from development and test environments.
• Encryption configuration records: Evidence that data at rest and in transit is encrypted in accordance with your system description. For cloud-hosted systems, this typically comes from cloud console exports showing storage encryption settings and TLS termination configuration.

Policy and Training Evidence (CC1.x / CC2.x)

• Policy acknowledgment records: Evidence that employees reviewed and acknowledged information security policies during the observation period. Most HR or GRC tools can generate this; the gap is usually stale acknowledgment records from two years ago.
• Security awareness training completion records: Training completion logs for all in-scope personnel, with dates during the observation period. Auditors sample employees and check whether their training dates fall within the observation window.
• Board or leadership security review records: Evidence that senior leadership received updates on the security program during the period. Meeting minutes, email threads, or board materials that reference security program status.

The Three Evidence Types That Consistently Create Problems

In our experience mapping audit prep patterns, three evidence types account for a disproportionate share of scramble time and last-minute findings.

Offboarding Access Removal Timestamps

This seems simple — you revoke access when someone leaves — but producing auditable proof of when revocation happened (not just that it happened) requires that your identity provider audit log has been retained since the beginning of the observation period. If your Okta or Azure AD audit log retention is set to 30 or 90 days, you may not be able to produce removal timestamps for departures that happened in the first half of the year. This is a configuration issue that can only be fixed by adjusting retention settings before the observation period starts.

Access Review Closed-Loop Evidence

Completing an access review is necessary but not sufficient. Auditors want to see that flagged accounts were actually revoked, and that the revocation happened within your policy-defined remediation window. A spreadsheet showing "revoke this account" without a corresponding IAM removal timestamp is an open finding. The evidence chain needs to connect the review record to the actual system change.

Incident Register Completeness

We're not saying your organization had no security incidents during the observation period — we're saying that an empty incident register raises audit questions that are harder to answer than a populated one with low-severity entries. Near-misses, phishing attempts that were caught, brief system unavailability events, and security tool false positives all represent documented operational activity that gives the auditor confidence that your detection capabilities were operating. A blank register suggests that either nothing happened (improbable) or that you weren't looking (problematic).

Format Notes That Save Time During Fieldwork

Auditors review evidence from multiple clients on compressed timelines. Evidence that requires explanation creates friction that can extend fieldwork duration. A few format choices that consistently reduce review time:

• Timestamped exports from source systems beat screenshots. Screenshots can be edited; direct exports from your identity provider or cloud console carry more inherent credibility and require less explanation.
• CSV exports with sortable date columns beat PDF reports for sample-based testing. When an auditor selects a sample date and asks for evidence from that date, a filterable export lets them verify it themselves.
• Evidence keyed to control IDs beats evidence keyed to internal process names. If your system description maps "CC6.3" to your access review process, label your access review evidence with "CC6.3" so the auditor can cross-reference without a translation table.

This checklist doesn't guarantee a clean audit — controls that weren't operating can't be proven into existence. What it does is identify the collection categories early enough that you can confirm either you have the evidence or you need to start generating it now. The auditors who complete fieldwork in two weeks versus six are usually working with teams that started evidence collection in parallel with control operation, not as a trailing activity.