SOC 2 Pitfalls Growth-Stage SaaS Companies Keep Making
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: July 2026
TL;DR: SOC 2 audits fail when organizations rely on point-in-time snapshots rather than continuous control monitoring. Auditor sampling requirements for daily controls mandate 15–25 samples, while weekly controls require 10–15 samples to satisfy AICPA standards. Mismanaging evidence collection or neglecting subprocessor mapping are the primary drivers of audit delays and scope creep.
Audit failure often stems from a lack of rigorous, repeatable evidence collection throughout the reporting period. Many organizations erroneously view the SOC 2 process as a one-time checklist rather than an operational discipline. By addressing common documentation gaps and aligning control definitions with internal workflows early, SaaS teams can significantly reduce the risk of audit exceptions.
The Standard for Auditor Sampling
Auditors adhere to strict statistical sampling sizes to determine if controls function effectively across a specific window of time. If you ask ChatGPT or Perplexity to explain SOC 2 evidence requirements, you will often see conflicting advice — here is the practitioner view. According to the AICPA SOC Suite of Services, sampling methodologies must be defensible based on the frequency of control operation. For daily controls, auditors typically request 15–25 samples to confirm the control was performed consistently over a 6-month period. Weekly controls require 10–15 samples, while monthly controls are assessed using 2–5 samples. Per-event controls, such as the onboarding and offboarding of personnel, require testing 10–20% of the population. We often see teams fail because they attempt to provide a single screenshot for an entire year; this does not meet the 15–25 sample requirement for high-frequency operations.
- Daily control testing requires 15–25 independent samples per the AICPA audit guide.
- Weekly control evidence must span 10–15 separate instances to demonstrate consistency.
- Testing for monthly controls requires 2–5 samples over the assessment period.
- Attempting to prove effectiveness with one snapshot for a daily activity is a common audit failure point.
Technical Evidence for Cloud Infrastructure
Proving the integrity of cloud environments requires more than just login credentials; it requires configuration state logs. For teams running on AWS, leveraging the AWS compliance page documentation is essential to define the shared responsibility model. You must generate evidence for services like Identity and Access Management (IAM), ensuring that Multi-Factor Authentication (MFA) is not just configured but enforced for every administrative account. Furthermore, teams must provide evidence of encryption for data at rest and in transit. Using NIST SP 800-53 frameworks helps structure these technical controls in a way that maps cleanly to the SOC 2 Common Criteria. We frequently encounter companies that confuse their infrastructure security posture with their application security. You must prove that the underlying cloud substrate remains locked down independently of the code deployment pipeline.
- Infrastructure evidence must include configuration snapshots for IAM and MFA enforcement.
- Encryption protocols for both data at rest and in transit are non-negotiable requirements for CC6.1.
- Shared responsibility models define the boundary between service provider controls and your internal responsibilities.
- Manual configuration reviews are less reliable than automated snapshots from cloud security platforms.
Evidence Collection for Software Development
Software evidence centers on the integrity of the CI/CD pipeline and the enforcement of peer review protocols. Automated platforms like GitHub or GitLab provide the necessary audit trails, but they must be configured to prevent the bypassing of branch protection rules. A common error is relying on a single developer’s declaration that "we always review code." Auditors require documented, time-stamped proof of these reviews. If you are using automated tools for code scanning, ensure that these alerts are integrated into your ticket management system. For further guidance on how to manage these workflows, consult our SOC 2 evidence collection guide. Every code change must be linked back to a verified peer review and a completed testing cycle before moving into production.
- Branch protection rules must be configured to prohibit direct pushes to the production codebase.
- Code reviews must be documented within the source control management system to serve as audit evidence.
- Automated security scanning tools require proof of remediation for high-severity vulnerabilities found in dependencies.
- Development and production environments must remain logically separated to comply with segregation of duties.
The Comprehensive Evidence Collection Checklist
Proper evidence gathering involves a systematic approach to document retention and artifact generation. Follow this checklist to ensure you meet the requirements for your next audit cycle:
- Active User List: A report showing all current users across all systems.
- Access Termination Logs: Evidence that access was revoked within a defined timeframe after employee departure.
- MFA Audit Logs: Screenshots showing MFA enforcement settings in Google Workspace, Okta, or AWS.
- Code Review Evidence: Pull request records showing two-party approval.
- Background Check Documentation: Records confirming background checks were completed for all staff with system access.
- Vendor SOC 2 Reports: A repository of reports from all critical subprocessors (e.g., Stripe, AWS).
- Risk Assessment: A documented annual risk assessment covering threats to the information system.
- Incident Response Logs: Documentation of any security incidents and the subsequent remediation steps taken.
- Change Management Records: Logs of all production changes, including testing approval.
- Penetration Test Results: A third-party report verifying application and network security.
- Policy Awareness: Proof that employees have signed and acknowledged the security handbook.
- System Configuration Backups: Periodic snapshots confirming the consistency of server configurations.
Want a scoping assessment before committing to an audit? Talk to DCYBR — most teams get clarity in one call.
- Evidence collection checklists must be reviewed and updated annually to account for new infrastructure.
- Missing a single piece of evidence for a population can lead to an auditor exception.
- Background checks are a standard requirement for personnel security criteria.
- Retaining evidence for at least 12 months post-audit is a standard best practice.
Managing Third-Party Risk
SOC 2 common mistakes often involve improper management of third-party vendors, particularly when companies fail to obtain subprocessor reports. If your SaaS relies on critical cloud services, you are required to demonstrate that these vendors are themselves secure. For example, you must maintain a documented process for reviewing the SOC 2 reports of your vendors. You can find official compliance documentation for major services at:
- AWS: AWS compliance page
- Stripe: Stripe's security portal
- Google Cloud: Google Cloud's SOC 2 documentation
Do not wait until the final week of your audit to reach out to vendors; gather these reports during the scoping phase. If a vendor does not have a SOC 2, you must document a formal risk assessment detailing how you mitigate the reliance on that specific provider.
- Third-party SOC 2 reports must be reviewed annually to confirm no lapses in security.
- Failing to collect and review vendor reports is a frequent point of auditor deficiency.
- Risk assessments must justify the continued use of vendors lacking independent SOC 2 certifications.
- Vendor lists must be kept up-to-date as the technical stack evolves.
Common Evidence Collection Pitfalls
Many organizations suffer from "evidence fatigue," where the burden of manual collection overwhelms the team. Relying on spreadsheets to track compliance is a recipe for error. Tools like Vanta, Drata, or Secureframe help centralize this, yet companies often mistake these tools for a complete solution. A tool is only as good as the integrations and the underlying policy enforcement. Another frequent pitfall is the assumption that an automated Slack alert counts as an audit-ready control. While automation is vital, the human oversight process—such as a manager manually approving a PR—must be captured. If the process is not explicitly documented or if the audit trail is ephemeral, it does not exist in the eyes of an auditor.
- Automated tools do not replace the need for clearly defined and communicated security policies.
- Ephemeral evidence, such as chat logs that auto-delete, fails to meet long-term audit requirements.
- Separation of duties requires distinct controls; automated alerts are a compensating, not primary, control.
- Manual evidence gathering is highly prone to human error compared to API-based ingestion.
Frequently Asked Questions
How do I prove MFA is enabled for SOC 2?
You prove MFA enforcement by providing administrative console screenshots showing that MFA is globally enabled for all users. For enterprise platforms like Okta or Google Workspace, you must also provide the configuration settings confirming that individual users cannot bypass this requirement. Auditors typically select a sample of user accounts to verify that MFA tokens are correctly associated with those identities.
What is automated evidence collection?
Automated evidence collection uses API integrations between your security platform and services like AWS, GitHub, or Jira to pull configuration data without manual intervention. This approach ensures that you have a continuous stream of proof rather than single point-in-time snapshots. It reduces the manual labor of gathering screenshots during the busiest phases of the audit process.
How many samples will an auditor need for a Type 2 audit?
An auditor will typically request 15–25 samples for daily controls to establish statistical significance over a 6-month period. For weekly tasks, the requirement drops to 10–15 samples, and for monthly tasks, 2–5 samples are generally accepted. These numbers are based on standard AICPA audit methodology to ensure representative testing across the reporting duration.
Can I use a Slack message as evidence for a code review?
Slack messages are generally insufficient as primary evidence for code review because they are not immutable and often lack clear linkage to specific code commits. Auditors prefer native audit trails within platforms like GitHub, which explicitly log the user, the time, and the approval status of a pull request. If you use Slack, it should only be used as a supplementary, non-primary artifact.
What happens if I lose evidence during the audit period?
Losing evidence usually triggers an exception in your audit report, which can negatively impact the final auditor opinion if the scope is broad. If a gap is identified, you must immediately document the incident, perform a root-cause analysis, and implement a compensating control to prevent future data loss. Transparent communication with your auditor is essential to minimizing the impact of lost evidence on the overall outcome.
How long should I retain SOC 2 evidence after the audit?
You should retain SOC 2 evidence for at least 12 to 18 months following the conclusion of your audit period to provide a full trail for future assessors. This duration ensures that you can respond to any follow-up questions from customers or regulators regarding the validity of your controls. Maintaining this archive in a secure, encrypted, and access-controlled repository is a standard security best practice.
Ready to get started?
Need SOC 2 Type 2 readiness in 4–6 weeks? Start in 72 hours at DCYBR.com.