What Is SOC 2 Compliance? The Definitive Guide for SaaS Companies & Tech Leaders (2026)

Compliance · March 2026

Everything you actually need to know about SOC 2 compliance - the Trust Service Criteria, audit types, real-world costs, timelines, and the mistakes that sink most first-time attempts. Written by practitioners, not marketers.

Key Takeaways

• SOC 2 is a voluntary audit framework developed by the AICPA that evaluates how your organization protects customer data across 5 Trust Service Criteria
• Type 1 is a snapshot ("controls exist"); Type 2 is an observation period ("controls actually work over time") - enterprise buyers almost always require Type 2
• Realistic costs range from $30,000 to $200,000+ depending on company size, complexity, and starting maturity
• The typical timeline from zero to Type 2 report is 9-14 months, but readiness work can compress this significantly
• Security (CC criteria) is mandatory; the other four criteria are chosen based on your business model and customer commitments

Table of Contents

SOC 2 stands for System and Organization Controls 2. It's an auditing framework developed by the American Institute of Certified Public Accountants (AICPA) that evaluates how well a service organization protects customer data. The "2" distinguishes it from SOC 1, which focuses on financial reporting controls - SOC 2 is specifically about information security.

Here's what trips most people up: SOC 2 is not a certification. You don't "pass" or "fail" SOC 2 the way you pass a driving test. Instead, a licensed CPA firm examines your controls against the AICPA's Trust Service Criteria and issues a report describing what they found. That report can contain a "clean" (unqualified) opinion, a qualified opinion (some issues), or an adverse opinion (significant problems). Your customers then read that report and decide whether your controls meet their risk tolerance.

This is an important distinction because it means two companies can both have SOC 2 reports but offer wildly different levels of security assurance. The report is a detailed narrative, not a binary pass/fail stamp. Sophisticated buyers - the kind you want as customers - actually read these reports.

The framework was first introduced in 2010 and has been revised multiple times, most recently with the 2017 Trust Service Criteria update that aligned the criteria more closely with the COSO internal controls framework and brought the criteria count from about 60+ points of focus to a more structured set of Common Criteria (CC series). As of 2026, the framework remains one of the most requested security attestations in the B2B software market.

The short answer: any company that stores, processes, or transmits customer data as part of providing a service. The longer answer has some nuance.

SOC 2 is technically voluntary. No law mandates it. But market forces have made it functionally mandatory for several categories of companies:

You almost certainly need SOC 2 if you are:

• A SaaS company selling to mid-market or enterprise customers, especially in the US
• A cloud infrastructure or managed services provider hosting customer data or workloads
• A fintech company handling financial data, even indirectly
• A healthtech company (often alongside HIPAA - SOC 2 doesn't replace HIPAA but complements it)
• A data analytics or AI/ML company processing customer datasets
• Any B2B company where prospects regularly send security questionnaires

You probably don't need SOC 2 (yet) if you are:

• A B2C company with no enterprise sales motion
• Pre-revenue or very early stage with no customer data in production
• Selling physical products with no SaaS or hosted service component

Here's my rule of thumb, learned from doing this for years: if you've received more than three vendor security questionnaires in the past 12 months, you're past the point where SOC 2 pays for itself. Each questionnaire takes your team 20-40 hours to complete manually. A SOC 2 report replaces most of that work, and it's infinitely more credible than a self-attested spreadsheet.

The heart of SOC 2 is the five Trust Service Criteria (TSC). Think of them as five lenses through which the auditor examines your organization. Security is always required. The other four are optional - you include them based on what's relevant to your service and what your customers expect.

Let me walk you through each one in plain English, then get into the technical weeds.

1. Security (Common Criteria) - Always Required

This is the backbone. Security evaluates whether your system is protected against unauthorized access - both physical and logical. The AICPA calls this the "common criteria" because every SOC 2 audit includes it. It maps to nine CC-series criteria groups (CC1 through CC9) covering:

For most companies, the Security criterion alone requires 80-120 individual controls. This is the meat of the audit and where most of the preparation work goes.

2. Availability

Availability evaluates whether your system is operational and usable as committed or agreed upon. This isn't about achieving 100% uptime - it's about whether you've defined availability commitments (typically in SLAs) and have the controls to meet them.

What the auditor looks for:

• Documented SLAs with uptime commitments (e.g., 99.9%)
• Capacity planning and performance monitoring
• Disaster recovery and business continuity plans - tested, not just written
• Redundancy mechanisms (multi-AZ deployments, database replicas, failover procedures)
• Incident response procedures for outages, including communication protocols

Include Availability if: Your customers depend on your service for critical operations, your contracts include SLAs, or downtime for your service directly impacts their ability to serve their own customers.

3. Processing Integrity

Processing Integrity asks: does the system do what it's supposed to do? When data goes in, does the right thing come out? This criterion evaluates whether system processing is complete, valid, accurate, timely, and authorized.

What the auditor looks for:

• Quality assurance procedures for data processing
• Input validation controls
• Error handling and exception management
• Reconciliation processes (e.g., verifying that every transaction was processed correctly)
• Monitoring for processing anomalies

Include Processing Integrity if: You process financial transactions, perform calculations that others rely on (billing, payroll, analytics), or if data accuracy is central to your value proposition. If you're a payments processor, an accounting SaaS, or a data pipeline company, this criterion is non-negotiable.

4. Confidentiality

Confidentiality addresses whether data designated as confidential is protected as committed. This goes beyond just "security" - it's specifically about how you handle data that has been classified as confidential, whether that's customer intellectual property, pre-release financial data, or proprietary business information.

What the auditor looks for:

• Data classification policies (what counts as "confidential"?)
• Encryption of confidential data at rest and in transit
• Access restrictions - only authorized personnel can view confidential data
• Data retention and disposal policies
• Confidentiality agreements with employees, contractors, and sub-processors

Include Confidentiality if: You handle trade secrets, proprietary customer data, intellectual property, pre-publication research, or any data where unauthorized disclosure would be specifically harmful beyond a general security breach.

5. Privacy

Privacy is the most misunderstood criterion. It evaluates whether personal information (PII) is collected, used, retained, disclosed, and disposed of in accordance with your privacy commitments and with criteria set forth in the AICPA's Generally Accepted Privacy Principles (GAPP).

What the auditor looks for:

• A published privacy notice that matches actual practices
• Consent mechanisms for data collection
• Data subject access request (DSAR) procedures
• Data minimization practices
• Third-party data sharing disclosures and controls
• Cross-border data transfer safeguards

Include Privacy if: You collect PII from end users (not just business contacts), particularly if you're subject to GDPR, CCPA/CPRA, or other privacy regulations. However, many companies opt not to include Privacy in their SOC 2 scope, choosing to demonstrate privacy compliance through separate mechanisms (like GDPR assessments). This is a legitimate approach - discuss it with your auditor.

This is the second most common question I get, right after "what is SOC 2 compliance?" The difference is simple but consequential:

My honest recommendation: If you have time, skip Type 1 entirely and go straight to Type 2. Here's why: Type 1 costs 50-70% of what Type 2 costs, but has about 30% of the credibility. You'll end up doing Type 2 anyway - most customers treat Type 1 as a temporary concession, not a destination. The only scenario where Type 1 makes sense is when you have a specific deal that requires a SOC 2 report in the next 60-90 days and you can't wait for a Type 2 observation period.

The exception to this rule: if you're planning a 6-month Type 2 observation window (which many auditors now accept), the total timeline from start to report is comparable to a Type 1 plus gap period anyway. Talk to your auditor and your SOC 2 readiness services consultant about the fastest path to a credible report.

I've guided dozens of companies through this process, and the pattern is remarkably consistent. Here's what actually happens, phase by phase:

Phase 1: Scoping and Readiness (4-12 weeks)

Before the official audit begins, you need to figure out your scope (which Trust Service Criteria, which systems, which locations) and assess your current state. This is where a SOC 2 readiness assessment is worth its weight in gold.

During readiness, you'll:

• Define your system boundaries - which infrastructure, applications, people, procedures, and data are "in scope" for the audit
• Perform a gap assessment - compare your current controls against what the TSC require
• Create or update policies - information security policy, access control policy, incident response plan, change management policy, vendor management policy, and more (typically 12-20 policies)
• Implement missing controls - this is usually the biggest time sink; you're deploying MFA, setting up monitoring, documenting procedures, configuring access reviews, and so on
• Select your auditor - must be a licensed CPA firm with SOC examination experience

Phase 2: The Observation Period (Type 2 only - 3-12 months)

Once your controls are in place, the clock starts ticking on your observation period. During this time, you need to operate your controls consistently. The auditor will later sample evidence from this period to verify that controls were working.

This means:

• Access reviews happened quarterly (and you have the sign-off records)
• Incidents were logged and responded to per your documented procedures
• Changes went through your change management process (with approvals in your ticketing system)
• Vulnerability scans ran on schedule and findings were remediated within your stated SLA
• Employee security training was completed and tracked

The most common observation period is 12 months, which aligns with annual renewal. However, many companies start with a 6-month or even 3-month window for their first report, then extend to 12 months in subsequent years. A shorter window is perfectly legitimate - it just means your report covers less history.

Phase 3: Evidence Collection and Fieldwork (4-8 weeks)

This is where the auditor rolls up their sleeves. They'll request evidence for each control - typically via a shared portal or request list. Expect to provide:

• Screenshots of system configurations (MFA settings, encryption configs, firewall rules)
• Exports from your ticketing system showing change management workflows
• Access review records with manager sign-offs
• Penetration test reports
• Vulnerability scan results and remediation timelines
• Training completion records
• Incident response logs (if any incidents occurred)
• Board or management meeting minutes discussing security
• Vendor assessment documentation

The auditor samples across the observation period. For a 12-month period, they might pull one sample per month for recurring controls. If any sample fails, they'll expand their sample size - which means more work for you and more scrutiny on that control.

Phase 4: Report Drafting and Issuance (2-4 weeks)

After fieldwork, the auditor drafts the report. You'll have a chance to review for factual accuracy (you can't change the opinion, but you can correct misstatements about your systems). The final SOC 2 report typically includes:

• Section 1: Auditor's report (their opinion)
• Section 2: Management's assertion
• Section 3: System description (your infrastructure, people, processes)
• Section 4: Description of criteria, controls, tests, and results
• Section 5 (optional): Other information provided by management

A clean SOC 2 report will state an "unqualified opinion" - meaning the auditor found your controls were suitably designed and (for Type 2) operating effectively throughout the observation period. If there are exceptions, they'll be documented individually, and you'll have the opportunity to include management's response explaining the exception and what you've done to address it.

Let me break this down into the real cost categories, because the auditor's fee is only part of the picture. I've seen too many founders budget $30K for the audit and then act surprised when the total bill is three times that.

Year 2+ costs drop significantly - typically 40-60% of year one - because the readiness work is done, policies exist, tooling is deployed, and your team knows the drill. The ongoing costs are primarily the annual audit fee, tooling subscriptions, and the internal time for evidence collection.

The timeline question is where I see the most wishful thinking. "We need SOC 2 in two months" is something I hear roughly once a week. Let me set realistic expectations:

The biggest time variable isn't the audit itself - it's the readiness work. If you already have MFA deployed, centralized logging, documented policies, and a reasonable change management process, the gap between "where you are" and "where you need to be" might only be a few weeks of focused effort. If you're starting from a Google Doc that says "We take security seriously" and production access controlled by shared passwords, you're looking at months of infrastructure work.

This is exactly why I recommend engaging with a vCISO or SOC 2 readiness services partner early - ideally 6-12 months before you think you'll need the report. The readiness partner can help you build controls the right way the first time, so you're not scrambling to fix things during the observation period.

I've seen all of these firsthand. Some of them cost companies months of delays and tens of thousands of dollars. Learn from other people's pain.

1. Scoping too broadly

Including every system in your environment when only your SaaS platform and its supporting infrastructure are relevant. More scope = more controls = more evidence = more cost. A focused scope around the systems that actually process customer data is almost always the right call. Your internal HR system probably doesn't need to be in scope.

2. Treating policies as a checkbox exercise

Downloading a policy template pack, doing a find-and-replace with your company name, and calling it done. Auditors are not stupid. They'll ask you to walk them through your incident response plan. If your "plan" is a 40-page document nobody has read, you'll get caught. Policies should reflect what you actually do. If your real incident response process is "Alex gets a PagerDuty alert and Slacks the team," write that down (with a bit more structure) and make it your policy.

3. Ignoring the "people" controls

Companies obsess over technical controls (encryption, firewalls, MFA) and forget that CC1 and CC2 are about governance, communication, and organizational commitment to security. You need a security-aware culture: employee training records, background checks for roles with data access, confidentiality agreements, and documented reporting lines for security issues.

4. Starting the observation period before controls are ready

This one is heartbreaking because it wastes months. If you start your Type 2 observation period and your quarterly access reviews aren't happening yet, or your change management process has no approval workflow, you're accumulating failed control samples. Six months later, the auditor pulls samples from month two and finds nothing. That's an exception in your report - or worse, it forces you to restart the observation window.

5. No single owner

SOC 2 compliance touches engineering, IT, HR, legal, and executive leadership. Without a dedicated owner (whether that's an internal security lead or an external vCISO), things fall through the cracks. Access reviews don't happen. Policy updates get deprioritized. Training lapses. You need one person who wakes up every morning thinking about this.

6. Choosing the wrong auditor

Not all CPA firms are created equal when it comes to SOC 2. Some specialize in SOC 1 (financial controls) and treat SOC 2 as an afterthought. Others have deep technical expertise and can actually understand your cloud architecture. Ask prospective auditors how many SOC 2 reports they issue per year, whether their team includes technical specialists (not just accountants), and for references from companies similar to yours.

7. Forgetting about sub-service organizations

If you use AWS, GCP, Azure, Stripe, or any other cloud provider to process customer data, those are sub-service organizations. Your SOC 2 report needs to clearly describe which controls are your responsibility and which are the responsibility of your sub-service providers (the "carve-out" vs. "inclusive" method). This comes up in your system description and auditors will probe it. Have your sub-service organization SOC 2 reports on hand.

8. Treating SOC 2 as a one-time project

Your SOC 2 report expires. Not officially - there's no expiration date on the report itself - but buyers expect a report that covers the most recent 12-month period. If your report covered January to December 2025 and it's now October 2026, that's stale. SOC 2 is an annual commitment. Budget for it, staff for it, and bake it into your operating rhythm from day one.

These frameworks overlap but serve different purposes. Understanding the differences saves you from doing unnecessary work - or skipping something you actually need.

Quick decision guide:

• Selling primarily to US companies? Start with SOC 2.
• Selling internationally, especially in Europe? Consider ISO 27001 first, or do both.
• Handling protected health information? HIPAA compliance is non-negotiable. SOC 2 complements but doesn't replace it.
• Providing services that affect clients' financial reporting? That's SOC 1, not SOC 2.

For many of our clients, the eventual destination is SOC 2 + ISO 27001. The control overlap is substantial (70-80%), so if you build your security program with both frameworks in mind from the start, achieving both is significantly cheaper than doing them sequentially. An IT security audit can help you map your current posture against multiple frameworks simultaneously.

If you've read this far, you're probably ready to actually do something about SOC 2. Here's the practical sequence I recommend to every company, whether they're 20 people or 2,000:

Step 1: Determine if you actually need SOC 2 right now. Count your security questionnaires from the last year. Talk to your sales team about deals lost or delayed due to lack of compliance. Look at your ICP - if they're mid-market or enterprise, the answer is probably yes.

Step 2: Assign an owner. This could be your Head of Engineering, your IT Director, or - if you don't have a dedicated security person - a virtual CISO (vCISO). The vCISO route is increasingly popular for companies under 200 employees because it gives you experienced security leadership at a fraction of the cost of a full-time hire.

Step 3: Get a readiness assessment. A good SOC 2 readiness assessment will tell you exactly where you stand, what gaps exist, and what the realistic timeline and budget look like. This typically costs $10,000-$30,000 and saves multiples of that by preventing rework and scope creep.

Step 4: Build your remediation plan. Based on the gap assessment, create a prioritized list of controls to implement. Tackle the heavy-lift items first - deploying MFA, setting up centralized logging, writing core policies, and establishing change management workflows.

Step 5: Select tooling and an auditor. Compliance automation platforms (Vanta, Drata, Secureframe, Sprinto) can significantly reduce the evidence collection burden. Select your CPA firm early - popular firms book out 2-3 months in advance, especially in Q4.

Step 6: Start your observation period. Once controls are operating, formally begin the audit observation window. During this time, operate your controls diligently. Document everything. When in doubt, over-document.

Step 7: Complete fieldwork and get your report. Work with your auditor through evidence collection, address any questions or findings, and receive your SOC 2 report.

Step 8: Use the report. Share it with prospects (under NDA), update your security page, streamline your vendor questionnaire responses, and close deals faster. Then set a calendar reminder to start the renewal process 3 months before your next observation period ends.

Ready to Get SOC 2 Compliant?

Whether you're exploring SOC 2 for the first time or preparing for your annual renewal, our team has guided companies from seed stage to public markets through the compliance journey. Let's figure out the fastest, most cost-effective path for your specific situation.

The Bottom Line on SOC 2 Compliance

SOC 2 compliance isn't glamorous. Nobody starts a company dreaming about writing access control policies or collecting evidence for quarterly access reviews. But here's what I've learned after years of helping companies through this process: the organizations that treat SOC 2 as a genuine security improvement program - not just a checkbox to close deals - end up with better security, faster sales cycles, and fewer incidents. The report is a byproduct of doing security well.

That panicked Series B founder I mentioned at the beginning? We helped him get a Type 1 report in 10 weeks to unblock his deal, then transitioned into a 12-month Type 2 observation period. He closed the Fortune 500 account and three more like it. His only regret was not starting 12 months sooner.

If you're sitting where he was - knowing you need SOC 2 but not sure where to start - reach out. We offer SOC 2 readiness services, virtual CISO services, and IT security audits specifically designed to get you from confused to compliant as efficiently as possible. No thousand-page proposals. No six-month sales cycles. Just a straight conversation about what you need and how to get there.

Get in touch - we'll tell you honestly whether you're ready, what it'll cost, and how long it'll take.

Published: March 2026 · Author: Alexander Sverdlov · Last updated: March 25, 2026