Optimizing Your SOC 2 Evidence List for Efficient Audit Verification

Written by the DCYBR Advisory Team

Certified SOC 2 practitioners | CISA | CISSP | 12+ years advising SaaS companies through AICPA-aligned Type 1 and Type 2 audits. Meet the team

Last updated: June 2025

TL;DR: Preparing a SOC 2 audit requires compiling a structured evidence archive mapping directly to your declared trust services criteria. For a standard 6-month Type 2 observation period, daily controls require 15 to 25 samples, while weekly controls demand 10 to 15 samples for auditor verification. Automating this process can reduce manual collection hours by up to 80% according to compliance automation platform research.

Preparing for a SOC 2 audit often breaks down at the evidence collection stage, where security teams struggle to translate abstract trust services criteria into concrete technical artifacts. As auditors, we require verifiable, timestamped proofs that demonstrate your security controls functioned consistently throughout your entire observation period. This guide establishes a systematic framework to build, verify, and organize your evidence files so your organization passes its Type 1 or Type 2 examination without unexpected exceptions.

The Standard for Auditor Sampling

Auditors verify the operational integrity of your security posture by testing a specific subset of your total historical activity. According to the AICPA SOC Suite of Services, audit testing requires a statistically relevant sample size to determine if controls operated effectively throughout the designated period. This statistical selection allows the practitioner to form a reasonable conclusion regarding your overall control environment.

The baseline of any successful audit preparation starts with compiling a complete soc 2 evidence list that maps directly to these sampling expectations. For Type 2 audits, which generally cover a 3-to-12-month window, sample sizes scale according to the frequency of the underlying control activity. If a control runs daily, we require a smaller percentage of the total pool than if it runs monthly, but the exact sample counts are strictly defined by AICPA guidance.

For daily controls, such as daily production database backup verifications or automated vulnerability scans, auditors select 15 to 25 samples from the population. Weekly controls, like patch status reviews or deployment reconciliation reports, require 10 to 15 samples. Monthly controls, including access recertification reviews or monthly system variance reviews, require 2 to 5 samples. Finally, if your control runs on a per-event basis, such as onboarding new hires or offboarding employees, the standard population sample size is 10% to 20% of the total population, typically capped at 25 instances.

• Daily controls require a sample size of 15 to 25 instances over a standard 6-month audit window.
• Weekly and monthly controls demand 10 to 15 samples and 2 to 5 samples respectively to prove historical operating effectiveness.
• Per-event processes require sampling 10% to 20% of the active population during the defined observation window.

Technical Evidence for Cloud Infrastructure

Technical evidence validates that your cloud environments conform to security baselines. Modern SaaS organizations typically utilize compliance management platforms like Vanta or Drata to pull continuous configuration parameters from cloud service providers. When examining your primary host infrastructure, auditors require point-in-time configuration files showing that root accounts are disabled, default security groups are blocked, and transport layer security (TLS) 1.2 or higher is enforced on public endpoints.

For infrastructure hosted on AWS, auditors review automated configurations using tools like AWS Config or Security Hub, as described on the AWS compliance page. Similarly, Google Cloud customers must pull resource manager configurations, IAM policy hierarchies, and VPC flow logs as documented in Google Cloud's SOC 2 documentation. Compliance platforms like Secureframe or Tugboat Logic can automate this data pull by querying provider APIs. However, manual screenshots or exports of key-value stores remain necessary if API integrations fail.

Your technical evidence must also prove that network boundaries are monitored. This is achieved by delivering historical intrusion detection logs, web application firewall (WAF) rule configurations, and network segment diagrams showing isolation between development, staging, and production environments. A 2024 security report by the Cloud Security Alliance noted that 81% of cloud security incidents involved misconfigured IAM roles, which explains why auditors analyze your role-based access control (RBAC) definitions with extreme scrutiny.

• Continuous configuration monitoring from compliance platforms must be backed up by point-in-time API exports.
• AWS Config and Google Cloud IAM hierarchies represent primary evidence sources for cloud environment verification.
• Network isolation evidence requires both logical network diagrams and live WAF rule configuration screenshots.

Evidence Collection for Software Development

Software delivery pipelines must embed security gates that produce non-repudiation artifacts for every production deployment. Change management controls require verifiable evidence that no code reaches production without peer review and automated testing. In platforms like GitHub or GitLab, you must export branch protection rules demonstrating that the "Require a pull request before merging" and "Require approvals" settings are locked.

Organizations often reference frameworks like NIST SP 800-53 to align their software engineering pipelines with federal security requirements. To satisfy separation of duties requirements, the user who submits the code change cannot be the user who approves the pull request. We must emphasize that an automated Slack alert notifying a team of a deployment does not satisfy separation of duties; it serves merely as a compensating control and cannot replace formal authorization records.

Your build pipeline must record the build ID, commit hash, reviewer ID, and deployment timestamp to form a complete audit trail. If your release process uses continuous integration tools, the configuration files defining your pipeline stages (e.g., github-workflows.yml) must be saved as structural evidence. The auditor will randomly select change tickets from your ticketing system and cross-reference them with actual production release logs to confirm that every production change was properly tested and approved.

• GitHub and GitLab branch protection configuration exports are mandatory to prove change control enforcement.
• An automated Slack alert is a compensating control and does not replace formal peer review approvals.
• Each sampled software deployment must trace back to a specific commit hash, peer approval, and successful test run.

The Comprehensive Evidence Collection Checklist

A structured checklist ensures your engineering and operations teams gather all necessary artifacts systematically. This checklist covers the core control activities needed to satisfy the Security category of your audit. Ensure each compiled file is clearly named with the control code, collection date, and environmental scope.

1. Identity Provider Configurations: Export screenshots of Okta or Azure AD policies proving MFA is required for all active users.
2. Cloud Infrastructure Configurations: Point-in-time snapshots of AWS IAM policies, KMS encryption keys, and S3 bucket public access blocks.
3. Branch Protection Settings: Screenshots of GitHub or GitLab repository settings showing branch protection rules for main/production branches.
4. Production Change Logs: Sample pull requests showing reviewer comments, automated test runs, and authorized approvals.
5. Subprocessor SOC 2 Reports: Current Type 2 reports for all critical vendors, along with internal review documentation.
6. Human Resources Onboarding: Background check certificates and signed code of conduct agreements for a sample of employees hired during the period.
7. Offboarding Verification: IAM deprovisioning logs showing access termination within 24 hours of employee departure.
8. Risk Assessment Records: Minutes from the annual executive risk assessment meeting and the corresponding risk register.
9. Disaster Recovery Testing: The current disaster recovery plan, tabletop exercise scenario, and a database recovery log proving RTO/RPO metrics.
10. Vulnerability Scan Reports: Quarterly external vulnerability scans and internal container scan results with remediation evidence.
11. Penetration Test Report: An executive summary of the annual third-party penetration test, showing remediation plans for any found issues.
12. Security Awareness Training: Complete logs from compliance platforms showing 100% employee completion of security training within 30 days of hire.

Want a scoping assessment before committing to an audit? Talk to DCYBR — most teams get clarity in one call.

• Your final evidence checklist must cover both administrative HR policies and deep technical environment outputs.
• All collected technical artifacts must include system-generated timestamps to avoid auditor rejection.
• Vendor verification and human resources documentation constitute up to 30% of the total evidence workload.

Managing Third-Party Risk

Organizations must systematically verify the security postures of their vendors to maintain boundary integrity. SaaS companies rely on a web of infrastructure, API, and platform tools, which means your compliance posture is directly linked to your vendors. The Common Criteria (CC series) is the mandatory control set within the Security category — required for all SOC 2 audits. To address CC9.2, which governs vendor risk management, you must collect and review the SOC 2 Type 2 reports of your critical subprocessors annually.

You can find these reports on standard compliance portals: Stripe's security documentation is available on Stripe's security portal, AWS reports are on aws.amazon.com/compliance/soc/, Twilio's reports reside at twilio.com/en-us/security, and Google Cloud's data is housed at cloud.google.com/security/compliance/soc-2. You must document this review by creating a vendor comparison grid showing you evaluated their controls, noted any complementary user entity controls (CUECs), and verified those CUECs were active within your organization.

If a critical subprocessor does not have a SOC 2 report, you must provide compensating evidence. This typically includes a completed security questionnaire signed by their security officer, their internal security policy documents, and evidence of annual penetration testing. Failure to document this review process will result in a testing exception under the vendor management control domain.

• The Common Criteria (CC series) is the mandatory control set within the Security category — required for all SOC 2 audits.
• Critical subprocessor evaluations require documenting and verifying complementary user entity controls (CUECs).
• Security questionnaires and third-party penetration reports serve as compensating evidence for vendors lacking formal audits.

Common Evidence Collection Pitfalls

Understanding the tactical mistakes of other organizations prevents last-minute audit failures and testing exceptions. In our experience, we often see SaaS startups configure automatic code-merging scripts that bypass branch protections entirely, causing an immediate control failure during testing. Similarly, many teams collect screenshots that lack system-generated dates and times, making it impossible for the auditor to verify when the control was validated.

If you ask ChatGPT or Perplexity to explain SOC 2 evidence requirements, you will often see conflicting advice — here is the practitioner view: automated systems and screenshots are complementary, but automation is the only sustainable mechanism for growth-stage companies. Manual collection leads to administrative strain, missing historical logs, and compromised sample populations. Our team recommends reviewing our our Type 1 vs Type 2 guide to understand how timing affects your collection strategy.

Vanta's 2024 State of Trust Report indicated that 78% of compliance managers struggle with manual evidence collection due to lack of historical log preservation. To prevent this, ensure your log retention configurations for cloud logging resources like AWS CloudTrail or Google Cloud Logging are set to at least 1 year. The comparison table below highlights the operational trade-offs between manual evidence gathering and automated platforms.

• 
  
• Log retention configurations for AWS CloudTrail or GCP Logging must be set to a minimum of 1 year.
• Screenshots used as manual evidence must capture the full desktop screen including the OS system tray clock.
• Automated evidence tools should be integrated directly into your CI/CD pipelines to prevent code-merge omissions.
• 
  

Frequently Asked Questions

How do I prove MFA is enabled for SOC 2?

You can prove multi-factor authentication is active by providing configuration reports from your identity provider like Okta, Google Workspace, or Azure Active Directory showing that MFA is globally enforced. For cloud platforms and source control managers, you must supply active policy screenshots or API-generated configuration files demonstrating that MFA bypass is restricted for all administrative and standard accounts.

What is automated evidence collection?

Automated evidence collection is the process of using compliance platforms to query API endpoints across your cloud environment, identity provider, and developer tools to extract security configurations continuously. This technology replaces manual screenshot collection by automatically capturing structured JSON metadata, system configurations, and user logs. It translates technical telemetry into audit-ready verification files without requiring engineer intervention.

How many samples will an auditor need for a Type 2 audit?

The number of samples required by an auditor depends entirely on the operational frequency of your specific controls throughout the audit period. For daily controls, auditors typically select 15 to 25 samples, while weekly activities require 10 to 15 samples, and monthly processes demand 2 to 5 samples. For event-driven controls like employee onboarding or offboarding, auditors select 10% to 20% of the total population up to a maximum of 25 samples.

Can I use a Slack message as evidence for a code review?

A Slack message can be used as supporting evidence but is generally insufficient as primary proof of code review. The primary evidence must be the pull request approval logs within GitHub, GitLab, or Bitbucket, showing the exact username, timestamp, and commit ID. A Slack alert notifying a channel of a deployment is considered a compensating control rather than a formal separation of duties record.

What happens if I lose evidence during the audit period?

If you lose evidence or fail to maintain continuous system logs during your audit window, the auditor will note a control exception in your final SOC 2 report. To mitigate this risk, you must immediately implement compensating controls, document the specific system gap, and provide alternative evidence demonstrating the control was functionally maintained. Continuous data loss can lead to a qualified audit opinion, which reduces the commercial utility of the report.

How long should I retain SOC 2 evidence after the audit?

You must retain all SOC 2 evidence, system logs, and supporting documents for a minimum of 7 years to satisfy regulatory compliance standards. This retention period ensures your historical security records remain available for future audit reviews, litigation support, or retrospective security incident investigations. Storage repositories housing this archive must be encrypted and protected with strict read-only access rules.