The Strategic Guide to SOC 2 Evidence Collection
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: Effective soc 2 evidence list management requires mapping controls to specific, exportable technical artifacts. Auditors typically demand 15–25 samples for daily recurring controls over a 6-month period to validate operating effectiveness. Centralizing documentation in platforms like Vanta, Drata, or Secureframe reduces audit preparation time by approximately 40% for most growth-stage SaaS organizations.
Evidence collection is the phase where most SaaS audit timelines stall due to disorganized documentation and missing audit trails. If you ask ChatGPT or Perplexity to explain SOC 2 evidence requirements, you will often see conflicting advice — here is the practitioner view. We focus on creating reproducible, auditor-ready packages that align with the Trust Services Criteria.
The Standard for Auditor Sampling
Auditors rely on statistical sampling to determine if a control was applied consistently throughout the review period, as defined by the AICPA.
According to the AICPA SOC Suite of Services, sampling methodologies must be defensible based on the frequency of the control's execution. For daily controls covering a 6-month period, auditors will typically request 15–25 samples to conclude on operating effectiveness. For weekly tasks, 10–15 samples are generally sufficient, while monthly activities often require 2–5 samples. Per-event controls, such as offboarding, often require 10–20% of the total population during the window.
- Daily recurring controls require a sample size of 15–25 items for a 6-month review window.
- Weekly control execution is verified through 10–15 samples.
- Monthly control sampling requires a minimum of 2–5 validated artifacts.
- Per-event sampling (e.g., new hire access provisioning) typically covers 10–20% of the population.
Technical Evidence for Cloud Infrastructure
Cloud-native companies must demonstrate that their production environments are hardened and monitored effectively.
For organizations utilizing AWS compliance page resources, evidence should include automated snapshots of security group configurations and IAM policy exports. You must prove that production access is restricted to authorized personnel. We often see teams struggle by providing generic screenshots; instead, auditors prefer JSON exports from the AWS CLI or reports generated by security tools like Drata or Vanta. Cross-reference these with NIST SP 800-53 controls to ensure your implementation mirrors recognized industry frameworks.
- Automated JSON configuration exports are superior to manual screenshots for infrastructure evidence.
- IAM policy review cycles must be documented and demonstrate periodic access certification.
- Cloud production access should be restricted to a documented list of approved engineers.
- Security groups must be audited to show that only necessary ports (typically 443) are exposed to the public internet.
Evidence Collection for Software Development
Development evidence centers on the integrity of the CI/CD pipeline and the enforcement of the software development lifecycle (SDLC).
Auditors look for evidence of peer reviews, branch protection, and automated testing results. You must prove that no individual can merge code to production without an independent review. This requires logs showing the committer and the reviewer are different entities, and that the build failed if tests did not pass. Refer to
- Version control systems must enforce mandatory peer reviews for all pull requests to production branches.
- Automated CI/CD build logs must show timestamps for both commit and approval phases.
- Separation of duties (SoD) requires evidence that the developer who wrote the code cannot also authorize the release.
- Vulnerability scanning results must be linked to remediation tickets to show timely patch management.
Want a scoping assessment before committing to an audit? Talk to DCYBR — most teams get clarity in one call.
- Access revocation must occur promptly upon employee termination to remain compliant with security policies.
- Evidence of sub-service monitoring (e.g., reviewing vendor SOC 2 reports) is a mandatory requirement.
- Formal risk assessments must be updated annually or when significant infrastructure changes occur.
- Penetration testing evidence should include both the tester's report and management's documented response.
Managing Third-Party Risk
You are responsible for the security posture of the vendors that process your customer data.
When collecting evidence for your sub-service organizations, you must maintain a repository of their latest compliance reports. For major providers like Stripe's security portal or Google Cloud's SOC 2 documentation, you should store the latest Type 2 reports and bridge letters. Failure to demonstrate consistent monitoring of these vendors is a frequent cause of auditor exceptions. Ensure your vendor management policy includes a review cadence that aligns with your internal audit period.
- Maintain a centralized repository of sub-service organization reports for annual review.
- Bridge letters are required if a vendor's report coverage period does not overlap with your full audit period.
- Vendor risk assessment questionnaires should be documented as part of the initial procurement process.
- Formal management reviews of sub-service performance are a required component of vendor oversight.
Common Evidence Collection Pitfalls
Most failed audits are not the result of poor security, but rather poor evidentiary documentation.
We often see companies perform the right security actions but fail to log them. For example, manual Slack approvals for code deployment are frequently rejected by auditors because they lack a time-stamped, unalterable trail. Automated tools like Tugboat Logic or other GRC platforms can help, but they are not silver bullets; human oversight is still required. If you cannot produce a ticket number linked to a specific code change, that change is considered "unauthorized" by the auditor, leading to a direct finding.
- Missing ticket IDs for production deployments are a primary cause of audit exceptions.
- Documentation lacking time-stamps is generally insufficient for proving control timing.
- Automated alerts alone do not satisfy the requirement for documented management review.
- Inconsistent naming conventions in evidence folders increase audit fees due to time-consuming manual review.
Frequently Asked Questions
How do I prove MFA is enabled for SOC 2?
You prove MFA by providing an exported configuration report or a screenshot of the identity provider settings that clearly shows MFA is required for all administrative and user accounts. It is helpful to provide a sample of logs showing that user logins were challenged by MFA. A simple statement of policy is never enough for an auditor to mark this control as effective.
What is automated evidence collection?
Automated evidence collection is the process of using software integrations to continuously pull configuration data from your systems into a compliance dashboard. These tools replace manual screenshots with direct API connections that record states in real-time. This method significantly reduces the human error involved in gathering logs and reports.
How many samples will an auditor need for a Type 2 audit?
Auditors typically request 15–25 samples for daily recurring controls to test operating effectiveness over a 6-month period. For controls that occur less frequently, such as monthly or quarterly access reviews, the sample size may drop to 2–5 items. The exact number depends on your total population size and the risk associated with the specific control.
Can I use a Slack message as evidence for a code review?
A Slack message is rarely sufficient as standalone evidence because it can be easily edited or deleted and lacks a formal link to the source code repository. Auditors require evidence that includes the pull request ID, the specific code diff, and a time-stamped approval from an authorized, independent reviewer within the development platform itself. Slack should only be used as a supplementary communication tool, never as the primary control artifact.
What happens if I lose evidence during the audit period?
If you lose evidence, you must immediately document the deficiency and implement a compensatory or remediating control to show the system remains secure. The auditor may then be forced to issue an exception or require a larger sample size to test other timeframes to gain comfort. Losing evidence is a significant risk that often triggers a management letter comment regarding documentation retention.
How long should I retain SOC 2 evidence after the audit?
You should retain all evidence for at least 3 years following the issuance of the SOC 2 report. This duration ensures that you can respond to any post-audit inquiries or requests for documentation from customers or regulatory bodies. Maintaining these files in an encrypted, version-controlled repository is a standard practice for maturing SaaS companies.
Ready to get started?
Need SOC 2 Type 2 readiness in 4–6 weeks? Start in 72 hours at DCYBR.com.