What Is SOC 2 Compliance? A Practitioner's Guide for First-Timers

You got the question from a prospect: “Do you have a SOC 2 Type 2 report?” If you’ve never touched SOC 2 before, that question can feel like a foreign language. Here’s what it actually means, why it matters, and how to get from zero to audit-ready without rebuilding your entire compliance program.

TL;DR

• SOC 2 is the AICPA’s framework for evaluating how service organizations protect customer data — it’s not a regulation, but enterprise customers treat it like one
• Five Trust Service Criteria: Security (required for all), Availability, Processing Integrity, Confidentiality, Privacy
• Type 1 = controls designed correctly at a point in time; Type 2 = controls operating effectively over 3–12 months — enterprise buyers want Type 2
• The most common audit failures aren’t technical gaps — they’re execution failures: missed access reviews, no vendor assessments, inconsistent change control

What SOC 2 Actually Is (and Isn’t)

SOC 2 — System and Organization Controls 2 — is an auditing standard developed by the American Institute of Certified Public Accountants (AICPA). A licensed CPA firm examines your controls and issues a formal report attesting to whether they meet the Trust Services Criteria.

What it isn’t: a government regulation. No federal law requires SOC 2. But the market has essentially mandated it anyway. Over 60% of businesses are more likely to partner with SOC 2-compliant vendors, and roughly a third of organizations have lost deals specifically because they lacked the report. SOC 2 adoption surged 40% in 2024 as SaaS companies rushed to meet enterprise customer requirements.

What makes it different from ISO 27001: ISO 27001 is prescriptive — it tells you exactly which controls to implement. SOC 2 is principle-based. You determine what controls are appropriate for your environment and services, then auditors test whether those controls actually work. That flexibility is a feature, not a bug, but it means the framework doesn’t write your controls for you.

Who audits it: Only licensed CPA firms can issue SOC 2 reports. Not security consultants, not compliance platforms — a CPA with AICPA attestation authority.

The Five Trust Service Criteria

Every SOC 2 engagement is scoped against one or more Trust Service Criteria (TSC). Security is mandatory; the other four are optional but often required by customers or relevant to your business model.

Most first-time SOC 2 audits scope only Security. Adding Availability is common for infrastructure and SaaS. Adding all five is rare and typically unnecessary unless you have contractual obligations requiring specific criteria.

The Nine Common Criteria: Security in Detail

The Security criterion contains nine Common Criteria (CC1–CC9). These form the backbone of every SOC 2 report — the controls tested here determine whether you pass or struggle.

CC1: Control Environment

Foundation of internal control. Board and management commitment to integrity, ethical values, and organizational structure. Auditors look for: documented policies, defined roles, evidence that management sets the tone.

CC2: Communication and Information

Relevant information is identified, captured, and communicated in time for people to do their jobs. Auditors look for: policy distribution evidence, security awareness training records, communication channels for reporting issues.

CC3: Risk Assessment

The organization analyzes risk and evaluates how change affects risk. Auditors look for: a formal risk assessment process, documentation of identified risks, and evidence that risk reviews happen on schedule.

CC4: Monitoring Controls

Controls are monitored and evaluated for effectiveness. Auditors look for: internal audit or compliance reviews, log monitoring evidence, deficiency tracking and remediation.

CC5: Control Activities

Processes and technologies are in place to reduce risk to acceptable levels. Auditors look for: written procedures, automated controls, evidence that control activities happen as documented.

CC6: Logical and Physical Access Controls

This is where most audit findings live. CC6 covers access provisioning, deprovisioning, authentication requirements, encryption, and physical access to infrastructure.

Key evidence requirements under CC6:

• Access provisioning and termination procedures (with evidence of consistent execution)
• Multi-factor authentication on critical systems
• Encryption in transit and at rest
• Quarterly or more frequent access reviews with documented sign-off
• Physical access logs or badge records for infrastructure

CC7: System Operations

Systems are monitored for operational performance and security events. Incident response and disaster recovery plans are in place and tested. Auditors look for: SIEM or log monitoring configuration, incident tickets, DR test results.

CC8: Change Management

Material changes to systems are tested and approved before deployment. Auditors look for: change tickets, approval workflows, documented testing evidence, emergency change procedures.

CC9: Risk Mitigation

Risk is mitigated through vendor management and business processes. Auditors look for: vendor risk assessments, vendor SOC reports reviewed and on file, business continuity considerations for critical dependencies.

SOC 2 Type 1 vs. Type 2: The Decision That Actually Matters

This is the question most first-timers get wrong. Here’s the breakdown:

The practical advice: Don’t do a Type 1 and then wait a year to start Type 2. The most efficient path is the “staircase” approach:

1. Months 1–2: Run a gap assessment and remediate critical findings
2. Month 3: Type 1 audit fieldwork and report issuance — you have something to show prospects
3. Months 3–9: Type 2 observation period begins immediately, overlapping with your ongoing operations
4. Months 9–11: Type 2 fieldwork and report issuance

You get a Type 1 report to share with impatient prospects at month 3, and a Type 2 by month 10 or 11 — the thing they actually want.

The Scoping Decision Most Companies Get Wrong

Before you start, you need to decide:

• Which Trust Service Criteria to include (start with Security only unless there’s a specific customer or contractual requirement)
• Which systems are “in scope” (your production environment, customer-facing services, and the infrastructure supporting them)
• Which subservice organizations (vendors) are “carved out” vs. “inclusive” in your report

Getting scope wrong creates problems in both directions. Too narrow and your report won’t satisfy enterprise buyers who want your core SaaS platform covered. Too broad and you’re testing controls in systems that don’t handle customer data, inflating your audit cost and evidence burden.

A good scoping rule of thumb: anything that touches production customer data is in scope. Development and staging environments are typically excluded unless they contain production data.

What Auditors Actually Test

SOC 2 auditors don’t just review documentation — they test operating effectiveness by sampling actual control execution over the observation period. Typical sampling:

• For a 12-month Type 2: 15–25 samples per control
• For a 6-month Type 2: 10–15 samples per control
• The number of samples scales with the observation period and the frequency of the control (daily, weekly, monthly)

This is why “we have a policy” isn’t enough. You need evidence that the policy was followed, consistently, every time, with documentation. An access review policy that wasn’t executed for two of the four quarterly cycles will generate a finding.

The Most Common SOC 2 Audit Findings (and Why They Happen)

The organizations that struggle in SOC 2 audits almost never fail because they lack sophisticated security technology. They fail because of execution gaps between documented procedures and actual practice.

1. Access Reviews Not Completed

You have a policy requiring quarterly access reviews. You ran them in Q1 and Q3 but forgot Q2 and Q4. That’s an exception — and a finding.

Fix: automate access review scheduling with a dedicated tool. Build a calendar reminder 30 days before each review cycle. Assign a named owner. Require documented sign-off that goes into your evidence archive.

2. Terminated Employee Access Not Revoked Timely

One of the most consistently flagged findings across SOC 2 audits: a terminated employee retained access for days, weeks, or months after departure. The auditor samples your terminations list against your access provisioning system, and any gap is a finding.

Fix: tie offboarding to HR workflow. Access revocation should trigger within 24 hours of termination, with documented confirmation stored in your evidence tracker.

3. Vendor SOC Reports Not Reviewed

CC9 requires you to assess and monitor vendors with access to your systems or customer data. Most organizations procure vendor SOC 2 reports but never formally review them. Getting the report isn’t the control — reviewing it and documenting the review is.

Fix: require vendors to provide their current SOC 2 report annually. Build a vendor review calendar. Document that the review happened and what compensating controls you’ve applied for any noted exceptions in the vendor’s report. (For more on vendor risk management workflows, see Third-Party AI Vendor Risk Assessment: Due Diligence Framework.)

4. Change Management Procedures Not Consistently Followed

Your change management policy requires a ticket, a review, and approval before deploying to production. Then an engineer pushes a “small fix” directly without a ticket. That’s an exception.

Fix: enforce change procedures technically — require tickets before merges to main, require PR approvals, use deployment gates that block unreviewed changes.

5. Evidence Gaps

The most underestimated SOC 2 challenge: evidence collection. Auditors don’t take your word for it. They want screenshots, logs, tickets, emails, and sign-off records — for 15 to 25 samples per control, per observation period.

Build your evidence collection system before you start your Type 2 observation period. Every time a control fires, capture the evidence immediately. Trying to reconstruct evidence at audit time is painful and often incomplete.

How to Prepare: A 30/60/90-Day Readiness Plan

Days 1–30: Gap Assessment

• Inventory your in-scope systems and identify current control coverage
• Map your existing controls to the CC1–CC9 common criteria
• Identify control gaps where no documented procedure or technical control exists
• Prioritize gaps by likelihood of audit finding (CC6 access controls first, then CC8 change management)

Days 31–60: Remediation Sprint

• Write (or formalize) policies for any undocumented areas
• Implement automated controls where possible (MFA enforcement, access provisioning integration with HR)
• Build your evidence collection system — a tracker where every control has a named owner, frequency, and evidence folder
• Conduct a mock access review to test the process end-to-end

Days 61–90: Readiness Assessment and Auditor Selection

• Engage an auditor for a Type 1 or directly for Type 2
• Run a formal readiness assessment — either self-conducted or with the auditor
• Remediate any remaining gaps before the Type 1 date or before the Type 2 observation period begins
• Train all control owners on evidence requirements

Choosing the Right Auditor

Not all CPA firms are equal for SOC 2. Things that matter:

• AICPA peer review: Verify the firm has a clean AICPA peer review record
• Industry experience: A firm that audits tech companies understands cloud infrastructure, DevOps, and SaaS architectures; one that primarily audits manufacturing may not
• Communication style: Your auditor should explain what they need, not just list deficiencies after the fact
• Pricing clarity: Get a fixed-fee engagement letter; open-ended “time and materials” arrangements inflate cost significantly

Mid-market audit firms with SOC 2 specialties typically charge $15,000–$30,000 for a Type 1 and $30,000–$60,000 for a Type 2 for a standard SaaS company.

What You Get at the End

A SOC 2 report has four main sections:

1. Management’s Assertion: Your statement that controls were in place and operating effectively
2. Service Auditor’s Report: The CPA firm’s opinion — either “no exceptions” or a qualified opinion noting deviations
3. Description of the System: The system boundary, infrastructure, and services included in scope
4. Control Activities with Auditor’s Testing and Results: Every control tested, the testing methodology, and results — this is the section prospects read

You’ll receive both a restricted-use report (for prospective customers under NDA) and potentially a summary or bridge letter if you need to cover periods between audit cycles.

So What?

SOC 2 isn’t just a vendor checkbox — it’s a forcing function for operational discipline. The organizations that do it well don’t just pass audits; they build sustainable security and compliance operations that scale.

The hardest part isn’t implementing controls. It’s keeping evidence, maintaining consistency, and making sure no one takes a shortcut during the observation period. That’s an organizational behavior change, and it starts before you engage an auditor.

If you’re building your SOC 2 readiness from scratch, a pre-mapped checklist against all 151 AICPA controls saves weeks of gap analysis work. The SOC 2 Compliance Checklist covers every Trust Service Criteria control with evidence guidance, a 12-month audit preparation roadmap, and a Type 1 vs. Type 2 decision framework.

For broader compliance program infrastructure, see Building a Compliance Management System That Survives a CFPB Exam and Regulatory Change Management: How to Track New Rules and Stay Ahead of Compliance Deadlines.

Frequently Asked Questions

What is SOC 2 compliance? SOC 2 is an AICPA-developed audit framework that evaluates how service organizations protect customer data through five Trust Service Criteria. Security is the only required criterion; the others (Availability, Processing Integrity, Confidentiality, Privacy) are added based on your business model and customer requirements.

Who needs SOC 2? Any SaaS company, cloud provider, or technology vendor handling customer data in a B2B context. Enterprise buyers — especially in financial services, healthcare, and government — nearly universally require a SOC 2 Type 2 report before signing vendor contracts.

What’s the difference between SOC 2 and ISO 27001? SOC 2 is principle-based (you design controls appropriate to your environment; auditors test them). ISO 27001 is prescriptive (it specifies required controls). SOC 2 is more common in US B2B markets; ISO 27001 is more common in European and international enterprise contexts. Organizations with global customer bases often pursue both.

How much does SOC 2 cost? Audit costs alone run $15,000–$30,000 for Type 1 and $30,000–$60,000 for Type 2. Total project costs including readiness preparation, remediation, compliance tooling, and consultant support can reach $80,000–$150,000+ for complex environments. Simpler SaaS environments with mature security programs may come in below these ranges.

How do I maintain SOC 2 compliance after my first audit? SOC 2 Type 2 reports are typically issued annually (covering a 12-month observation period). To maintain compliance, you need continuous evidence collection, regular access reviews, consistent change management execution, and annual vendor assessments. Between audit cycles, you may issue bridge letters to prospective customers confirming no material changes to your control environment.

Can a startup get SOC 2? Yes — and increasingly, you need it to close enterprise deals. Startups with cloud-native infrastructure often have an easier time than legacy enterprises because they can enforce controls technically from the start (MFA enforcement, automated access provisioning, CI/CD pipeline gates for change management). The main challenge for startups is evidence collection discipline and consistent execution during the observation period.