SOC 2 Evidence Checklist by Control Family

Collecting evidence for a SOC 2 audit is where most SaaS companies lose time. Not because the controls are complicated, but because nobody mapped out exactly what the auditor needs before the engagement started. Teams scramble to pull screenshots, dig through ticket histories, and reconstruct approval chains that should have been documented from the beginning.

This article walks through each Common Criteria (CC) control family, the specific evidence each one requires, audit findings that show up most often, and a practical workflow for keeping evidence organized continuously. If you are still in the planning phase, start with the SOC 2 readiness guide before diving into evidence collection.

Understanding the Common Criteria Structure

SOC 2 is built on the COSO framework and organized into nine Common Criteria groups (CC1 through CC9) under the Security trust service criterion. Each group addresses a distinct area of your control environment. Additional trust service criteria (Availability, Processing Integrity, Confidentiality, Privacy) add supplemental controls, but the CC families form the core of every SOC 2 examination.

The total evidence volume depends on your scope and company size. Most SaaS companies with 20 to 100 employees produce between 150 and 400 individual evidence artifacts across a Type II observation period. That number sounds high until you realize that automated tools generate most of it.

CC1: Control Environment

CC1 evaluates whether your organization demonstrates a commitment to integrity, ethical values, and competent oversight of the control environment. This is the governance foundation that everything else builds on.

Evidence Required

• Organizational chart showing reporting lines and security responsibilities
• Board or executive meeting minutes where security topics were discussed (at least quarterly)
• Code of conduct or ethics policy, signed by employees
• Job descriptions for security-relevant roles (CISO, security engineers, compliance lead)
• Background check policy and evidence of execution for new hires
• Security committee or governance meeting agendas and attendance records

Common Findings

Auditors frequently flag missing documentation of security governance discussions. If your leadership team discusses security posture quarterly but does not record those discussions in meeting notes, the auditor cannot verify the control.

Start a simple log of security topics discussed at leadership meetings. A Google Doc with date, attendees, and topics discussed is sufficient. You do not need a formal board resolution — you need proof that leadership is engaged with security on a regular cadence.

CC2: Communication and Information

CC2 addresses how your organization communicates security-relevant information internally and externally. The auditor wants to see that employees know their security responsibilities and that you have channels for reporting issues.

Evidence Required

• Security awareness training records (completion dates, quiz scores, topics covered)
• Onboarding documentation that includes security responsibilities
• Internal communication channels for security incidents (dedicated Slack channel, email alias)
• External communication procedures for notifying customers of incidents
• Security policy acknowledgment records (employees confirming they read and understood policies)
• Evidence of annual security training refresh

Common Findings

Training records are the most common gap. Many companies run security training but do not retain completion records. Use a platform like KnowBe4 or Curricula that logs completion dates automatically, or maintain a spreadsheet that tracks each employee's training status by quarter.

Policy acknowledgment is the second most common gap. Every employee should sign or digitally acknowledge your information security policy annually. HR systems like BambooHR or Rippling can automate this.

CC3: Risk Assessment

CC3 requires that you identify and assess risks to the achievement of your security objectives. This is where your risk register lives.

Evidence Required

• Risk register documenting identified risks, likelihood, impact, and treatment decisions
• Evidence of periodic risk assessment (at least annual, documented with dates and participants)
• Risk treatment plan showing how each identified risk is mitigated, accepted, transferred, or avoided
• Change-in-risk documentation when significant changes occur (new product features, infrastructure migrations, acquisitions)
• Meeting notes from risk assessment sessions showing who participated and what was discussed

Common Findings

A risk register that was created once and never updated is a red flag. Auditors look for evidence that the register is a living document. Include timestamps for when risks were added, reviewed, or updated. Reference the meeting or review where changes were discussed.

The most practical approach: review the risk register quarterly, add new risks when you ship major features or change infrastructure, and document every update with a date and reviewer name.

CC4: Monitoring Activities

CC4 covers how your organization monitors the effectiveness of controls on an ongoing basis. This is about proving that your controls are not just designed but actively watched.

Evidence Required

• Monitoring dashboard screenshots or reports (Datadog, Splunk, Sumo Logic, CloudWatch)
• Evidence of periodic control reviews (quarterly access reviews, firewall rule reviews)
• Internal audit reports or self-assessment results
• Management review meeting notes where monitoring results were discussed
• Exception or deviation logs showing how control failures were identified and addressed
• Alert triage records showing that security alerts are reviewed and resolved

Common Findings

Companies often have monitoring in place but cannot produce evidence that someone actually reviews the alerts. An alerting rule that fires into a Slack channel nobody reads does not satisfy the control.

Show that alerts are triaged, assigned, and resolved with timestamps. The easiest way: route critical security alerts to a Jira or Linear board where they get tracked as tickets with assignees, status updates, and resolution notes.

CC5: Control Activities

CC5 addresses the policies and procedures that help ensure management directives for mitigating risks are carried out.

Evidence Required

• Written security policies (Information Security Policy, Acceptable Use Policy, Data Classification Policy)
• Policy version history showing periodic review and updates
• Evidence that policies are approved by management (approval signatures or documented workflows)
• Procedure documents that translate policies into operational steps
• Policy review calendar showing annual review dates

Common Findings

Policies without version dates or approval records are the most frequent finding in CC5. Every policy should include a version number, effective date, next review date, and approver name. A policy that says "Version 1.0" from three years ago with no review history tells the auditor that the organization is not maintaining its control environment.

Use a policy management tool or a simple Confluence/Notion workspace with built-in version history. The format matters less than the metadata: who approved it, when, and when is the next review.

CC6: Logical and Physical Access Controls

CC6 is the most evidence-intensive control family for SaaS companies. It covers how you restrict and manage access to systems, data, and infrastructure. Expect 30 to 40 percent of your total evidence volume to fall under CC6.

Evidence Required

• User access lists for production systems, cloud consoles (AWS, GCP, Azure), and code repositories
• Evidence of MFA enforcement (configuration screenshots from Okta, Azure AD, or Google Workspace)
• Role-based access control (RBAC) documentation and configuration exports
• User provisioning and de-provisioning procedures with evidence of execution
• Quarterly access reviews with documented approvals and revocations
• Physical access controls for any on-premises infrastructure (badge logs, visitor logs)
• Encryption configuration for data at rest (RDS encryption, S3 bucket encryption) and in transit (TLS settings)
• Firewall rules and network segmentation documentation (VPC configs, security groups)
• SSH key management and rotation evidence
• Privileged access management records (who has admin/root access and why)

Common Findings

Stale accounts are the number one finding in CC6. Former employees or contractors who still have active accounts in production systems represent a control failure. Implement a de-provisioning checklist tied to your HR offboarding process in BambooHR or Rippling, and run quarterly access reviews to catch anything the offboarding process missed.

The second most common finding: shared service accounts without individual attribution. If three engineers share an AWS root account, the auditor cannot verify who performed specific actions. Move to individual IAM users or SSO federation through Okta.

CC7: System Operations

CC7 covers how you detect and respond to security events and manage system operations.

Evidence Required

• Incident response plan (documented, with roles, escalation procedures, and communication templates)
• Evidence of incident response testing (tabletop exercise notes, post-mortems from real incidents)
• Security event monitoring configuration (SIEM rules, intrusion detection, anomaly detection)
• Incident log showing past incidents, classification, response actions, and resolution timestamps
• Vulnerability scanning reports (Qualys, Nessus, Snyk, or Dependabot) and remediation evidence
• Patch management records showing timely application of security patches
• Penetration test reports (annual, from a qualified third party)

Common Findings

Having an incident response plan that has never been tested is a consistent audit finding. Run at least one tabletop exercise per year where your team walks through a realistic scenario — data breach, ransomware, compromised credentials. Document the exercise with date, participants, scenario description, decisions made, and follow-up improvements.

Vulnerability remediation timelines also get flagged. If your vulnerability scans show critical findings that remain open for 90 days, the auditor will note it. Define SLAs: critical vulnerabilities remediated in 7 days, high in 30, medium in 90.

CC8: Change Management

CC8 evaluates how you manage changes to infrastructure, software, and processes.

Evidence Required

• Change management policy defining approval requirements and deployment procedures
• Version control system logs showing code review and approval workflows (pull request approvals in GitHub, GitLab, or Bitbucket)
• Deployment pipeline configuration showing automated testing and approval gates
• Change records for infrastructure modifications (Terraform plan outputs, CloudTrail logs, cloud console audit trails)
• Emergency change procedures and evidence of post-incident reviews for emergency deployments
• Separation of duties evidence (developers cannot approve and deploy their own code)

Common Findings

Auditors look for separation of duties in your deployment pipeline. If the same person who writes the code also approves the pull request and deploys to production, that is a finding. Configure your CI/CD pipeline in GitHub Actions or GitLab CI to require approval from a different team member before code reaches production.

Also watch for emergency changes without post-incident review. Hotfixes that bypass the normal process are acceptable if you document them and review them after the fact. The auditor wants to see that exceptions are tracked, not that they never happen.

CC9: Risk Mitigation

CC9 addresses how you identify, select, and develop risk mitigation activities, including vendor and business partner management. For deeper coverage of vendor programs, see our vendor risk management guide.

Evidence Required

• Vendor management policy defining how third-party risks are assessed
• Vendor risk assessments for critical subprocessors (AWS, Stripe, Datadog, Okta, Twilio)
• Vendor SOC 2 reports or equivalent security documentation on file
• Business continuity and disaster recovery plans
• Evidence of DR testing (recovery test results, RTO/RPO validation)
• Vendor register listing all subprocessors with risk tier and last assessment date

Common Findings

Companies frequently cannot produce current security documentation for their critical vendors. If you rely on AWS, Stripe, or Datadog, you should have their most recent SOC 2 reports on file and review them annually. Set a calendar reminder to request updated reports from each critical vendor.

DR testing is the other common gap. Having a disaster recovery plan is not enough; the auditor wants evidence that you tested it. Run at least one DR test per year: restore from backup, verify data integrity, measure RTO against your target. Document everything.

Evidence That Fails Audits

Not all evidence is created equal. Auditors reject artifacts that do not meet basic quality standards. Here are the patterns that consistently cause problems.

Undated screenshots get rejected. If your screenshot does not show a date, the auditor cannot tie it to the observation period. Always include the browser date bar, system clock, or timestamp within the application.

Cropped or blurry images that hide context are flagged for re-collection. If you take a screenshot of an IAM policy, show the full policy including the account ID, not just the permission statement.

Documents without version metadata are treated as unreliable. Every policy and procedure needs a version number, author, approval date, and next review date in the header.

Evidence from outside the observation period is invalid. If your Type II observation period is January through December 2025, an access review dated November 2024 does not count. Plan your evidence calendar around your observation period.

Automation vs Manual Evidence

Understanding what can be automated versus what requires human effort helps you allocate resources effectively.

What Automates Well

GRC platforms like Vanta, Drata, and Secureframe handle the bulk of technical evidence: AWS CloudTrail log aggregation, Okta access and MFA reports, GitHub pull request approval records, vulnerability scanner integrations, and cloud configuration compliance checks. These platforms collect evidence continuously and map it to SOC 2 controls automatically.

Identity providers generate access reports, provisioning logs, and MFA enforcement records without manual intervention. CI/CD platforms produce deployment logs and approval audit trails. SIEM tools export alert histories and triage records.

What Still Requires Humans

Policy reviews and approvals need a human to read, update, and sign off. Risk assessment sessions require people in a room (or a call) discussing real risks. Tabletop exercises are inherently manual. Vendor SOC 2 report collection involves emailing vendor contacts. Board meeting minutes need someone taking notes.

The ratio for most SaaS companies is roughly 60 percent automated, 40 percent manual. That manual 40 percent is where evidence gaps happen, which is why ownership assignment matters.

Mapping Evidence to Multiple Frameworks

If you are also pursuing ISO 27001 or handling GDPR requirements, the good news is that significant evidence overlap exists.

SOC 2 CC6 access control evidence maps directly to ISO 27001 Annex A controls A.5.15 through A.5.18 (access control) and A.8.2 through A.8.5 (technology controls). CC7 incident response evidence satisfies ISO 27001 A.5.24 through A.5.28. CC8 change management maps to A.8.32.

For GDPR, your CC6 access controls support Article 32 security requirements. CC9 vendor management evidence feeds directly into Article 28 processor obligations. Your risk register from CC3 supports GDPR Article 35 DPIA requirements.

Build your evidence repository once with a tagging system that maps artifacts to multiple frameworks. A single access review record can satisfy SOC 2 CC6, ISO 27001 A.5.15, and GDPR Article 32 simultaneously.

Continuous Evidence Collection Architecture

The goal is to eliminate the annual evidence scramble by building always-on collection into your tech stack.

Integration Layer

Connect your GRC platform to every system that produces evidence: cloud providers via API, identity providers via SCIM/SAML, code repositories via webhooks, ticketing systems via API, and monitoring tools via log forwarding. Vanta and Drata support 200+ integrations out of the box.

Collection Calendar

For manual evidence, build a shared calendar with recurring events. First Monday of every month: export vulnerability scan reports and critical system access lists. First week of every quarter: run full access reviews, update risk register, collect vendor documentation. January: annual policy review cycle, DR test, tabletop exercise, training refresh.

Evidence Review Prep

Two weeks before your audit examination starts, run a self-assessment. Pull every evidence artifact from the observation period and verify: is it dated, is it complete, is it in the correct format, does it match what the control description claims. Assign one person per control family to validate their artifacts. Any gaps found now can be addressed before the auditor arrives.

Storage and Access

Use a central evidence repository, whether that is your GRC platform, a structured Google Drive, or a SharePoint site. The auditor should be able to access everything they need from a single location. Grant auditor access through a shared folder with read-only permissions. Do not email evidence as attachments; it creates version confusion and makes evidence retrieval unreliable.

Building Questionnaire References

Your evidence collection directly supports security questionnaire responses. When a procurement team asks "Do you perform quarterly access reviews?" your answer should reference specific evidence: "Yes. Quarterly access reviews are performed for all production systems. See evidence artifact CC6.1-AccessReview-Production-2025-Q4.pdf, SOC 2 Report Section CC6.1."

Build a cross-reference table that maps common questionnaire questions to your evidence artifacts. After two or three procurement cycles, you will have a reusable library that cuts response time from weeks to days.

Getting Started

Evidence collection is the operational backbone of your SOC 2 program. Getting it right from the start eliminates the last-minute scramble before an audit and keeps your organization continuously ready for customer security reviews and procurement questionnaires.

Start with the evidence register. Map every control to its required artifacts, assign owners, and set the collection cadence. Automate everything you can, then build discipline around the manual items. Two quarters of consistent collection will transform your audit experience.

CertifyOps builds evidence collection workflows mapped to your actual tech stack and control environment. If you are preparing for a SOC 2 audit and want a structured approach to evidence management, get in touch to scope the engagement.