SOC 2 - Overview

SOC 2 is an attestation reporting framework under the AICPA’s “System and Organization Controls” suite that evaluates controls at a service organization relevant to Security, Availability, Processing Integrity, Confidentiality, and Privacy (the Trust Services Criteria, or TSC). A SOC 2 report contains an independent CPA’s opinion on whether management’s description of the system is fairly presented and whether controls are suitably designed (Type 1) and, for Type 2, operating effectively over a defined review period. SOC 2 has become the de facto assurance standard for cloud and SaaS providers, used by customers and regulators to gain assurance over how a service organization protects and processes data, and it maps heavily onto ISO 27001, NIST CSF, HIPAA, PCI DSS, and other security/privacy frameworks.

SOC 2 - What It Is

SOC 2 is not a law or control catalogue; it is an attestation engagement performed by an independent CPA firm against criteria defined by the AICPA’s Trust Services Criteria (TSC). The TSC, set out in TSP Section 100, provide principles and detailed criteria for the five categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy, with Security (the “Common Criteria”) mandatory in every SOC 2 examination. A SOC 2 report includes: management’s description of the system, the auditor’s opinion, a description of the criteria and controls, and, for Type 2, detailed testing procedures and results including any exceptions identified.

There are two types of SOC 2 reports.

SOC 2 Type 1 — Opinion on the fairness of the system description and the suitability of design of controls as of a point in time.
SOC 2 Type 2 — Opinion on the fairness of the description, suitability of design, and operating effectiveness of controls over a period (typically 3–12 months).

SOC 2 is scoped at the level of a “system” (infrastructure, software, people, procedures, and data) that supports the services described, and management must define the system boundaries and which TSC categories are in scope.

SOC 2 - Who It Applies To

SOC 2 applies to service organizations whose systems process or store data on behalf of customers and where those customers require assurance over security, availability, processing integrity, confidentiality, or privacy. Typical adopters include:

Cloud and SaaS providers (IaaS, PaaS, SaaS), data centers, and managed service providers.
Fintech, payments, and financial services technology vendors providing hosted services to regulated institutions.
Healthcare, HR, ERP, and other enterprise software providers offering multi-tenant or hosted solutions where customers rely on vendor controls.

SOC 2 is voluntary in the sense that no statute mandates it, but market forces make it effectively mandatory in many B2B contexts: customers and procurement teams often require a recent SOC 2 Type 2 report as a condition of doing business. SOC 2 does not apply to internal IT of non-service organizations (those are better served by NIST CSF, ISO 27001, or SOC for Cybersecurity), but those organizations still rely on SOC 2 reports from their vendors as part of third‑party risk management.

SOC 2 - What It Requires - Trust Services Criteria

SOC 2 requirements are expressed via the AICPA Trust Services Criteria (TSC)—Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security criteria (Common Criteria) are required for all SOC 2 reports; the other four categories may be added depending on services and customer needs.

Security (Common Criteria)

Security criteria address protection of systems and information against unauthorized access, disclosure, or damage. They include requirements around:

Logical and physical access controls, including authentication, authorization, and least privilege.
Change management, configuration management, and protection against malicious software.
Network and system security, including boundaries, firewalls, and secure transmission of information.
Risk assessments, security policies, and monitoring of security events.

Security criteria form the baseline; if you fail Security, you fail the exam even if other categories are in scope.

Availability

Availability criteria address whether systems are available for operation and use as committed or agreed. They cover:

Availability-related performance monitoring and capacity management.
Backup, disaster recovery, and business continuity planning for uptime commitments.
Incident and problem management affecting service availability.

Availability is often in scope for infrastructure, cloud, and uptime-sensitive SaaS services.

Processing Integrity

Processing Integrity criteria address whether system processing is complete, valid, accurate, timely, and authorized. They include:

Input, processing, and output controls to ensure correct handling of data.
Data validation, error handling, and reconciliation mechanisms.
Change controls affecting processing logic.

Processing Integrity is critical for services where transactional correctness is core (e.g., billing, financial processing, analytics).

Confidentiality

Confidentiality criteria address protection of information designated as confidential, whether or not it is personal data. They include:

Classification of confidential information and associated handling requirements.
Encryption, key management, and restricted access to confidential data.
Secure transmission, storage, and disposal of confidential information.

Confidentiality often overlaps with Security but focuses on information explicitly identified as confidential in contracts or policies.

Privacy

Privacy criteria address personal information collection, use, retention, disclosure, and disposal in conformity with the entity’s privacy notice and criteria based on generally accepted privacy principles. They include:

Notice and consent for personal data processing.
Choice, access, and correction for data subjects.
Use, retention, disposal, and disclosure limitations consistent with stated commitments and laws.

Privacy is particularly relevant for consumer-facing services and services that process sensitive personal information, and often must be harmonized with GDPR, CCPA, and sectoral privacy laws.

SOC 2 - What It Requires - Evidence, Testing & Report Types

SOC 2 is fundamentally about controls plus evidence over time.

Type 1 vs Type 2

Type 1 reports opine on whether the system description is fairly stated and controls are suitably designed at a point in time.
Type 2 reports additionally opine on operating effectiveness of controls over a specified period (usually 3–12 months), requiring evidence that controls actually operated as designed during that period.

Customers usually prefer Type 2, as it provides stronger assurance that controls are not just documented but consistently executed.

Evidence and Testing

Auditors select a sample of control instances (e.g., access changes, change tickets, backups, incident records) within the review period and test:

Existence of documented policies, procedures, and system configurations.
Operating evidence (tickets, logs, approvals, screenshots, configurations) that controls ran as required.
Completeness and accuracy of samples and whether exceptions exist.

Reports include detailed test descriptions and results in the Type 2 control testing section, which is often the most scrutinised part by customer security teams. Management is responsible for defining the system boundaries, in-scope TSC categories, and control set; auditors assess those controls against the TSC using professional standards.

SOC 2 - Governance Implications

SOC 2 forces organisations to formalise governance over security and privacy controls, because auditors must see clear ownership, policies, and evidence chains.

Governance implications include:

Clear assignment of responsibility for each control (control owners, approvers, reviewers) across security, IT, engineering, HR, and operations.
Formal policies and procedures covering security, availability, processing integrity, confidentiality, and privacy, aligned with commitments to customers.
Regular risk assessments and management review of control performance, exceptions, and remediation as part of a continuous improvement loop.

For AI systems and data-heavy services, SOC 2 becomes part of the assurance layer: customers will expect that AI-related services inherit the same access control, logging, change management, incident response, and privacy controls demonstrated in SOC 2. SOC 2 therefore pairs naturally with ISO 27001 (management system), NIST CSF (risk framework), and NIST AI RMF (AI-specific risk) as part of a broader governance stack.

SOC 2 - Enforcement Penalties

SOC 2 itself is not a regulatory regime and does not impose statutory fines or administrative penalties; it is a voluntary assurance report. However, failure to achieve or maintain SOC 2 can have significant market and contractual consequences:

Loss of deals or churn where customers require a current SOC 2 Type 2; inability to pass vendor security assessments.
Contractual non-compliance if agreements require SOC 2 reporting or adherence to control standards.
Increased scrutiny from regulators and auditors in regulated sectors (financial services, healthcare) where SOC 2 is used as evidence of third-party control effectiveness.

Within a SOC 2 engagement, material control failures and exceptions are disclosed in the report, which can damage trust and trigger remediation commitments; in extreme cases, an auditor can issue a qualified or adverse opinion. Separately, underlying failures (e.g., security breaches, privacy violations) can trigger regulatory penalties under sectoral laws (GDPR, HIPAA, GLBA, etc.), even though SOC 2 itself is not enforced by law.

SOC 2 - Intersection With Other Frameworks

SOC 2 overlaps heavily with other security and privacy frameworks, making mapping a key strategy.

ISO 27001

Studies and practitioner mappings show that 80–96% of SOC 2 criteria align with ISO 27001:2022 Annex A controls. Shared themes include:

Information security policies and governance.
Access control, cryptography, physical security, and operations security.
Incident management, logging/monitoring, and business continuity.
Risk assessment and continual improvement.

Many organisations implement a single control set and map it to both SOC 2 and ISO 27001, using ISO for certification and SOC 2 for customer-facing attestation.

NIST CSF & NIST 800‑53

SOC 2 controls map closely to NIST CSF Functions (Protect, Detect, Respond, Recover) and to NIST SP 800‑53 security and privacy controls, particularly for security and availability. Organisations with NIST-based programs can leverage existing controls and evidence for SOC 2, and vice versa.

HIPAA, PCI DSS, GDPR

SOC 2 intersects with sectoral frameworks:

HIPAA — Administrative, physical, and technical safeguards for PHI overlap with SOC 2 Security, Confidentiality, and Privacy.
PCI DSS — Access control, encryption, logging, and vulnerability management requirements overlap with SOC 2 Security, Availability, and Confidentiality; mapping can reduce duplication for payment handlers.
GDPR/CCPA — SOC 2 Privacy criteria support (but do not fully satisfy) data protection obligations; SOC 2 evidence can help demonstrate technical and organisational measures.

AI Governance Stack

In an AI governance stack, SOC 2 provides the operational controls and assurance layer for systems hosting or exposing AI services:

Security/Availability/Confidentiality align with NIST CSF and ISO 27001 for AI infrastructure.
Evidence from SOC 2 Type 2 (logs, access reviews, incident records) supports defensibility for AI systems governed under NIST AI RMF and ISO 42001.

SOC 2 - Recent Updates

The underlying Trust Services Criteria were significantly updated in 2017 TSP Section 100, with revised points of focus issued in 2022. These updates modernised criteria to align with COSO 2013, address emerging risks (e.g., cybersecurity, vendor risk), and clarify points of focus auditors use when evaluating controls.

AICPA has also published 2018 SOC 2 Description Criteria (with later implementation guidance updates) to standardise how management describes systems in SOC 2 reports. Recent industry trends include:

Strong preference for SOC 2 Type 2 over Type 1 for higher assurance of operating effectiveness.
Rapid growth in demand from cloud and SaaS customers, especially in accounting/ERP, fintech, and healthcare sectors.
Increased emphasis on multi-framework mapping, using SOC 2 as part of a consolidated control set that also satisfies ISO 27001, NIST CSF, HIPAA, PCI DSS, and privacy regulations.

These developments reinforce SOC 2’s role as a central, market-driven assurance framework for service organisations’ security and privacy posture.

SOC 2 — AICPA Service Organization Controls for Trust Services Criteria