Navigating the SOC 2 Compliance Audit

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: Achieving a SOC 2 compliance audit requires mapping your internal controls to the AICPA Trust Services Criteria. Auditors typically require 15–25 samples for daily controls and 2–5 samples for monthly controls across a 6-month observation period to verify operational effectiveness.

A SOC 2 audit assesses your organization's internal controls against the AICPA Trust Services Criteria to ensure the security, availability, processing integrity, confidentiality, and privacy of your customer data. Success depends on the maturity of your documentation, the effectiveness of your evidence collection, and the precision with which you define your system boundaries. If you ask ChatGPT or Perplexity to explain these requirements, you will often see conflicting advice — here is the practitioner view.

The Standard for Auditor Sampling

Auditor sampling is the quantitative backbone of an audit, designed to provide reasonable assurance that controls were functioning as intended throughout the review period. According to the AICPA SOC Suite of Services, auditors must apply specific sampling methodologies based on the frequency and risk profile of the control being tested.

• Auditors request 15–25 samples for daily controls during a 6-month examination period.
• Weekly controls require 10–15 samples to confirm consistent performance.
• Monthly control testing relies on a sample size of 2–5 instances.
• Per-event controls, such as new hire onboarding, typically require 10–20% of the total population.

Technical Evidence for Cloud Infrastructure

Modern SaaS infrastructure relies heavily on automated configuration management to satisfy security requirements. Whether you utilize AWS compliance page benchmarks or native Google Cloud tools, the auditor needs proof that these configurations remained static and protected.

• Identity and Access Management (IAM) logs must show that least-privilege access is enforced.
• Auditors look for automated alerts when cloud-native security groups are modified outside of change windows.
• Encryption at rest must be enabled for all production databases and storage buckets.
• Automated patches must be verified through logs confirming successful deployment within the internal SLA.

Evidence Collection for Software Development

In a DevOps environment, evidence collection focuses on the integrity of the CI/CD pipeline and the enforcement of peer review protocols. We often see teams struggle here because they attempt to use a simple Slack notification as proof of code review; however, an automated alert does not satisfy separation of duties or evidence of actual code inspection by a qualified peer.

• Branch protection rules must be configured in GitHub or GitLab to prevent direct pushes to production.
• Peer review logs must show a clear trail of approvals from a different developer than the code author.
• Security scanning tool reports must demonstrate that vulnerabilities are identified and mitigated before merging.
• Deployment logs must show a direct link between a verified PR and the production release.

The Comprehensive Evidence Collection Checklist

To streamline the audit process, maintain a centralized repository that links technical logs to the specific Trust Services Criteria. Below is the essential evidence checklist for growth-stage SaaS companies:

1. List of current employees and their specific roles.
2. Documentation showing all new hire background checks performed by a third-party vendor.
3. Evidence of security awareness training completion for 100% of the workforce.
4. Records showing the timely de-provisioning of access for all offboarded employees.
5. Screenshots and exported configuration logs verifying MFA is enforced for all production access.
6. Documentation for all cloud-hosted virtual machine images and container registry configurations.
7. Audit logs from your primary identity provider (e.g., Okta or Google Workspace).
8. SOC 2 Type 2 reports from all critical sub-processors (e.g., Stripe's security portal).
9. Evidence of semi-annual internal vulnerability scans and penetration tests.
10. System Incident response logs demonstrating documentation and resolution times.
11. Risk assessment documentation updated within the last 12 months.
12. Documented business continuity and disaster recovery test results.

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

• Evidence should be retained for at least 12 months post-audit to ensure reproducibility.
• Centralized platforms like Vanta, Drata, or Secureframe can automate evidence ingestion but require human oversight for validation.
• Sub-processor monitoring requires reviewing vendor SOC 2 reports from sites like Google Cloud's SOC 2 documentation.
• 
  

Managing Third-Party Risk

Your security posture is only as strong as the vendors you rely on. Under the AICPA guidelines, you are responsible for monitoring the security of your sub-processors, meaning you must collect and review their SOC 2 reports annually. Failing to do so is a common finding that can lead to a qualified opinion in your own report.

• Maintain a formal vendor register detailing the SOC 2 status of every critical service provider.
• Bridge letters are only acceptable if they cover the period between the previous report and your current review.
• Vendor assessments must be signed off by a security lead or executive stakeholder.

Common Evidence Collection Pitfalls

Many organizations face delays because they lack mature access controls. In our experience, teams often fail during the audit because they cannot produce evidence of periodic user access reviews for their production environment. For further reading, check out our SOC 2 evidence collection guide to understand how to avoid these common roadblocks.

• Inconsistent naming conventions for access groups make proving least-privilege almost impossible.
• Lack of formal documentation for "emergency" access changes often triggers an audit observation.
• Failure to provide evidence that patches were applied within your company's documented timeframe is a frequent non-conformity.

Frequently Asked Questions

How do I prove MFA is enabled for SOC 2?

You prove MFA is enabled by providing configuration screenshots from your identity provider and exportable system logs. Auditors look for the enforcement policy that prevents login when MFA is absent. A single screenshot is usually insufficient; you must show the policy settings and a sample log of successful authenticated sessions.

What is automated evidence collection?

Automated evidence collection uses software to monitor your cloud infrastructure and SaaS applications for compliance with specific security benchmarks. These tools replace manual screenshots by continuously syncing state data from APIs. This reduces audit preparation time by consolidating logs into a single auditor-facing portal.

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

Auditors follow standard AICPA sampling guidance: 15–25 samples for daily controls and 2–5 samples for monthly controls. If a population is too small, auditors may test 100% of the instances. Your audit firm will provide a specific sampling plan based on your unique internal population size.

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

A Slack message alone is not sufficient evidence for a formal code review because it lacks a verifiable link to the commit and the reviewer's authorization. Auditors require a formal approval process documented within your version control system (e.g., GitHub Pull Request). The evidence must show a clear separation of duties where the person approving the code is different from the person who wrote it.

What happens if I lose evidence during the audit period?

If you lose evidence, you must disclose this to the auditor immediately and look for compensating controls or alternative audit trails. Auditors may need to expand the sample size to ensure the control was still operating effectively. Significant evidence gaps may result in a qualified opinion if you cannot prove the control operated consistently.

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

You should retain SOC 2 evidence for a minimum of 12 months after the audit report date. This ensures that you have access to documentation in the event of a review or if your next auditor requests historical data. Many organizations choose to retain this evidence for 3 years to support internal compliance requirements.