SOC 2 Evidence Collection: The Complete Guide to What Your Auditor Will Actually Ask For

The Evidence Problem: Why Most Organizations Struggle with SOC 2 Audit Prep

You built the controls. You wrote the policies. Your team follows the processes. But when your SOC 2 auditor sends you a 150-item evidence request list two weeks before fieldwork, the panic sets in. Where is that screenshot from six months ago? Who approved that policy change? Can you prove that access review actually happened in October?

Evidence collection is the single most time-consuming part of SOC 2 compliance, and it is where the gap between "we do this" and "we can prove we do this" becomes painfully obvious. Organizations that run clean, efficient audits are not necessarily more secure than those that struggle -- they are just better at capturing and organizing proof of their security practices on an ongoing basis.

This guide covers exactly what your auditor will request, organized by Trust Services Criteria, along with practical advice on how to collect it, when to collect it, and the mistakes that turn a straightforward audit into a months-long ordeal.

Understanding What Auditors Actually Do with Your Evidence

Before diving into specific evidence requests, it helps to understand the audit methodology. Your auditor is not checking every transaction, every login, or every change request from the entire audit period. They use sampling.

For a SOC 2 Type II audit, the auditor will:

1. Review your control descriptions -- These are the controls you claim to have in place, documented in your system description
2. Design test procedures -- For each control, the auditor defines how they will test whether it operated effectively
3. Select samples -- For controls that operate on a per-transaction basis (like change management), the auditor selects a sample of transactions from across the audit period
4. Request evidence -- You provide evidence for the sampled transactions and for controls that operate continuously
5. Evaluate and conclude -- The auditor determines whether the evidence supports that the control operated effectively

Sample sizes typically follow this pattern:

This means your evidence must be available for any point in the audit period, not just the most recent occurrence. If your auditor asks for the access review from September and you only have the one from December, that is a gap.

Evidence Requests by Trust Services Criteria

Here is a comprehensive breakdown of what auditors typically request, organized by the Common Criteria categories. This is not exhaustive -- your specific evidence requests will depend on your control descriptions -- but it covers the requests that appear in virtually every SOC 2 audit.

CC1: Control Environment

CC1 covers organizational governance, structure, and accountability. Evidence requests focus on proving that security is embedded in your organizational culture and management practices.

• Organizational chart -- Current org chart showing reporting lines, particularly for the security function
• Board/management meeting minutes -- Minutes from meetings where security topics were discussed, risk was reviewed, or compliance status was reported
• Code of conduct or ethics policy -- Signed acknowledgments from employees
• Security awareness training records -- Completion records showing all employees completed training during the audit period, including dates and pass/fail results
• Job descriptions for security roles -- Descriptions that define security responsibilities for key personnel
• Background check records -- Evidence that background checks were performed for employees hired during the audit period (redacted for privacy)

CC2: Communication and Information

CC2 covers how your organization communicates security responsibilities internally and externally.

• Information security policy -- Current policy with version history and approval records
• Policy acknowledgment records -- Evidence that employees reviewed and acknowledged security policies
• System description -- Your documented description of the system, its boundaries, and infrastructure
• Vendor and customer communications -- Examples of security-related communications to third parties
• Internal security communications -- Evidence of security updates, advisories, or bulletins shared with staff

CC3: Risk Assessment

CC3 evidence demonstrates that your organization identifies, analyzes, and manages risk systematically.

• Risk assessment report -- Your most recent formal risk assessment, including methodology, identified risks, likelihood/impact ratings, and treatment decisions
• Risk register -- A current register showing tracked risks, owners, mitigation strategies, and status
• Risk assessment meeting notes -- Evidence that risk was reviewed by appropriate stakeholders
• Fraud risk assessment -- Specific assessment of fraud risks and controls to mitigate them

CC4: Monitoring Activities

CC4 covers internal monitoring of your control environment -- essentially, how you verify that your own controls are working.

• Internal audit or self-assessment reports -- Evidence of periodic reviews of control effectiveness
• Control deficiency tracking -- Records of identified control gaps and remediation actions
• Management review records -- Evidence that leadership reviews the overall health of the compliance program

CC5: Control Activities

CC5 is broad and covers the policies and procedures that support your control objectives. This is where the bulk of your technical evidence lives.

CC5 -- Logical Access and Security

• User access lists -- Current lists of users with access to in-scope systems, including roles and permissions
• Access provisioning records -- Tickets or requests showing how access was granted, who approved it, and the principle of least privilege applied
• Access revocation records -- Evidence of timely access removal for terminated employees (compare against HR termination dates)
• Periodic user access reviews -- Evidence of regular reviews of access appropriateness with sign-off from managers
• MFA configuration -- Screenshots showing MFA is enforced for all in-scope systems, particularly administrative access
• Password policy configuration -- Screenshots from identity provider showing password complexity, rotation, and lockout settings
• Firewall and network security configurations -- Rule exports showing network segmentation and access restrictions
• Encryption configurations -- Evidence of encryption at rest and in transit for customer data

CC5 -- Change Management

• Change management policy -- Your documented process for requesting, reviewing, approving, testing, and deploying changes
• Sample change tickets -- The auditor will select 25 or more changes from the audit period and request the full ticket showing description, review, approval, testing, and deployment evidence
• Code review evidence -- Pull request records showing peer review before merge to production
• Deployment pipeline configuration -- Evidence that deployments follow a defined path (dev to staging to production) with appropriate gates
• Emergency change records -- If any emergency changes bypassed normal procedures, documentation of the change and post-hoc review

CC6: Logical and Physical Access Controls

CC6 digs deeper into access control specifics. Expect these requests:

• Physical access controls -- If you manage physical infrastructure, evidence of badge access systems, visitor logs, and data center security
• Endpoint protection -- Evidence that all endpoints have security software (EDR/antivirus) installed and updated
• Data classification policy -- Documentation defining data sensitivity levels and handling requirements
• Data retention and disposal records -- Evidence that data is retained and destroyed according to your policy

CC7: System Operations and Monitoring

CC7 covers your continuous monitoring program. Evidence requests include:

• Monitoring architecture diagram -- Showing log sources, aggregation, alerting, and response workflow
• Alert rule inventory -- List of active detection rules with descriptions and thresholds
• Alert response records -- Sampled alerts showing acknowledgment, triage, and resolution
• Vulnerability scan reports -- Scan results from throughout the audit period with remediation tracking
• Penetration test report -- Your most recent penetration test report and evidence of remediation for identified findings
• Incident response plan -- Current plan with evidence of testing (tabletop exercise results)
• Incident records -- If any security incidents occurred during the audit period, the full incident record including detection, response, and post-incident review

CC8: Change Management

CC8 overlaps with CC5 change management but focuses specifically on infrastructure and system changes rather than application code changes.

• Infrastructure change records -- Evidence of changes to servers, network configurations, cloud infrastructure, and security tools
• Patch management records -- Evidence that patches are applied on a defined schedule with tracking of critical patch timelines
• System configuration baselines -- Documented baseline configurations for production systems

CC9: Risk Mitigation

CC9 covers risk mitigation activities including vendor management and insurance.

• Vendor inventory with risk classifications -- Your vendor management register showing all vendors, risk tiers, and assessment dates
• Vendor assessment records -- SOC 2 reports from subservice organizations, completed security questionnaires, or alternative evidence
• CUEC mapping -- Documentation showing how you implement Complementary User Entity Controls from vendor SOC 2 reports
• Business continuity and disaster recovery plan -- Current plan with evidence of testing
• Backup configuration and testing records -- Evidence that backups are configured, encrypted, and periodically tested for recoverability
• Insurance certificates -- Current cyber liability and professional liability insurance certificates

How to Organize Your Evidence Repository

The structure of your evidence repository can make or break your audit timeline. A well-organized repository means your auditor finds what they need quickly, asks fewer follow-up questions, and finishes fieldwork faster. A disorganized one means weeks of back-and-forth.

Recommended Folder Structure

Organize your evidence by control criteria, with sub-folders for each evidence type. Here is a structure that works well:

• CC1-Control-Environment/
  • Org-Charts/
  • Meeting-Minutes/
  • Training-Records/
  • Background-Checks/
• CC2-Communication/
  • Policies/ (with version history)
  • Acknowledgments/
  • System-Description/
• CC3-Risk-Assessment/
  • Risk-Assessments/
  • Risk-Register/
• CC5-Control-Activities/
  • Access-Reviews/
  • Change-Management/
  • Configurations/
• CC7-System-Operations/
  • Monitoring/
  • Vulnerability-Scans/
  • Penetration-Tests/
  • Incident-Records/
• CC9-Risk-Mitigation/
  • Vendor-Management/
  • BCP-DR/
  • Insurance/

Evidence Naming Conventions

Use consistent naming that makes evidence immediately identifiable:

Format: [CC#]-[Description]-[Date]-[Version]

Examples:

• CC5-Access-Review-Production-Systems-2025-09.pdf
• CC7-Vulnerability-Scan-Report-2025-10-15.pdf
• CC1-Security-Training-Completion-Q3-2025.xlsx
• CC9-AWS-SOC2-Report-Review-2025-08.pdf

The Evidence Collection Timeline

Evidence collection is not a one-time event. For a Type II audit, you need evidence from throughout the audit period. Here is how to structure your collection cadence so you are never scrambling.

Continuous Collection (Automated Where Possible)

• Access provisioning and revocation tickets -- captured automatically through your ticketing system
• Change management tickets -- captured through your development workflow (Jira, GitHub, etc.)
• Monitoring alerts and response records -- captured through your alerting and incident management platform
• Log aggregation and retention -- configured once, verified periodically

Weekly or Monthly Collection

• Vulnerability scan exports -- save the report after each scan cycle
• Access review records -- after each periodic review, save the review document with approvals
• Patch management records -- after each patch cycle, document what was patched and any exceptions

Quarterly Collection

• Risk register review notes -- document any changes to risk ratings or new risks identified
• Vendor assessment updates -- check for new SOC 2 reports from critical vendors
• Configuration baseline verification -- validate that production configurations match approved baselines
• Management review meeting minutes -- capture security program status discussions

Annual Collection

• Penetration test report and remediation evidence
• Full risk assessment or risk assessment update
• Security awareness training completion records for all employees
• Incident response plan test (tabletop exercise) results
• Business continuity and disaster recovery test results
• Policy review and update records with version history
• Insurance certificate renewals

Compliance Automation: What It Can and Cannot Do

Compliance automation platforms have become essential tools for SOC 2 evidence collection. Platforms like Vanta, Drata, Secureframe, and Thoropass integrate with your infrastructure and automatically pull evidence on a continuous basis. For a detailed comparison, see our guide on compliance automation for SOC 2 and ISO 27001.

What Automation Handles Well

• Cloud configuration checks -- Automatically verifying that AWS, GCP, or Azure configurations meet security baselines (encryption enabled, public access blocked, logging configured)
• Identity provider integration -- Pulling user lists, MFA status, and access configurations from Okta, Google Workspace, or Azure AD
• Endpoint monitoring -- Verifying that all corporate devices have EDR software installed and updated
• Version control integration -- Pulling code review evidence from GitHub or GitLab to demonstrate change management
• Background check integration -- Connecting to your background check provider to verify completion
• Training tracking -- Monitoring security awareness training completion rates

What Still Requires Manual Effort

• Policy creation and review -- Automation can remind you to review policies, but writing and approving policies requires human judgment
• Risk assessment -- The risk assessment process requires qualitative analysis and business context that cannot be fully automated
• Incident response details -- If an incident occurs, the investigation, root cause analysis, and post-incident review require manual documentation
• Vendor SOC 2 report review -- Reading and evaluating a vendor's SOC 2 report requires human analysis
• Meeting minutes and management reviews -- Board and management discussions about security must be documented manually
• Business context for controls -- Explaining why a control is designed the way it is requires human narrative

For startups preparing for their first SOC 2, the investment in a compliance automation platform typically pays for itself by reducing the internal labor required for evidence collection by 60 to 70 percent. The real value is not just the automation -- it is the continuous visibility into your compliance posture that prevents last-minute surprises.

The Top 10 Evidence Mistakes That Create Audit Findings

After supporting organizations through dozens of SOC 2 audits, these are the evidence-related mistakes we see most frequently. Each one has the potential to create an exception in your report. For a broader view, see our guide on common SOC 2 audit findings.

• Screenshots without timestamps -- A screenshot of your MFA configuration is only useful if it shows when it was captured. Auditors need to verify the configuration was in place during the audit period, not just at the time of the audit
• Policies without version history -- If your information security policy does not have version numbers, dates, and approval records, the auditor cannot verify it was reviewed and updated during the audit period
• Access reviews without evidence of action -- Performing an access review is only half the control. You must also document any access that was revoked as a result of the review and the tickets or records showing the revocation occurred
• Gap periods in evidence -- Your vulnerability scans show January through May and August through December. What happened in June and July? Any unexplained gap in evidence continuity raises questions
• Training records without completion dates -- "John Smith completed security training" is not evidence. "John Smith completed security training on March 15, 2025, scoring 92 percent" is evidence
• Change management tickets without all required fields -- The auditor samples 25 change tickets. Three of them are missing peer review evidence, two are missing testing documentation, and one was deployed without approval. Each is a potential exception
• Terminated employee access not revoked promptly -- The auditor cross-references your HR termination records with your access revocation records. If there is a gap of more than 24 hours between termination and access revocation, that is a finding most auditors will flag
• Vendor SOC 2 reports that expired during the audit period -- If your cloud provider's SOC 2 report covered January through June and your audit period is January through December, you have a six-month gap. You need the updated report
• Incident response plan never tested -- Having an incident response plan is CC7.4. Testing it is also CC7.4. An untested plan is an incomplete control
• Evidence that contradicts your control descriptions -- Your system description says access reviews are performed quarterly. Your evidence shows they happened in Q1 and Q4 but not Q2 or Q3. Your control description becomes the standard you are measured against

The 8-Week Audit Prep Countdown

If your audit fieldwork starts in 8 weeks, here is a week-by-week preparation plan that ensures you walk into fieldwork organized and confident.

Week 8: Inventory and Gap Check

• Review your control descriptions and create a master list of expected evidence for each control
• Check your evidence repository for completeness -- are there gap periods for any recurring evidence?
• Verify that all policies have been reviewed and updated within the audit period
• Confirm your risk assessment was performed or reviewed during the audit period

Week 7: Access and Identity Evidence

• Export current user access lists from all in-scope systems
• Verify all periodic access reviews are documented with approvals
• Cross-reference HR termination records with access revocation records for the audit period
• Capture screenshots of MFA enforcement, password policies, and SSO configurations

Week 6: Change Management and Operations

• Review a sample of your own change tickets for completeness -- description, review, approval, testing, deployment evidence
• Verify deployment pipeline configurations are documented and screenshots are current
• Collect patch management records for the full audit period

Week 5: Monitoring and Incident Response

• Verify monitoring alert response records are complete across the audit period
• Collect vulnerability scan reports with remediation tracking
• Verify your penetration test was conducted within the audit period
• Confirm incident response plan testing (tabletop exercise) was completed and documented

Week 4: Vendor and Third-Party Evidence

• Verify all critical vendor SOC 2 reports are current and cover the audit period
• Confirm CUEC mapping documentation is complete
• Review vendor inventory for completeness and accuracy
• Collect vendor assessment records for the audit period

Week 3: Business Continuity and Recovery

• Verify backup configuration evidence and recent restoration test results
• Confirm business continuity and disaster recovery plans are current and tested
• Collect insurance certificates and verify they are not expired

Week 2: Organization and Index

• Organize all evidence in your repository using consistent naming and folder structure
• Create an evidence index mapping each expected auditor request to the specific file
• Brief your team on what to expect during fieldwork -- who handles which evidence requests, response time expectations

Week 1: Final Validation

• Do a final walkthrough of your evidence repository, checking for completeness
• Run through the most common evidence requests in your head and verify you can locate each item in under 2 minutes
• Prepare a brief system description overview for the auditor's opening meeting
• Ensure all key personnel are available during the fieldwork window

Connecting Evidence Collection to Your SOC 2 Journey

Evidence collection is not a standalone activity. It is the thread that runs through every aspect of your SOC 2 compliance program. When your readiness assessment identifies a gap, the fix is not just implementing the control -- it is also implementing the evidence capture mechanism. When you run a penetration test, the report itself is evidence but so is the remediation tracking that follows.

The organizations that make SOC 2 sustainable -- not just passable once but a repeatable annual process -- are those that build evidence collection into their daily operations. Every access review automatically produces a document. Every change ticket captures the required fields. Every alert response is logged with timestamps. The audit becomes a validation of what already exists, not a frantic documentation exercise.

If you are early in your SOC 2 journey, invest the time upfront to build evidence collection into your processes. If you are preparing for a renewal, use this guide to identify and close gaps before your auditor arrives. Either way, the work you put into evidence collection directly determines how smooth your audit experience will be.

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

We've completed 170+ security engagements across web apps, APIs, cloud infrastructure, and AI-generated codebases. Everything we publish here comes from patterns we see in real client work.