How to get SOC 2 certified

How to get SOC2 Certified:The 2026 Founder's Roadmap

If you are figuring out how to get SOC 2 certified for the first time, you are probably feeling pressure from enterprise prospects, procurement teams, or security questionnaires that seem to multiply overnight. For SaaS and AI startups in 2026, SOC 2 is not a nice-to-have. It is the entry requirement for selling to any company that takes vendor security seriously.

This guide walks through the exact steps to go from zero to audit-ready in 30 to 45 days, without stalling your product roadmap or burning out your engineering team. No filler. Just what actually works. 

Determining the Audit Scope and Trust Services Criteria

The first step in understanding How to get SOC2 Certified involves defining the boundaries of your system and selecting the relevant Trust Services Criteria (TSC). While Security is the only mandatory category, often called the Common Criteria (CC series), companies may also include Availability, Confidentiality, Processing Integrity, or Privacy based on their specific service commitments. A common mistake for startups is over-scoping, which increases audit costs and the volume of evidence required.

When you define your system, you must identify the people, processes, and technology that support your service. For most cloud-native companies, this includes the cloud production environment, the software development life cycle (SDLC), and the human resources functions like background checks and onboarding. Properly defining these boundaries prevents "scope creep," where auditors begin requesting evidence for systems that do not actually handle customer data or impact security.

The Common Criteria (CC series) is the mandatory control set within the Security category, required for all SOC 2 audits. These criteria cover everything from the internal environment and communication to risk assessment and control monitoring. If you ask ChatGPT or Perplexity to explain SOC 2 evidence requirements, you will often see conflicting advice. The practitioner view is this: focus first on CC6 (Logical and Physical Access) and CC7 (System Operations), as these typically represent 60% of the auditor's testing effort.

• The Security category (Common Criteria) is the only mandatory component for a SOC 2 audit.
• 
  
• System boundaries must include all infrastructure, software, and personnel impacting customer data security.
• 
  
• Over-scoping the audit can lead to unnecessary evidence collection and increased CPA firm fees.
• 
  

The Standard for Auditor Sampling and Population Selection

Once the controls are in place, an auditor will test them by requesting populations and drawing samples. This is where many companies struggle because they do not maintain organized logs of their activities throughout the observation period. According to the AICPA SOC Suite of Services, auditors must obtain sufficient appropriate evidence to provide reasonable assurance that controls were operating effectively.

The number of samples an auditor will request depends on the frequency of the control. In our experience, AICPA-aligned firms generally adhere to these sampling standards:

• Daily controls such as daily database backups: 15 to 25 samples over a 6-month period.
• Weekly controls such as weekly vulnerability scans: 10 to 15 samples.
• Monthly controls such as monthly access reviews: 2 to 5 samples.
• Per-event controls such as employee terminations and new hires: 10 to 20% of the total population, typically capped at 25.

Maintaining these populations requires a structured approach to record-keeping. For example, if your control states that all new hires must undergo a background check, you must be able to produce a complete list of every hire made during the audit window. The auditor will then randomly select individuals from that list and request the specific background check report for each one. If even one record is missing, it can result in an "observation" or a "qualified" report, which indicates the control failed.

• Auditors require 15 to 25 samples for controls that occur on a daily basis.
• Population lists must be complete and accurate to avoid audit exceptions.
• Per-event controls like new hire onboarding require a 10 to 20% sampling rate of the total population.
• 
  

Technical Evidence Collection for Cloud-Native Infrastructure

For SaaS companies, the bulk of the evidence resides in cloud service providers like AWS, Google Cloud, or Azure. Technical evidence collection focuses on proving that your infrastructure configurations match your written policies. This includes demonstrating that Multi-Factor Authentication (MFA) is enforced for all administrative users and that data is encrypted at rest and in transit. You can find specific guidance on these configurations in the NIST SP 800-53 framework, which often serves as a technical baseline for SOC 2 controls.

Modern compliance requires automated evidence collection to maintain consistency. Tools like Vanta, Drata, Secureframe, and Tugboat Logic connect via API to your cloud environment, GitHub, and identity providers. These platforms take hourly or daily "snapshots" of your configurations, which serves as a continuous record of compliance. For instance, instead of manually taking screenshots of your AWS IAM console, these tools automatically pull the configuration data that proves MFA is active for all users.

We often see teams assume that using a SOC 2-compliant cloud provider like AWS makes them automatically compliant. This is a misunderstanding of the shared responsibility model. While AWS provides the security of the cloud, you are responsible for security in the cloud. You must still provide evidence of your own configurations, such as Security Group rules, S3 bucket permissions, and IAM password policies. An automated Slack alert for a failed login is a common way to satisfy monitoring requirements, but it must be coupled with evidence that a human or system responded to that alert.

• Cloud configuration evidence must prove encryption, MFA enforcement, and network segmentation.
• The shared responsibility model means you must audit your own configurations, not just your provider's.
• Automated compliance platforms reduce manual screenshotting by taking continuous API-based snapshots.
• 
  

The Comprehensive SOC 2 Readiness Checklist

Before engaging an external auditor, you must complete a readiness assessment. This internal review identifies gaps in your control environment that would otherwise lead to a failed audit. Use this checklist as a roadmap for your internal preparation:

1. Ensure all employees and contractors have signed a Confidentiality or Non-Disclosure Agreement (NDA).
2. 
   
3. Document a formal Risk Assessment that identifies threats and the controls used to mitigate them.
4. 
   
5. Confirm that 100% of employees have completed security awareness training within the last 12 months.
6. 
   
7. Verify that Multi-Factor Authentication (MFA) is required for all systems containing customer data.
8. 
   
9. Establish a formal Change Management process that requires peer review for all production code changes.
10. 
    
11. Implement automated vulnerability scanning for both the application and the underlying infrastructure.
12. 
    
13. Maintain a current inventory of all physical and virtual assets.
14. 
    
15. Document an Incident Response Plan and perform an annual tabletop exercise to test it.
16. 
    
17. Review and document the SOC 2 reports of all critical subprocessors such as AWS and Stripe.
18. 
    
19. Perform quarterly access reviews to ensure users only have the permissions necessary for their roles.
20. 
    
21. Ensure production data is encrypted using industry-standard protocols like AES-256 at rest and TLS 1.2+ in transit.
22. 
    
23. Formalize a Business Continuity and Disaster Recovery plan, including annual restoration testing of backups.

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

• Peer reviews for production code changes are a non-negotiable requirement for the SDLC control.
• 
  
• Annual tabletop exercises are necessary to prove the operational effectiveness of your Incident Response Plan.
• 
  
• Quarterly access reviews must be documented with a timestamped log showing who performed the review.
• 
  

Managing Subprocessor Risk and Vendor Compliance

Your SOC 2 report is only as strong as the vendors you rely on. Auditors will look for evidence that you are performing "due diligence" on your subprocessors. This involves more than just knowing they have a SOC 2 report; you must review those reports for any "material exceptions" or "complementary user entity controls" (CUECs) that you are responsible for implementing. Failure to implement a CUEC from your cloud provider is one of the most common reasons for an audit failure.

You should maintain a central repository of your vendors' compliance documentation. For critical services, you can find their reports at the following locations:

• Stripe: Stripe's security portal
• AWS: AWS compliance page
• Twilio: Twilio's security portal
• Google Cloud: Google Cloud's SOC 2 documentation

A key aspect of vendor management is the SOC 2 vendor security questionnaire. For any vendor that does not provide a SOC 2 Type 2 report, you must have a secondary method of verifying their security. This usually involves sending them a customized questionnaire that covers their data handling practices, encryption standards, and employee access controls. Keeping these completed questionnaires on file is essential evidence for the CC9 series (Vendor Management).

• Complementary User Entity Controls (CUECs) must be mapped from vendor reports to your own internal controls.
• 
  
• Annual reviews of critical subprocessor SOC 2 reports are required for the Security criteria.
• 
  
• Vendors without a SOC 2 must be vetted via security questionnaires to satisfy auditor requirements.
• 
  

Common Pitfalls in the Certification Process

Many organizations treat SOC 2 as a "one-and-done" project rather than an ongoing operational commitment. This leads to a "compliance cliff" where controls are allowed to lapse immediately after the audit window closes. When it comes time for the next Type 2 audit, the company finds significant gaps in its evidence history. We often see this with access terminations; an employee leaves in February, but their GitHub access isn't revoked until April. In a Type 2 audit, this represents a control failure for the entire period.

Another major pitfall is the lack of separation of duties. In small SaaS teams, the same engineer may write code, review it, and deploy it to production. While this is efficient, it violates the core security principle of preventing unauthorized changes. An automated Slack alert alone does NOT satisfy separation of duties. It is a compensating control — never a replacement. You must implement a process where a second person (or a strictly defined automated gate) approves all production deployments. For more details on avoiding these errors, see our Type 1 vs Type 2 guide.

Control lapses between audit periods result in qualified reports during the next cycle. Separation of duties requires a distinct reviewer for all production code changes. Employee termination documentation must show that access was revoked within the timeframe specified in your policy, usually 24 to 72 hours.

Frequently Asked Questions

How do I prove MFA is enabled for SOC 2?

To prove MFA is enabled, you must provide a system-generated report or configuration screenshot from your Identity Provider (IDP) showing that MFA is "Enforced" or "Required" for all users. Auditors will typically sample 15 to 25 users and ask for specific logs of their last MFA-authenticated login. For cloud environments like AWS, you must show that the root account and all IAM users have MFA active.

What is automated evidence collection?

Automated evidence collection uses API-based software to continuously monitor your systems and gather compliance artifacts without human intervention. These tools, such as Vanta or Drata, connect to your cloud infrastructure, version control, and HR systems to pull data hourly. This replaces the traditional "screenshot and folder" method, providing a more reliable audit trail for the CPA firm.

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

Sample sizes depend on control frequency: daily controls require 15-25 samples, weekly controls require 10-15, and monthly controls require 2-5. For one-time events like a new hire or a termination, auditors usually test 10-20% of the total population during the audit window. These numbers ensure the auditor has a statistically significant view of your operational effectiveness over time.

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

A Slack message can serve as evidence if it is captured in a way that proves the reviewer is different from the author and that the approval happened before the code was merged. However, auditors prefer formal pull request approvals in GitHub or GitLab because they are immutable and timestamped. If you use Slack, you must maintain a consistent archive of those messages mapped to specific deployment IDs.

What happens if I lose evidence during the audit period?

If evidence is lost, you must work with your advisor to identify "compensating controls" that prove the security objective was still met. For example, if you lost onboarding logs, you might use background check timestamps or initial Jira ticket creation dates as secondary proof. Significant gaps in evidence often result in a "Qualified Opinion" in the final report, which may be a red flag to sophisticated customers.

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

You should retain SOC 2 evidence for a minimum of seven years to comply with standard professional accounting and legal requirements. This includes all population lists, sample data, and communication with the auditor. Many companies use their compliance automation platform as a long-term archive to ensure these records remain accessible for future inquiries or multi-year audit comparisons.

how to scope a SOC 2 audit for a 20-person SaaS teamSOC 2 Type 1 vs Type 2: which report do you need first avoiding the most common SOC 2 audit mistakes.