SOC 2 — a practitioner reference

ControlForge free guide · 2026-05-23 · Reflects the 2017 Trust Services Criteria with Revised Points of Focus 2022

Quick reference

Applies to: service organisations whose customers entrust them with data — typically SaaS, cloud providers, managed-service providers, data processors, payroll bureaus, claims administrators, fintechs, healthtechs.
Mandatory or voluntary: voluntary at the regulator level. Effectively mandatory for SaaS firms selling to US enterprise buyers from approximately Series B onwards — RFP screening, procurement, and customer security questionnaires consistently require SOC 2 Type II.
Year published: AICPA TSP Section 100, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (with Revised Points of Focus 2022). The criteria themselves are unchanged since 2017; the 2022 revision added and clarified Points of Focus to address evolving technology and threat environments.
Issuing body: American Institute of Certified Public Accountants (AICPA), via the Assurance Services Executive Committee (ASEC).
Penalties: none under the framework itself. SOC 2 is an attestation engagement, not a regulatory regime. Adverse opinion or qualified opinion exposes the service organisation to commercial and contractual consequences.
ControlForge density: 65 controls curated (security CC1–CC9 + supplemental TSC); 17 cross-framework clusters reference SOC 2, primarily in IAM, monitoring, and incident-response areas.

What it is

SOC 2 is an attestation engagement performed by a licensed CPA firm under the AICPA's Statement on Standards for Attestation Engagements (SSAE) No. 18 (now superseded by SSAE 21 for examinations). The engagement results in a report — a SOC 2 report — describing the service organisation's system, the controls relevant to the Trust Services Criteria in scope, and the auditor's opinion on whether those controls were suitably designed (Type I) and operating effectively over a period (Type II).

The "SOC" in SOC 2 stands for System and Organization Controls. The naming history is muddled — SOC 2 originated as a successor to SAS 70 reports (which were primarily financial-controls-focused) and has gone through several refinements. Today, the relevant authoritative literature is:

TSP Section 100, 2017 Trust Services Criteria (with Revised Points of Focus 2022) — defines the criteria.
AICPA SOC 2 Description Criteria (DC Section 200, 2018) — defines how management describes the system.
AICPA SOC 2 Reporting Guide — guidance for CPAs performing the engagement.
SSAE 21 — the attestation standard governing the examination.

SOC 2 reports come in two types:

Type I — point-in-time. Controls suitably designed at a specific date. Easier to obtain (typically 4–8 weeks of engagement); shorter operational history needed. Useful as a stepping-stone to Type II or for early-stage SaaS.
Type II — operating effectiveness over a period (typically 6 or 12 months). The market-standard deliverable. Enterprise customers expect Type II with a minimum 6-month coverage period and frequently 12 months.

A SOC 2 report is distribution-restricted — typically shared under NDA with prospects, customers, regulators, and authorised business partners — not published openly. Some organisations issue a "SOC 3" report (general use, no detailed controls) as a public summary, though SOC 3 has limited utility in modern procurement processes.

Structure at a glance

SOC 2 is organised around the five Trust Services Criteria (TSC) categories:

Security (Common Criteria CC1–CC9) — required in every SOC 2 engagement. The other four TSCs are optional and selected based on the service organisation's offering.
Availability (A1) — system availability per commitments.
Processing Integrity (PI1) — system processing is complete, valid, accurate, timely, and authorised.
Confidentiality (C1) — information designated as confidential is protected.
Privacy (P1–P8) — personal information is collected, used, retained, disclosed, and disposed of in conformity with commitments.

The Security TSC is sometimes called the Common Criteria because the same 9 sections apply across all engagements. Its sections are:

CC1 — Control Environment. Integrity and ethics, board oversight, organisational structure, commitment to competence, accountability.
CC2 — Communication and Information. Internal information generation and use; external communication.
CC3 — Risk Assessment. Objectives, risk identification, fraud risk, change-related risk.
CC4 — Monitoring Activities. Ongoing and separate evaluations; communication of deficiencies.
CC5 — Control Activities. Selection and development of controls; technology controls; policies and procedures.
CC6 — Logical and Physical Access Controls. Access provisioning, authentication, removal, restriction; physical access; data segregation; transmission controls.
CC7 — System Operations. Vulnerability management; system monitoring; security event response; recovery; communication of incidents.
CC8 — Change Management. Change authorisation, design, development, testing, and approval.
CC9 — Risk Mitigation. Risk-mitigation activities including vendor and business-partner risk.

Each section contains numbered criteria (e.g. CC6.1 through CC6.8) with associated Points of Focus — characteristics that may assist management and the practitioner in evaluating whether controls are suitably designed and operating effectively. The 2022 revision did not change the criteria; it added and clarified Points of Focus to address newer risks (cloud, third-party reliance, ransomware, secure development, data protection).

A note on the criteria-vs-controls distinction that matters in practice: AICPA does not specify the controls. The service organisation designs its own controls to meet the criteria, and the auditor evaluates whether those controls are suitably designed and operating effectively. This is a key difference from prescriptive frameworks like PCI DSS or NIST SP 800-53.

Who must comply

SOC 2 is voluntary. Its commercial gravity comes from procurement:

US enterprise B2B SaaS — SOC 2 Type II is the de-facto floor for selling to Fortune 1000 and mid-market US enterprises. Customer security questionnaires routinely require it; RFP responses without it are downgraded.
Cloud providers and managed-service providers — global, but US procurement-driven.
Fintech, healthtech, payroll, claims administrators — service organisations handling sensitive customer data routinely treat SOC 2 Type II as table stakes.
Vendors to publicly listed US companies — SOX 404 compliance frameworks frequently require SOC 2 Type II as evidence of internal-control reliance on third-party services.

International organisations selling into US markets typically obtain SOC 2 Type II alongside (or in lieu of) ISO 27001 to satisfy US procurement. EMEA and APAC procurement traditionally weighted ISO 27001 higher, but SOC 2 is increasingly accepted globally — particularly for cloud-native SaaS.

There is no public registry of SOC 2-attested organisations (reports are restricted-distribution). Buyer-side validation happens through report review under NDA.

Core obligations / control families

SOC 2 obligations are categorised differently from ISO 27001 or NIST CSF — by Common Criteria and supplemental TSCs rather than by domain. Coverage maps to ControlForge clusters as follows:

CC1 Control Environment (5 criteria). Board oversight, organisational ethics, structure, competence, accountability. The 2022 Points of Focus revisions strengthened the CC1.3 reporting-structure and CC1.5 accountability content. Maps into cl-roles-responsibilities, cl-policy, and cl-personnel-security.

CC2 Communication and Information (3 criteria). Internal communication of objectives and responsibilities; obtaining or generating relevant information; external communication. The 2022 revisions added detail on information classification, asset inventory, and data flow. Maps into cl-asset-inventory, cl-data-classification, and cl-awareness.

CC3 Risk Assessment (4 criteria). Specifying objectives; identifying and analysing risk; fraud risk; significant-change risk. Where SOC 2's risk methodology often differs from ISO 27001's: SOC 2 emphasises link to service commitments and system requirements ("the system" is a core SOC 2 concept). Maps into cl-risk-assessment and cl-change-management.

CC4 Monitoring Activities (2 criteria). Ongoing and separate evaluations of internal control; communication of deficiencies. Auditor focus: internal-audit programme, management review of monitoring outputs, ticket-system evidence of deficiency tracking and remediation. Maps into cl-mandatory-audit and cl-monitoring-activities.

CC5 Control Activities (3 criteria). Selection of controls (general); technology controls; deployment via policies and procedures. The general scaffolding under which the more specific CC6–CC9 controls sit. Maps into cl-policy.

CC6 Logical and Physical Access Controls (8 criteria). The largest section by criteria count. CC6.1 covers identity-management infrastructure; CC6.2 user registration/deregistration; CC6.3 authorisation/role management; CC6.4 physical access; CC6.5 destruction of media; CC6.6 protection against external threats; CC6.7 data transmission protection; CC6.8 unauthorised software prevention. This is the most heavily tested section in most SOC 2 audits — 30–40% of audit hours. Maps into cl-access-rights, cl-multi-factor-authentication, cl-authentication, cl-secure-disposal, cl-network-protection, and cl-cryptography.

CC7 System Operations (5 criteria). CC7.1 configuration management; CC7.2 system monitoring and event detection; CC7.3 security event evaluation; CC7.4 incident response; CC7.5 recovery. The operational lifecycle. Auditor focus: SIEM coverage, alert-to-incident traceability, incident response runbooks and test evidence, recovery testing. Maps into cl-monitoring-activities, cl-logging, cl-incident-response-execution, cl-ir-plan-prep, cl-ir-reporting, and cl-backup.

CC8 Change Management (1 criterion). CC8.1 — authorisation, design, testing, approval, deployment of changes. Single criterion but heavily evidence-bearing. Auditor sample of 25–60 changes is typical, traced from request through production deployment. Maps into cl-change-management.

CC9 Risk Mitigation (2 criteria). CC9.1 risk-mitigation activities; CC9.2 vendor and business-partner risk. The vendor-risk content materially strengthened in the 2022 Points of Focus revisions. Maps into cl-supplier-policy and cl-cloud-shared-responsibility.

Supplemental TSCs: - Availability (A1.1–A1.3) — capacity, environmental protection, recovery. Maps into cl-bcp-ict-readiness. - Processing Integrity (PI1.1–PI1.5) — input completeness/accuracy, processing, output, data storage. Maps into cl-processing-integrity. - Confidentiality (C1.1–C1.2) — identification and retention of confidential information; disposal. Maps into cl-data-classification and cl-secure-disposal. - Privacy (P1–P8) — notice, choice/consent, collection, use/retention/disposal, access, disclosure to third parties, security, quality, monitoring and enforcement. Closer in shape to GDPR than to security TSC. Maps into cl-privacy, cl-data-subject-rights, cl-personal-data-erasure, and cl-data-subject-rights.

TSC selection in practice. Security is mandatory. Availability is the most-commonly-added second TSC, particularly for SaaS firms whose customers have uptime commitments. Confidentiality is added by service organisations whose customer contracts include confidentiality of specific data sets (legal services, M&A advisory, regulated industries). Processing Integrity is rare outside specific contexts (transaction processing, payroll, claims administration) — the criteria are demanding and not always commercially valuable. Privacy is the most-resource-intensive supplemental TSC and is typically pursued only when a customer-specific commitment or regulatory driver (state privacy law alignment, GDPR-adjacent positioning) makes it necessary; many SaaS firms find that ISO 27701 certification or a documented GDPR/DPDPA compliance posture serves better as evidence of privacy controls than the SOC 2 Privacy TSC.

How auditors test it

SOC 2 audits are conducted by licensed CPA firms registered with the AICPA. Common engagement firms in the SaaS market include the Big 4 (Deloitte, EY, KPMG, PwC), national firms (BDO, Grant Thornton, RSM, Crowe), and specialised SOC-2 firms (A-LIGN, Schellman, Insight Assurance, Sensiba San Filippo).

Engagement structure for SOC 2 Type II:

Planning and scoping (2–4 weeks). System description; trust services criteria selection; control identification; readiness assessment.
Audit period (typically 6 or 12 months). The period during which controls must operate effectively.
Fieldwork (4–8 weeks at the end of the audit period). Sample testing of controls.
Reporting (2–4 weeks). Draft report, management responses to exceptions, final report issuance.

Total elapsed time from kickoff to issued report: typically 9–18 months for a first Type II.

Cost structure varies materially by firm tier and scope. A first SOC 2 Type II with a specialist firm typically runs $40,000–$120,000 USD for a single-TSC (Security only) engagement at a mid-size SaaS company; Big-4 engagements run higher. Adding TSCs (Availability, Confidentiality, Privacy) adds cost; multiple-system scope adds cost. The market has shifted in 2024–2026 toward continuous-monitoring tooling integration (Vanta, Drata, Secureframe, Sprinto, Thoropass), which can reduce evidence-gathering cost but does not reduce the auditor's testing work.

Evidence patterns during fieldwork:

Inquiry: structured interviews with control owners covering process narrative.
Observation: live observation of controls (e.g. access review meeting, change advisory board, incident response runthrough).
Inspection: documentation review — policies, procedures, completed forms, tickets, logs, screenshots.
Re-performance: auditor independently re-performs a control activity (e.g. re-runs an access query, recalculates an access removal date).

Sample sizes are statistical: typical samples are 25 for high-frequency controls (daily, weekly), 5–10 for medium-frequency (monthly), 1–3 for low-frequency (quarterly, annual). AICPA guidance allows judgmental sampling for unique events.

Report types and opinions:

Unqualified ("clean") — controls suitably designed and operating effectively across the period. The target outcome.
Qualified — most controls effective, but specific identified deficiencies or scope limitations. Buyers will review carefully and may push back on contracts.
Adverse — pervasive control failures. Effectively unusable for procurement purposes.
Disclaimer of opinion — auditor unable to form an opinion (rare).

Exceptions and deviations during the period are documented in the report. A small number of exceptions (e.g. 2–3 minor terminations not processed within SLA over a 12-month period) is common and typically does not lead to qualified opinion if root-cause and remediation are documented. Larger deviations or systemic process failures typically do.

How it relates to other frameworks

SOC 2 sits in a specific commercial niche: US-oriented attestation of operating effectiveness. Its relationships:

ISO/IEC 27001:2022 — concept-overlap, control-overlap, different audit regimes. Many organisations hold both, particularly for global sales motion. SOC 2's CC6 (access controls) and CC7 (system operations) heavily overlap ISO 27001 Annex A.5 and A.8. ControlForge bridges them through cl-access-rights, cl-monitoring-activities, and cl-change-management.
NIST CSF 2.0 — concept-aligned. SOC 2 CC1–CC9 maps roughly: CC1+CC2 → Govern; CC3 → Identify; CC6+CC7 → Protect+Detect+Respond; CC4 → ongoing Detect+oversight; CC8 → Protect (change); CC9 → Govern (supply chain). CSF gives strategic narrative; SOC 2 gives the audit attestation.
HIPAA Security Rule — overlap on access controls, audit logging, incident response. Healthcare SaaS frequently holds SOC 2 + HIPAA reports. SOC 2 + HITRUST CSF certification is the more comprehensive healthcare combo.
PCI DSS v4.0.1 — payment-card-specific; SOC 2 covers general security baseline that PCI assumes. Many payment processors hold both.
GDPR / DPDPA — the privacy TSC (P1–P8) overlaps GDPR principles and DPDPA Data Principal rights. SOC 2 Privacy is not a substitute for either regulation but provides operational evidence.
ISO/IEC 27701:2025 — privacy information management standalone certification; offers more comprehensive privacy coverage than SOC 2 Privacy TSC for organisations needing GDPR/DPDPA-aligned evidence.
SEBI CSCRF — Indian regulated entities operating SOC-2-aligned controls can map them to CSCRF requirements; CSCRF's Aug 2025 technical clarifications recognise certain ISO 27001 equivalences (SOC 2 is not directly recognised).

The single biggest cross-framework benefit of SOC 2 evidence: the operational records (tickets, logs, change records, access reviews, monitoring outputs) that auditors test for SOC 2 also satisfy ISO 27001 audit sampling, NIST CSF assessment evidence, and most enterprise customer security questionnaires.

Common pitfalls

Five recurring failure patterns:

System description gaps. The Management Description of the System (Section 3 of the SOC 2 report) is materially incomplete or inconsistent with operational reality. Auditors flag this in the description-criteria evaluation. Fix: treat the system description as a documented design specification that gets reviewed quarterly, not as audit-time prose.
Access reviews performed but evidence thin. Quarterly access reviews happen but are signed off without traceable evidence of approval decisions. CC6.2 and CC6.3 evidence depth is consistently the most-cited gap. Fix: structured access review tooling with reviewer/approver per access right, decisions captured, evidence retained.
Change-management sampling exposes process gaps. Auditor samples 40–60 changes; finds emergency changes deployed without documented approval, hotfixes bypassing change advisory board, or production changes without rollback plans. CC8.1 evidence is high-volume and operational. Fix: change-management policy aligned with operational reality; ticketing-system enforcement; separate emergency-change process with retrospective approval.
Vendor risk programme limited to top-10 vendors. CC9.2 (vendor and business-partner risk) tested against the full vendor inventory; service organisations frequently have 50+ vendors but only 10 documented. The 2022 Points of Focus revisions sharpened expectations here. Fix: tiered vendor risk programme with risk-based due-diligence depth; integrated vendor register tied to procurement.
Incident response evidence thin in CC7.4. Incident response policy exists; runbooks documented; but no actual incidents in the period (or incidents handled outside the documented process). Auditors expect to see either real incidents traced through the lifecycle or tabletop exercises producing similar evidence. Fix: tabletop exercises with documented timeline, decisions, lessons learned; real incidents tracked through the documented process even when minor.

Two further patterns worth flagging:

Privacy TSC scope overreach. Organisations select Privacy TSC without operationally implementing P1–P8. The eight Privacy criteria are substantial and significantly broader than the security TSC. Many SaaS firms find that GDPR or DPDPA compliance gives them the foundation, but the SOC 2 Privacy TSC requires additional documented evidence (notice mechanisms, choice/consent tracking, disclosure registers).
Confidentiality TSC mistaken for "advanced security". Confidentiality (C1) covers identification, retention, and disposal of confidential information — narrower than expected. It's not a step-up from Security; it's a complementary scope for organisations whose service commitments include confidentiality-of-specific-data above and beyond security.

When to use this framework

SOC 2 Type II is the right choice when:

You sell SaaS to US enterprise buyers — the procurement-driven floor.
You need an attestation deliverable, not a certificate — SOC 2 is an opinion-based report, useful for customers performing vendor due-diligence.
You're at Series B+ — earlier stage Type I bridge engagements work; full Type II makes sense once enterprise procurement starts to dominate the pipeline.
You can sustain 12 months of evidence discipline — the audit period is the binding constraint.

SOC 2 is less appropriate when:

You sell primarily to EMEA or APAC enterprise buyers — ISO 27001 typically carries more procurement weight.
You're a regulated entity with a sectoral framework — the sectoral framework typically takes primacy; SOC 2 may add cost without commensurate procurement benefit.
You need a public-facing certification mark — SOC 2 reports are restricted-distribution. ISO 27001 certifications are public.

Pairing strategy: many SaaS firms scaling globally ultimately hold both SOC 2 Type II + ISO 27001:2022 + ISO 27701 (for GDPR/DPDPA). The evidence overlap is large — ~70% of artefacts serve multiple regimes.

A note on the continuous-monitoring tooling shift. The 2024-2026 SaaS market saw rapid adoption of compliance-automation tools (Vanta, Drata, Secureframe, Sprinto, Thoropass) that integrate with cloud providers, identity systems, and ticketing tools to continuously collect SOC 2 evidence. These platforms compress the evidence-gathering burden materially and surface control deviations in near-real-time, but they do not replace the auditor's professional judgement, do not change the criteria, and do not reduce the auditor's testing hours below SSAE 21 minimums. The right framing: continuous-monitoring tooling reduces operational toil and tightens evidence quality; it does not make SOC 2 cheaper or faster at the audit-firm level.