Sixty-three percent of enterprise procurement teams now require a SOC 2 report before signing a SaaS contract. If you are a cloud service provider that has not gone through a SOC 2 audit yet, you are not just leaving deals on the table — you are actively signaling that security governance is not a priority. That is a reputational problem, not just a compliance gap.
This guide covers what SOC 2 compliance actually means, how the AICPA Trust Services Criteria map to real technical controls, what distinguishes Type 1 from Type 2, what a realistic compliance checklist looks like, and how much you should budget. No fluff. Let us get into the mechanics.
What Is SOC 2?
SOC 2 — System and Organization Controls 2 — is an auditing standard developed by the American Institute of Certified Public Accountants (AICPA). It is designed specifically for service organizations that store, process, or transmit customer data. Unlike ISO 27001, which is a prescriptive management system standard, SOC 2 is a report-based framework. You get audited against the AICPA Trust Services Criteria, and an independent CPA firm issues a report on your controls.
The framework defines five Trust Service Categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security — also called the Common Criteria — is the only mandatory category. The rest are optional add-ons you select based on what your customers care about and what your product actually does.
SOC 2 is not a certification. This trips people up constantly. There is no SOC 2 certificate on the wall. You receive an audit report — and that report either has an unqualified (clean) opinion, a qualified opinion with exceptions, or an adverse opinion. Customers and partners request the report itself, not a badge.
What SOC 2 Compliance Actually Means
Compliance means you have implemented and documented controls that satisfy the AICPA criteria, and an auditor has independently verified that. It is not enough to have a firewall. You need evidence — logs, access reviews, policy documents, vendor assessments, penetration test results — that demonstrates those controls operate effectively over time.
This is where most startups underestimate the effort. The gap between having security practices and having audit-ready evidence of effective security practices is enormous. A SOC 2 audit surfaces that gap ruthlessly. Missing access review records from three months ago? That is a finding. No documented incident response procedure? Finding. Shared admin credentials on a production database? Potentially a qualified opinion.
The practical implication: SOC 2 compliance is an ongoing operational discipline, not a one-time project. You are building a security program that produces continuous evidence, not just passing a checkpoint.
SOC 2 Type 1 vs. Type 2: What Is the Difference?
This distinction matters more than people realize when planning their compliance roadmap.
SOC 2 Type 1
A Type 1 report evaluates whether your controls are suitably designed at a single point in time. The auditor looks at your policies, configurations, and architecture on a specific date and assesses whether these controls, as designed, address the relevant Trust Services Criteria. It is a snapshot. Faster to obtain — typically two to four months from prep to report — lower cost, and useful as an intermediate milestone. But sophisticated enterprise buyers increasingly know a Type 1 is not worth much on its own. It does not tell them your controls actually work day to day.
SOC 2 Type 2
A Type 2 report covers an observation period — typically six to twelve months. The auditor tests whether your controls operated effectively throughout that period. They will sample your access logs, pull change management tickets, review incident records, and verify that your automated controls fired correctly. This is the report that enterprise procurement, security teams, and regulated-industry buyers want. It is what actually closes deals.
Most compliance-mature companies do a Type 1 first to establish a baseline, then move into a continuous Type 2 cycle. The observation period for your first Type 2 is often six months; annual renewals then cover a twelve-month window.
AICPA Trust Services Criteria: A Technical Breakdown
The AICPA publishes the Trust Services Criteria in a document formally known as TSP section 100, which maps to the COSO internal control framework. Here is what each category demands from a technical standpoint.
Security (Common Criteria)
This covers logical and physical access controls, risk assessment, change management, and incident response. The CC series includes criteria like CC6.1 through CC9.2, covering everything from logical access security software to vendor risk management. Practically, this means you need: MFA on all privileged access, role-based access control with least privilege enforced, a documented and tested incident response plan, vulnerability management processes, and network segmentation between environments.
Availability
If you are a SaaS provider with uptime SLAs, customers will want the Availability category included. You need to demonstrate capacity monitoring, backup and recovery procedures, redundancy architecture, and documented RTO and RPO targets that you have actually tested against real recovery scenarios.
Processing Integrity
Relevant if your product processes transactions or financial data. Requires controls over completeness, accuracy, and timeliness of processing. Think input validation, error handling, and reconciliation procedures that produce traceable audit trails.
Confidentiality
Covers data classified as confidential — often sensitive customer or business data. Requires encryption at rest and in transit, access controls scoped to need-to-know, and disposal procedures when data is no longer needed or a contract ends.
Privacy
Aligned with AICPA Generally Accepted Privacy Principles. If you handle personal information, customers may require this. It overlaps significantly with GDPR requirements around notice, consent, and data subject rights — but it is not a substitute for GDPR compliance.
SOC 2 Compliance Requirements: The Technical Controls That Matter
Auditors are not looking for perfect infrastructure. They are looking for evidence of a functioning control environment. The highest-frequency findings in SOC 2 audits cluster around these areas.
Identity and Access Management
Every auditor tests this hard. You need MFA enforced organization-wide — not just recommended, actually enforced through policy. Quarterly or semi-annual access reviews with documented approvals. Automated deprovisioning triggered by HR offboarding workflows. Privileged access managed through PAM tooling or through break-glass procedures with full logging. Service accounts need the same rigor as human accounts. They rarely get it, and auditors notice.
Encryption
TLS 1.2 at minimum in transit, with TLS 1.3 preferred. AES-256 at rest for sensitive data stores. Key management matters: hardcoded secrets in source code will surface during auditor walkthroughs of your development practices. Secret Detection tooling integrated into your CI/CD pipeline is table stakes for a clean report — finding leaked credentials in production code is an automatic finding.
Vulnerability Management
Documented patch SLAs tied to severity: critical findings remediated within 24 to 48 hours, high severity within 30 days, medium within 90 days. Evidence that those SLAs are actually met. Auditors will pull your vulnerability scan history and check remediation dates against ticket creation dates. Vulnerability Management processes need to be automated and traceable, not reliant on spreadsheets that someone updates manually.
Change Management
Every production change should go through a documented approval process: code reviews, deployment approvals, and emergency change procedures for urgent fixes. Auditors love pulling a random sample of production deployments and asking for the associated change ticket. Direct pushes to production without review are a finding that can tip a clean opinion into a qualified one.
Logging and Monitoring
Centralized log aggregation, log retention aligned with your policy — typically 12 months minimum — alerting on security-relevant events, and evidence of alert review. If you have a SIEM, auditors will want to see your alert history. If you do not, structured logging to an immutable store with documented review processes is the minimum bar.
Incident Response
A documented IR plan is not enough. Evidence of tabletop exercises, post-incident reviews, and actual incident handling records is what auditors want to see. If you have genuinely never had a security incident to document, that is acceptable — but you need evidence of a tested, current plan and scheduled exercises.
SOC 2 Compliance Checklist: Where to Start
A practical pre-audit readiness checklist spans multiple parallel workstreams. These are the ones you need to open simultaneously.
- Scope definition: Which systems are in scope? Which Trust Service Categories are you pursuing? Document this formally. Scope creep during an active audit is painful and expensive.
- Policy library: Information security policy, access control policy, acceptable use policy, incident response plan, business continuity and disaster recovery plan, vendor management policy, data classification policy. All must exist, be approved by leadership, and be current within the last 12 months.
- Control mapping: Map your existing technical controls to specific Common Criteria criteria. Identify gaps. This becomes your remediation roadmap and sets your timeline to audit readiness.
- Evidence collection infrastructure: Set up automated evidence collection — audit logs exported to immutable storage, access review workflows in your ITSM or identity platform, vulnerability scan outputs retained and tied to remediation tickets.
- Vendor assessments: CC9.2 requires third-party risk management. Document your critical vendors, their security postures, your review process, and how you handle vendor risk exceptions.
- Penetration testing: Most enterprise customers expect to see annual penetration test results included in or alongside your SOC 2 report. Schedule this well before your audit window closes.
- Readiness assessment: Engage your auditor or a separate advisory firm for a gap assessment before the formal audit begins. Surprises during the actual audit are expensive to remediate mid-fieldwork.
Keeping your cloud posture continuously assessed matters enormously here. CSPM capabilities give you real-time visibility into misconfigurations that could become SOC 2 findings — public storage buckets, over-permissive IAM roles, unencrypted volumes. Catching these before your auditor does is obviously preferable to explaining them during fieldwork.
SOC 2 Compliance Cost: What to Actually Budget
Costs vary significantly based on organization size, scope, and existing security maturity. Here is a realistic breakdown for a mid-size SaaS company — 50 to 200 employees — pursuing SOC 2 Type 2 with Security and Availability categories.
Audit Fees
A Type 1 audit from a reputable CPA firm runs $15,000 to $30,000. A Type 2 audit: $30,000 to $60,000, sometimes higher for complex multi-cloud environments. Big-four firms charge premium rates. Mid-tier firms with deep technology sector experience often deliver equivalent quality at lower cost and with faster turnaround.
Compliance Automation Platforms
Platforms like Vanta, Drata, and Secureframe run $20,000 to $50,000 per year depending on employee count and integrations. ROI is generally positive given the alternative: a full-time compliance engineer doing manual evidence collection, which scales poorly and introduces human error into your evidence chain.
Remediation Work
This is the hardest to estimate and the most commonly underestimated line item. Engineering hours to implement missing controls — MFA rollouts, SIEM deployment, access review workflows, secrets management infrastructure — can easily run 500 to 1,000 engineering hours at a growing company. At $150 to $200 per hour blended rate, that is $75,000 to $200,000 in engineering cost before you have paid an auditor a dollar.
Penetration Testing
$15,000 to $40,000 for a thorough web application plus infrastructure penetration test from a credible firm with proper scoping and remediation verification.
Total first-year cost for a mid-size company pursuing SOC 2 Type 2: realistically $100,000 to $300,000 all in, heavily dependent on starting security maturity. Year two and beyond drops significantly once controls are operational and evidence collection is automated.
Automating SOC 2 Controls With Modern Security Tooling
The most efficient path to SOC 2 readiness in 2026 involves automating controls at the source rather than bolting on compliance tooling after the fact. Policy-as-Code is particularly powerful here — encoding your SOC 2 controls as machine-enforceable policies means drift from compliant state triggers automated alerts rather than being discovered during annual audits or quarterly access reviews.
Container workloads need specific attention in the SOC 2 context. Container Image Scanning integrated into your CI/CD pipeline catches vulnerable base images and misconfigurations before they reach production — directly addressing CC7 system operations and change management criteria. When your auditor asks how you validate security posture before deployment, a CI/CD-integrated scanning pipeline is a concrete, evidence-backed answer.
Similarly, SAST tooling running in your development workflow supports the argument that your change management process includes systematic security validation of code changes, not just manual code review by developers who may not have security expertise.
The Compliance solutions available on modern security platforms can map detected findings directly to SOC 2 criteria, producing the kind of traceable evidence trail auditors actually want to see. That is a fundamentally different value proposition than point-in-time scanning that produces a report nobody acts on.
Common SOC 2 Audit Failures and How to Avoid Them
Patterns emerge consistently in what causes qualified opinions across SOC 2 engagements. The top failure modes are: incomplete access reviews — doing them once and not maintaining the quarterly cadence; exception-heavy change management where too many changes bypass the review process as emergency fixes; missing vendor assessments for critical third-party processors; and log retention gaps where log data was purged before the audit observation period ended. Each of these is fixable with process discipline and tooling. None require rearchitecting your infrastructure.
The subtler failure mode is scope gaming — attempting to carve out problematic systems from scope to avoid uncomfortable findings. Experienced auditors identify when scope definitions do not reflect operational reality. If your billing system touches in-scope customer data, it is likely in scope whether or not you labeled it that way in your scoping document. Be honest with your auditor about system boundaries from day one of the engagement.
SOC 2 and Your Broader Security Program
SOC 2 compliance, done well, does not exist in isolation. The controls it demands — access management, vulnerability management, change control, incident response — are exactly the controls that make your infrastructure genuinely defensible against real threats. A well-implemented SOC 2 program makes you materially harder to breach. IBM Cost of a Data Breach Report 2026 put the average breach cost at $4.88 million. The cost of SOC 2 readiness looks very different against that benchmark.
If you are building on cloud infrastructure and managing a distributed attack surface across multiple providers and regions, treating Cloud Security as a continuous discipline rather than an audit event is the right mental model. SOC 2 gives you the external pressure and the structured framework to formalize what should already be operational practice — continuous monitoring, automated evidence collection, and security controls that run without human intervention.
The companies that struggle with SOC 2 are the ones treating it as a compliance exercise disconnected from their actual security posture. The ones that sail through audits are the ones who built a real security program and let SOC 2 serve as the validation layer on top of it.