SOC 2 Evidence Collection Guide: What Auditors Actually Want

How do automated and manual evidence differ?

Every SOC 2 control requires evidence — documentation that demonstrates the control is designed and operating as intended. Evidence falls into two categories, and we recommend understanding the distinction before you begin planning.

Automated Evidence

Automated evidence is collected continuously by your GRC platform through integrations with your infrastructure and tools. You configure the integration once and the platform collects evidence on an ongoing basis.

Automated evidence runs continuously without human intervention. The risk we see most often is integration disconnection — if an integration breaks, evidence collection stops, creating a gap that cannot be backfilled.

Manual Evidence

Manual evidence requires human action to produce and upload. No GRC platform can fully automate these activities because they involve judgment, analysis, or coordination that cannot be reduced to an API call.

In our experience, manual evidence is the source of most audit exceptions because it depends on human scheduling and follow-through.

Which evidence supports each control category?

CC1-CC2: Control Environment and Communication

What auditors want:

• Organizational chart showing security governance structure
• Evidence of security responsibilities in job descriptions or role definitions
• Communication records showing security policies were distributed to all employees
• Policy acknowledgment records (all employees, all policies)
• Board or leadership meeting minutes discussing security topics

Common gap: We frequently see missing leadership security discussion documentation. Our recommendation is to add a standing security update item to quarterly leadership meetings and document it in meeting minutes. This is low-effort but high-impact.

CC3: Risk Assessment

What auditors want:

• Formal risk assessment report dated within the observation period
• Risk register listing identified risks with likelihood, impact, and risk score
• Treatment plans for each identified risk (accept, mitigate, transfer, avoid)
• Evidence that the risk assessment methodology was followed consistently
• Documentation of any changes to risk ratings during the period

Common gap: We see risk assessments completed at the start of the engagement but never updated when new risks emerge. We recommend treating the risk register as a living document and updating it when material changes occur — new services launched, infrastructure changes, vendor changes.

CC5: Control Activities

Common gap: Policies approved but not acknowledged by all employees.

CC6: Logical and Physical Access

Common gap: Quarterly access reviews missed or not documented. We tell every client the same thing: schedule access reviews on fixed calendar dates (first week of each quarter) and document even when no findings are identified. A clean review is still evidence.

CC7: System Operations

What auditors want:

• Security monitoring configuration evidence: alerting rules, detection mechanisms
• Evidence of alert response: logs showing security alerts were investigated and resolved
• Vulnerability scan results and remediation evidence across the observation period
• Penetration test report with findings and remediation tracking
• Incident response plan documentation
• Incident response tabletop exercise records
• Actual incident records (if any incidents occurred) with documented response and resolution

Common gap: Vulnerability scan findings not remediated in a timely manner.

CC8: Change Management

What auditors want:

• Evidence of code review requirements: pull request configurations requiring approval
• Branch protection settings preventing direct production commits
• Sample of change records showing the change management process was followed: request, approval, testing, deployment
• Evidence that emergency changes followed an expedited but documented process
• Release documentation or deployment records

Common gap: Emergency or hotfix deployments that bypass the standard approval process without documentation. In our experience, the fix is straightforward: define an emergency change procedure that requires at minimum a post-deployment review and approval.

CC9: Risk Mitigation (Vendor Management)

What auditors want:

• Complete vendor inventory listing all third-party vendors that handle customer data or provide critical services
• Vendor security assessment records for critical vendors
• Vendor SOC 2 reports, ISO 27001 certificates, or security questionnaire responses
• Business continuity and disaster recovery test results
• Backup verification records showing backups are running and recoverable

Common gap: Vendor security documentation not collected or expired. We always advise starting vendor assessments early, sending requests to all critical vendors simultaneously, and following up aggressively with non-responsive vendors. Vendor responsiveness is outside your control, so the earlier you start the better.

Evidence Organization Best Practices

Naming Conventions

Consistent naming makes evidence retrieval during fieldwork dramatically faster. We recommend this format:

[Date]-[Category]-[Description].[ext]
2026-01-15-access-review-q1-production-systems.pdf
2026-03-01-risk-assessment-annual-report.pdf
2026-02-20-vendor-assessment-aws.pdf
2026-01-10-pen-test-report-acme-security.pdf

Folder Structure

We advise organizing evidence by control category to match how auditors review:

/CC1-CC2-Control-Environment/
/CC3-Risk-Assessment/
/CC5-Control-Activities/
/CC6-Access-Controls/
/CC7-System-Operations/
/CC8-Change-Management/
/CC9-Risk-Mitigation/

Most GRC platforms organize evidence by control category automatically. If you are supplementing with manual uploads, we recommend following the platform's organizational structure rather than inventing your own.

Evidence Freshness Requirements

How do you build a Sustainable Evidence Cadence?

Establish a recurring evidence schedule aligned with the reporting period agreed with the auditor. Track missed tasks and exceptions rather than treating a schedule as a guarantee of an unmodified opinion. We walk every client through this cadence.

Monthly Tasks

• Review GRC platform dashboard for any disconnected integrations or failing evidence collection
• Verify vulnerability scans are running and results are being collected
• Check for any new employees who need onboarding compliance tasks (training, policy acknowledgment, background check, agent installation)
• Verify any departing employees were properly deprovisioned

Quarterly Tasks

• Conduct access review across all critical systems
• Document leadership security update (meeting minutes or presentation)
• Review and update vendor inventory if new vendors were added
• Verify all automated evidence streams are collecting without gaps

Annual Tasks

• Conduct formal risk assessment and update risk register
• Complete security awareness training for all employees
• Review and approve all policies (update if needed)
• Conduct incident response tabletop exercise
• Complete penetration test
• Test business continuity and disaster recovery procedures
• Conduct or update vendor security assessments for critical vendors

Setting Up Reminders

We recommend configuring your GRC platform to alert you when manual evidence tasks are approaching their due dates. Supplement with calendar invitations for quarterly and annual tasks assigned to the compliance lead. Build a shared compliance calendar visible to all team members who contribute evidence. In our experience, the companies that maintain a clean evidence trail are the ones that treat evidence collection as an ongoing operational discipline, not a pre-audit scramble.

AICPA & CIMA’s SOC overview describes CPA assurance services. It defines the assurance context; it does not establish vendor rankings, market prices, or a particular company’s readiness.