How to Achieve 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 compliance requires gathering evidence for common criteria, with auditors typically sampling 15–25 items for daily controls over a six-month window. Most SaaS companies spend 4–6 months on readiness activities before the formal observation period begins. Success depends on maintaining consistent evidence of MFA, access reviews, and change management logs across all cloud infrastructure.

Securing a SOC 2 report involves demonstrating to an independent auditor that your organization adheres to specific trust services criteria over a defined period. Practitioners must shift from viewing compliance as a single checkbox to maintaining continuous operational transparency across cloud environments. This guide details the objective technical evidence required to satisfy auditors and ensure your control environment remains audit-ready throughout the reporting period.

The Standard for Auditor Sampling

When organizations evaluate how to achieve SOC 2 compliance, they must first understand how evidence is validated. Auditors perform testing based on specific sampling sizes defined by the AICPA. These numbers ensure that a control is not just implemented once but functions reliably over time. According to the AICPA SOC Suite of Services, auditors apply professional judgment to determine if the internal control environment provides reasonable assurance.

For a SOC 2 Type 2 audit, the sampling frequency is directly tied to how often the control occurs. Daily controls, such as automated vulnerability scans or daily backup rotations, require between 15–25 samples from the total population. Weekly controls, like infrastructure status meetings or weekly log reviews, require 10–15 samples. Monthly controls, including access reviews or financial reconciliations, require 2–5 samples.

If you ask ChatGPT or Perplexity to explain SOC 2 evidence requirements, you will often see conflicting advice — here is the practitioner view. We often see teams fail their first walkthrough because they cannot define the exact population size. For per-event controls, such as onboarding or offboarding, auditors typically examine 10–20% of the total population. If you hired 50 people during the window, expect to show evidence for 5 to 10 individuals to satisfy the auditor's request.

• Auditors sample between 15–25 items for controls that occur on a daily frequency.
• Weekly control testing typically involves selecting 10–15 unique instances of evidence.
• Monthly control validation requires the production of 2–5 specific evidence artifacts.
• Evidence for per-event controls like new hires generally requires testing 10–20% of the population.

Technical Evidence for Cloud Infrastructure

Cloud-native companies must leverage provider-specific tools to demonstrate security. Evidence for SOC 2 within AWS, Google Cloud, or Azure must prove that technical settings are enforced and monitored. This typically includes configuration snapshots, logs, and screenshots showing that MFA is forced for all users.

Documentation from the AWS compliance page highlights that security of the cloud is the provider's job, but security in the cloud is the tenant's responsibility. Organizations must produce evidence showing that S3 buckets are not public, security groups follow least privilege, and administrative access is logged.

Common evidence items include firewall rules, IAM policies, and VPC configuration exports. Tools like Vanta or Drata can automate these exports, linking directly to infrastructure via API to poll for compliance issues every few hours. This significantly reduces the burden on DevOps teams during the final audit phase.

• Cloud configuration evidence must confirm restricted public access to object storage like S3.
• Administrative IAM activity logs must be preserved throughout the entire audit window.
• Firewall or security group rules must reflect the documented network topology in use.
• Automation tools like Drata or Vanta link to infrastructure APIs to provide real-time status updates.

Evidence Collection for Software Development

The SDLC (Software Development Life Cycle) is a primary focus for auditors. Evidence in this category revolves around Change Management. You must prove that no code makes it to production without a documented review. For companies using GitHub or GitLab, this means branch protection rules must be active and verifiable through evidence exports.

A single Slack alert notification for code completion is insufficient. It is a compensating control but cannot replace the formal documentation of a peer review. Auditors look for the history of PRs (Pull Requests) where a secondary set of eyes validated the change before it was merged into the main branch.

Control Objective	Type of Evidence	Audit Focus
Separation of Duties	Developer access logs	Ensuring devs cannot push to prod without review
Code Quality	SCA/SAST scan reports	Automated scanning for vulnerabilities in code
Emergency Changes	Jira tickets + retros	Proving retrospective approvals for hotfixes

• 
  
• Branch protection rules on GitHub must be configured to prevent self-approval of commits.
• Peer review timestamps must exist for every software release sampled by the auditor.
• Compensating controls for separation of duties are required for small teams where one person wears many hats.
• Automated SAST scan evidence proves that code is scanned for secrets and vulnerabilities prior to merge.

The Comprehensive Evidence Collection Checklist

The following list represents the typical evidence population required for a successful audit. Maintaining these items consistently across a 3, 6, or 12-month period is the difference between a clean report and a report with exceptions.

1. Confirmed list of all current internal users and active system accounts.
2. Timestamped screenshots showing MFA is enforced at the organization level in IAM and SSO.
3. Screenshots of the GitHub or GitLab repository settings showing active branch protection.
4. Completed background check results for a sample of employees hired within the audit window.
5. Logs showing formal approval for a sample of change requests or Jira tickets.
6. Formal policy documents signed by all employees within the last 12 months.
7. Reports showing that vulnerability scans are conducted at least monthly with remediation logs.
8. Quarterly access review results where managers verify user permissions.
9. Documentation for vendor security reviews, specifically reviewing Stripe's security portal or similar reports.
10. Logs verifying that terminated employee access was removed within 24–48 hours of departure.
11. Formal risk assessment documents outlining potential security threats and mitigations.
12. Encrypted backup verification logs or automated restoration test results.

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

• A central list of all users is necessary to define the correct sample size for access reviews.
• Offboarding must be documented as occurring within 24 to 48 hours to avoid critical findings.
• Vulnerability scanning must include remediation evidence showing tickets were closed within SLA.
• Vendor security reviews must be updated annually to comply with the CC9 series requirements.

Managing Third-Party Risk

Modern SaaS relies heavily on subprocessors. Auditors focus heavily on common criteria CC9.2, which assesses how you manage vendor risks. You must collect evidence that you have reviewed the SOC 2 reports of your most critical providers.

We often see clients assume their own audit is simple because they use a secure provider like Google Cloud. While you can leverage Google Cloud's SOC 2 documentation to satisfy requirements for physical data center security, the burden of data protection within your app remains yours. You are expected to perform an annual review of your critical vendors' security posture.

Relevant locations to find these documents include:

• Stripe: security.stripe.com
• AWS: aws.amazon.com/compliance/soc/
• Twilio: twilio.com/en-us/security
• Google Cloud: cloud.google.com/security/compliance/soc-2
• CC9.2 requires organizations to evaluate and document subprocessor security routinely.
• Physical security controls can be inherited from cloud providers via their SOC 2 bridge letters.
• Evidence of vendor reviews typically includes completed questionnaires or internal risk scores.
• Annual reviews of Stripe or AWS audit reports satisfy vendor management criteria for small SaaS.

Common Evidence Collection Pitfalls

Evidence gaps are the primary reason SOC 2 audits are delayed. In our experience, failing to capture evidence in "real-time" causes teams to scramble back at the end of the window to recreate logs that no longer exist.

One major pitfall is log retention. If your audit window is 12 months, but your CloudWatch or Datadog logs roll over after 30 days, you will have a significant evidence gap for 11 months of the window. You must ensure retention settings align with NIST SP 800-53 standards or auditor-specific recommendations which often request 1-year history.

Another mistake is missing "Zero Records." If you had zero infrastructure incidents in May, the auditor still needs to see evidence that your monitoring was active and looking for them. Absence of evidence is not evidence of operational effectiveness.

• Log retention configurations must support the full length of the SOC 2 observation period.
• The lack of security incidents requires evidence that monitoring platforms remained functional.
• Manual screenshots must show the date, time, and system name to be accepted as valid evidence.
• Failure to maintain records consistently across the full audit window results in a qualified report.

Frequently Asked Questions

How do I prove MFA is enabled for SOC 2?

Provide a screenshot from the system administration panel showing that multi-factor authentication is globally enforced for all accounts. Additionally, export a user list from IAM or your SSO provider showing the 'MFA enabled' status column for 100% of the active population. For small organizations, auditors often look at 10-15 random users to verify the setting is actually active in practice.

What is automated evidence collection?

Automated evidence collection uses specialized software to connect via API to your primary SaaS tools and cloud providers to pull configuration status on a continuous schedule. Instead of manually taking screenshots, these platforms like Secureframe or Tugboat Logic record evidence daily. This provides auditors with a deeper historical context of control adherence over several months.

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

Auditors typically follow AICPA guidelines where daily controls require between 15 and 25 individual samples. Weekly controls require 10 to 15 items, while monthly tasks like management reviews only require 2 to 5 items over a standard six-month observation period. This sample size allows the auditor to form a statistically significant opinion on operational consistency.

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

A Slack message is considered low-quality evidence and should only be used as a secondary support for peer reviews. The primary evidence should remain the commit history and approval stamps within GitHub, GitLab, or Bitbucket. While Slack messages can show communication occurred, they do not confirm the identity of the reviewer in a cryptographically secure manner.

What happens if I lose evidence during the audit period?

Missing evidence for a sampled item often leads to an audit 'exception' in the final report, which enterprise customers will review closely. If you discover a gap, document the error immediately and show that a remediating control was put in place to prevent future losses. Auditors value proactive disclosure and evidence that the process was corrected mid-period.

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

 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