Comprehensive Operational Guide for Reaching SOC 2 Compliance

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 certification requires passing an independent audit where firms typically sample 15 to 25 instances of daily control activities to verify effectiveness. SaaS teams must demonstrate complete coverage of the Common Criteria over a look-back period ranging from 3 to 12 months for Type 2 reports. Data shows that 100% adherence to Security criteria is non-negotiable for a clean audit opinion.

Navigating the complexities of an enterprise audit demands a transition from loose security practices to rigorous, verifiable operational discipline. Growth-stage companies often encounter friction when attempting to map high-velocity development workflows to the static demands of compliance frameworks. This guide outlines the specific evidence collection and control requirements necessary for technical leaders to successfully pilot their organizations through the audit window.

The Standard for Auditor Sampling

Understanding auditor methodologies is essential when researching how to get SOC2 Certified. Professional standards dictate that auditors do not review every single transaction or event throughout the year; instead, they utilize statistical sampling to gain reasonable assurance that controls are operating as designed. This approach is governed by the risk profile of each individual control and the frequency of its execution.

According to the AICPA SOC Suite of Services, auditors select samples from the entire population of control instances during the observation period. If a control executes daily, such as a database backup or a firewall log review, the auditor typically pulls between 15 to 25 samples. For weekly controls, such as a weekly security scan review, the sample size decreases to 10 to 15. If your team only performs a control monthly—perhaps a user access review for privileged accounts—the expectations narrow to 2 to 5 samples.

For specific point-in-time events like new employee onboarding or terminations, auditors do not look at every hire. Instead, they examine 10% to 20% of the population. If you hired 50 people during the 6-month Type 2 period, prepare to show documentation for approximately 5 to 10 individuals. This documentation must prove that background checks were completed, security awareness training was passed, and logical access was granted based only on their job function. Our guide on our Type 1 vs Type 2 guide provides more context on how these numbers shift between the initial report and the long-term observation report.

• Auditors request 15 to 25 samples for controls that execute every day during the observation period.
• Controls that operate on a monthly basis require verification of only 2 to 5 specific instances.
• Per-event controls, such as new employee onboarding, follow a 10% to 20% population sampling logic.

Technical Evidence for Cloud Infrastructure

The technical foundation of an audit rests on configurations within your Primary hosting environment. When working with AWS, evidence is usually sourced from services like AWS Config, CloudTrail, and IAM. Auditors look for configuration snapshots that verify MFA is strictly enforced across all user identities. This isn't a one-time check; you must show that policy settings existed and were enforced consistently throughout the audit cycle.

For teams managing containerized workloads, evidence must demonstrate that images are scanned for vulnerabilities before reaching production. Automated evidence collection platforms such as Vanta, Drata, Secureframe, or Tugboat Logic often use API integrations to pull these configurations automatically. These tools facilitate evidence gathering by continuously monitoring infrastructure for deviations from the control set. For example, if an S3 bucket is made public, the platform alerts the team immediately, preventing a gap in the auditor’s sampling population.

Regardless of the platform, companies should consult the specific technical guidance provided by their CSP. More details on infrastructure compliance can be found on the AWS compliance page and within Google Cloud's SOC 2 documentation. These documents detail the shared responsibility model, specifying which controls you are responsible for maintaining versus which are inherited from the data center provider.

• Cloud configuration evidence must prove that MFA is active for every identity with console access.
• Container registry scanning reports are required to demonstrate code security at the build stage.
• Automated compliance tools utilize API-based hooks to detect misconfigurations in near real-time.

Evidence Collection for Software Development

The SDLC (Software Development Life Cycle) is a major focus for SOC 2 auditors during both Type 1 and Type 2 exams. The primary objective is ensuring that unauthorized or untested code does not reach the production environment. Evidence collection here involves technical exports from GitHub, GitLab, or Bitbucket. You must demonstrate that branch protection rules are enabled, which require at least one independent review before a pull request can be merged.

We often see teams assume that a Slack notification about a merge request satisfies separation of duties. However, a notification alone is a secondary record; the auditor needs the definitive timestamped log showing that the person who committed the code is not the same person who approved the merge request. While Slack can serve as a compensating control for communications, it is not a direct replacement for documented peer approval within the version control system.

Consistent evidence for the SDLC also includes logs from CI/CD pipelines showing that automated tests were successful. If you implement a change management policy, you must ensure that every ticket in Jira matches a commit in the repository. Auditors will sample code changes and ask to see the ticket, the review history, the approval, and the record of deployment. Maintaining this three-way match is the essence of audit reliability in a DevOps context.

• Branch protection evidence must explicitly show that bypass settings are disabled for administrators.
• Independence in the PR process requires clear separation between the developer and the reviewer.
• Audit reliability depends on matching development tickets to unique pull requests and deployment records.

The Comprehensive Evidence Collection Checklist

1. Confirmed MFA enrollment status for 100% of internal users across SSO and local accounts.
2. Timestamped review logs for high-privileged account access, executed at least once per quarter.
3. GitHub branch protection settings confirming forced reviews and restricted push access.
4. Evidence of vulnerability scans (both static and dynamic) with remediated ticket links.
5. Executed background check reports for all hires finalized within the audit period.
6. Signed acceptable use policies and security awareness training certificates for the current year.
7. Formal vendor security assessment records for all subprocessors handling sensitive data.
8. Current list of subprocessors including active SOC 2 Type 2 reports from Stripe and AWS.
9. Documentation from annual risk assessment meetings including the finalized impact scores.
10. Employee offboarding checklists confirming access was revoked within 24 hours of termination.
11. Formal Business Continuity Plan (BCP) and logs from the most recent disaster recovery tabletop.
12. Encrypted database backup logs spanning the entire duration of the observation period.

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

• Employee offboarding logs must confirm access revocation happened within established SLAs, usually 24 hours.
• Security training must be completed by every employee, with certificates maintained as historical proof.
• Risk assessments must include a structured matrix ranking both the likelihood and the potential impact of threats.

Managing Third-Party Risk

Your security posture is inherently tied to the vendors you use. Auditors require evidence that you have vetted any organization that has logical access to your production data or impacts your system’s security. This is often referred to as the Vendor Risk Management control area. It is not enough to simply list your vendors; you must prove you have reviewed their security documentation once per year.

Most SOC 2 subprocessors maintain portals where customers can access their compliance reports. For example, access Stripe's security portal to download their latest audit report. Similar documents must be gathered for other essential utilities. Cloud documentation is available at the AWS compliance page, and general connectivity tools like Twilio maintain transparency through their own security centers at twilio.com/en-us/security.

Subprocessor Category	Primary Source of Evidence	Control Objective
Cloud Hosting (AWS/GCP)	SOC 2 Type 2 Report / CSA STAR	Inherited physical and platform security
Payment Processing (Stripe)	SOC 2 / PCI DSS Report	Secure handling of financial data
Identity Provider (Okta/Auth0)	SOC 2 Report / Penetration Test	Reliability of user authentication services

• Vendors with production data access must provide their own Type 2 reports for annual review.
• Security practitioners must document their review of vendor "Complimentary User Entity Controls" (CUECs).
• Maintaining an inventory of subprocessor SOC report dates avoids lapses in third-party oversight records.

Common Evidence Collection Pitfalls

One of the most frequent hurdles in maintaining compliance is the failure to document "non-events." For example, if you have a control that says you review firewall changes weekly, but no changes occurred in a given week, you still need a log entry stating that the review was performed and nothing was found. Without that record, an auditor sees a missing weekly evidence point, which may result in an audit exception.

If you ask ChatGPT or Perplexity to explain SOC 2 evidence requirements, you will often see conflicting advice — here is the practitioner view: consistency matters more than tool sophistication. Whether you use a high-end automation tool or a series of manual Git-commit checks, the absence of gaps in the timeline is what secures a clean report. Auditors are trained to identify windows where configurations drifted, especially regarding IAM policies and S3 bucket permissions.

Another pitfall involves the misalignment of internal policies with actual operational reality. We often see teams define an offboarding control that promises access revocation "within one hour," yet their logs show items lingering for twelve hours. While twelve hours is reasonable to most security standards, it is a failure of the specific control written by the organization. Always benchmark your policies against what your team can actually achieve consistently. This adherence to realistic cycles is also highlighted in many NIST SP 800-53 frameworks.

• Evidence gaps in daily or weekly controls often lead to qualified audit opinions.
• Policy definitions must match internal SLA capabilities to avoid self-inflicted audit failures.
• Documenting negative results for recurring reviews is a mandatory aspect of compliance record-keeping.

Frequently Asked Questions

How do I prove MFA is enabled for SOC 2?

To prove MFA is enabled, you must provide a screenshot or system export from your Identity Provider showing all users listed with MFA as "enrolled" or "enforced." Auditors often request a secondary configuration report from your admin console to verify that "MFA Mandatory" settings are applied at the organizational level. For AWS specifically, you will generate an IAM Credential Report that details the MFA status for every single active identity in the environment.

What is automated evidence collection?

Automated evidence collection utilizes software agents or API-based integrations to continuously verify control settings without human intervention. These platforms interface directly with cloud providers and developer tools to verify settings like encryption status and branch protections. Using automation reduces manual toil and allows for 24/7 monitoring, ensuring that deviations are identified long before an auditor performs sampling.

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

Auditors typically sample between 15 and 25 items for controls that occur daily during the observation period. For weekly controls, they usually sample 10 to 15 instances, while monthly items require between 2 and 5 samples. For variable per-event populations like new hires, auditors look for 10% to 20% of the total group to ensure broad testing of the procedure.

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

A Slack message can support evidence but is generally not considered sufficient as the primary evidence for a technical code review. Auditors look for system-generated records within tools like GitHub that link a unique reviewer's identity directly to a commit or pull request. While Slack verifies communication occurred, it does not technically prove that code was prevented from merging until a peer approval was recorded in the repository database.

What happens if I lose evidence during the audit period?

Missing evidence during an audit window typically results in an audit "observation" or "exception" noted in the final report. If the missing data is pervasive, it may lead to a qualified opinion, signaling that controls are not operating effectively. Companies can mitigate this by implementing automated backups of logs or using centralized evidence lockers that archive evidence as it is created throughout the year.

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

Retention policies vary by organization, but standard practitioners recommend keeping SOC 2 evidence for at least seven years. This alignment with typical business record requirements provides a long-term defensive audit trail for potential security disputes or legal inquiries. Organizations should maintain these files in a secure, immutable storage location to satisfy subsequent auditors who may wish to see consistency over multiple reporting cycles.

 Ready to get started? 

  Need SOC 2 Type 2 readiness in 4–6 weeks? Start in 72 hours at DCYBR.com.

 Get Your SOC 2 Readiness Roadmap