SOC 2 has become the de facto trust standard for technology companies, SaaS platforms, and service providers that handle customer data. If you sell software or services to enterprise clients, you will eventually be asked for your SOC 2 report — and increasingly, the absence of one is a deal-breaker.
Yet despite its prevalence, SOC 2 remains one of the most misunderstood compliance frameworks. This guide explains what SOC 2 actually is, what the audit process looks like, and what organizations commonly get wrong.
What Is SOC 2?
SOC 2 — Service Organization Control 2 — is an auditing standard developed by the American Institute of Certified Public Accountants (AICPA). It evaluates a service organization's controls relevant to security, availability, processing integrity, confidentiality, and privacy. The standard is based on five Trust Services Criteria (TSC), with Security being the only required criterion — the others are optional depending on your business and customer requirements.
SOC 2 is not a certification in the traditional sense. No one "certifies" you as SOC 2 compliant. Instead, an independent CPA firm audits your controls and produces a formal opinion — either a Type I or Type II report — that attests to the design and operating effectiveness of those controls.
SOC 2 Type I vs. Type II: The Critical Difference
This is the most important distinction for organizations pursuing SOC 2:
- SOC 2 Type I is a point-in-time assessment. The auditor reviews your controls as of a specific date and opines on whether they are suitably designed to meet the Trust Services Criteria. Type I can be completed relatively quickly — some organizations obtain a Type I report in 3–6 months. It attests to design, not operation.
- SOC 2 Type II covers a period of time — typically 6 or 12 months — and attests to both the design and operating effectiveness of controls over that period. The auditor reviews evidence that controls were actually operating throughout the observation window: access review logs, change management records, patch management evidence, security monitoring alerts, and penetration test reports.
Enterprise customers almost universally require Type II. A Type I report tells a potential customer that your controls look good on paper as of a specific date. A Type II report tells them your controls actually operated for 12 months. The difference in customer confidence — and in sales cycle friction — is significant.
The Trust Services Criteria
Security (CC — Common Criteria)
Security is the only required Trust Services Criterion. The Common Criteria covers logical and physical access controls, system operations, change management, and risk mitigation. CC6.1 — logical access — is where most organizations have significant gaps: user provisioning and deprovisioning processes, MFA enforcement, privileged access management, and third-party access controls.
Penetration testing evidence is required under CC6.1: your auditor will request a penetration test report conducted within the observation period demonstrating that your systems were tested for exploitable vulnerabilities.
Availability
If your customers have uptime or SLA commitments, the Availability criterion documents how you meet them: redundant infrastructure, disaster recovery capabilities, monitoring, and incident response procedures.
Confidentiality
Confidentiality covers how customer data designated as confidential is protected throughout its lifecycle — encryption in transit and at rest, data classification, and disposal procedures.
Processing Integrity
Processing Integrity is relevant for transaction processing systems: ensuring that processing is complete, valid, accurate, timely, and authorized.
Privacy
Privacy applies to collection, use, retention, and disclosure of personal information — relevant for organizations subject to GDPR, CCPA, or handling consumer data at scale.
What Auditors Actually Examine
Understanding what evidence auditors request is essential to preparing for a Type II audit. Common evidence categories include:
- Access control evidence: User provisioning/deprovisioning logs, quarterly access reviews, MFA enforcement reports, privileged access audit trails
- Change management records: Change tickets, approval workflows, deployment logs, rollback procedures
- Penetration test report: A full-scope penetration test conducted within the observation period, signed by the testing engineer, with CVSS-scored findings and evidence of remediation for critical/high findings
- Vulnerability management: Scan reports, patch records, SLA adherence documentation
- Security monitoring: SIEM/EDR alert logs, incident records, response documentation
- Vendor management: Third-party risk assessments, contracts with security terms, vendor SOC 2 reports
- Employee security training: Training completion records, security awareness program documentation
- Incident response: IR plan, tabletop exercise records, actual incident documentation and post-mortems
How Long Does SOC 2 Type II Take?
Timeline to a first Type II report commonly runs 9–15 months, anchored by an observation window that is frequently 3–6 months for an initial report (12 months for recurring annuals); the AICPA sets no minimum window:
- Months 1–2: Readiness assessment — identifying control gaps against Trust Services Criteria
- Months 3–4: Gap remediation — implementing missing controls and operationalizing processes
- Months 5–10: Observation period — a 3-to-6-month window for an initial report, during which controls must operate and evidence must be collected
- Months 11–12: Audit fieldwork, evidence review, management assertions, report issuance
A 3-to-6-month observation period is standard for an initial Type II report; recurring reports then renew annually over a 12-month window.
Common SOC 2 Preparation Mistakes
Starting with tools instead of processes. SOC 2 auditors evaluate whether controls operate consistently — which means documented processes with evidence of execution. Buying a SIEM platform without implementing alert response procedures produces a lot of data and no audit evidence.
Treating penetration testing as a checkbox. Auditors review penetration test quality. A scanner output with a cover page is not a penetration test. A credible Type II audit requires a manual penetration test with CVSS-scored findings, proof of exploitation, and evidence of remediation for high-severity findings.
Scoping too broadly. SOC 2 scope should be carefully defined to include systems that process or store customer data — and exclude systems that do not. Over-scoping increases audit cost and control burden without adding customer assurance. Work with your auditor to define scope before beginning observation.
No access review cadence. User access reviews conducted quarterly (or at minimum semi-annually) are standard auditor expectations. Organizations that conduct access reviews for the first time when auditors request evidence of the process are flagged immediately.
What SOC 2 Costs
Costs vary significantly by organization size and auditor. For mid-market technology companies:
- Readiness assessment: $5,000–$20,000 depending on scope and advisor
- Penetration testing (required): $8,000–$15,000 for network and application testing
- Audit fees (Type II): $15,000–$40,000 for regional and boutique CPA firms; $60,000–$400,000+ for Big 4 firms (Deloitte, PwC, KPMG, EY), per published 2025–2026 auditor pricing surveys
- Tool costs: Compliance automation platforms (Vanta, Drata, Secureframe) price by custom quote rather than published list prices, with cost driven primarily by employee headcount, the number of compliance frameworks in scope, and add-ons — so budget against a sales quote scoped to your environment rather than a flat sticker figure
Getting Started
The right first step is a readiness assessment: a structured review of your current controls against SOC 2 Trust Services Criteria that identifies gaps, estimates remediation effort, and produces a realistic timeline for Type II readiness. For NYC technology companies, Fortress MSSP provides readiness assessment and penetration testing services designed to satisfy SOC 2 auditor requirements. The penetration test report we deliver is formatted specifically to meet the evidence requirements your auditor will request.