SOC 2System and Organization Controls 2

A SOC 2 report is an independent CPA firm's opinion on a service organisation's controls relevant to one or more of the AICPA Trust Services Criteria. Reports are restricted-use (intended for the service organisation's customers, regulators and their auditors — not the general public, which is SOC 3). The criteria framework was last revised in 2022; the underlying standard is AICPA SSAE 18.

• Security (Common Criteria, mandatory in every SOC 2) — protection against unauthorised access, disclosure or system damage. 9 Common Criteria categories (CC1–CC9) cover control environment, communication, risk assessment, monitoring, control activities, logical and physical access, system operations, change management and risk mitigation.
• Availability — system available for operation and use as committed (typically against an SLA).
• Processing Integrity — system processing is complete, valid, accurate, timely and authorised.
• Confidentiality — information designated as confidential is protected per its commitments.
• Privacy — personal information is collected, used, retained, disclosed and disposed of per the entity's privacy notice and AICPA Generally Accepted Privacy Principles.

Most SaaS reports cover Security + Availability + Confidentiality. Processing Integrity is added for financial / order-processing systems. Privacy is added where personal data is core (HR platforms, ad-tech).

• Type 1 — opinion on the design of controls at a single point in time. Useful as a first report; rarely accepted as final evidence by enterprise procurement.
• Type 2 — opinion on the design AND operating effectiveness over an audit period (typically 6 or 12 months). The standard enterprise procurement ask.

A typical journey is Type 1 in year 1 (proving the controls exist), Type 2 with a 6-month observation window in year 1 H2, then 12-month Type 2 reports annually thereafter. Bridge letters cover the gap between the last reported period and the customer's audit date.

The 9 Common Criteria categories that every SOC 2 covers (regardless of which additional criteria are in scope):

• CC1 — Control Environment (board / management oversight, organisational structure, ethics, integrity).
• CC2 — Communication and Information (internal + external communications, policies, system descriptions).
• CC3 — Risk Assessment (objectives, risk identification, fraud risk, change risk).
• CC4 — Monitoring Activities (ongoing + separate evaluations, communication of deficiencies).
• CC5 — Control Activities (selection + development of controls, technology-related controls, policy deployment).
• CC6 — Logical and Physical Access (the security-control core — identity, authentication, authorisation, encryption, network security, physical access).
• CC7 — System Operations (vulnerability + threat management, incident detection + response, recovery).
• CC8 — Change Management (authorised + tested + documented changes).
• CC9 — Risk Mitigation (vendor management, business disruption response).

Both are credible enterprise-security regimes. They differ in shape:

• SOC 2 — US-centric attestation report; criteria-based; CPA opinion; renewed annually; restricted-use.
• ISO 27001 — international certification; ISMS-based; issued by an accredited certification body; 3-year cycle with surveillance audits; certificate is publicly shareable.
• Significant control overlap; mature programmes maintain both and use a single control mapping (Common Criteria + Annex A) to avoid duplication.

Customers in regulated manufacturing frequently confuse SOC 2 and Part 11. They are independent:

• SOC 2 — security + availability + confidentiality of the SaaS environment. Says nothing about electronic-record / electronic-signature legal equivalence.
• Part 11 — FDA criteria for trustworthy electronic records and signatures used to satisfy a predicate FDA regulation (e.g. 21 CFR 211, 820). Says nothing about the cloud-platform security posture.
• Both are typically needed: a SOC 2 Type 2 report for the platform plus a validation pack (URS / IQ / OQ / PQ) demonstrating Part 11 control coverage at the customer tenant.

The auditor's opinion is bounded by the system description — the in-scope services, infrastructure, software, data, people and processes. Customers should read the system description first; the opinion only covers what is described. Important boundaries:

• Sub-service organisations — the SaaS's own cloud providers (e.g. AWS, GCP, Cloudflare). Reports use either the carve-out method (sub-service excluded; customer must obtain the sub-service's SOC report separately) or the inclusive method (sub-service included).
• Complementary user-entity controls (CUECs) — the controls the SaaS customer must implement on their side for the SOC 2 controls to be effective end-to-end. Reading the CUEC list is mandatory; many customers skip it and inherit gaps.
• Exceptions — any control failures observed by the auditor are listed and the auditor opines on whether they affect the overall opinion.

• Vendor treats Type 1 as a substitute for Type 2 — most enterprise procurement teams require Type 2.
• Vendor scope description omits the actual product the customer is buying.
• Customer reads only the opinion paragraph, not the system description, exceptions or CUECs.
• SOC 2 cited as a Part 11 substitute, or vice versa — they cover different control domains.
• Bridge letter not provided for the gap between the last audit period end and the current customer review date.
• Sub-service carve-out not reconciled (customer assumes AWS controls are in scope when they are explicitly excluded).
• Annual renewal lapses without a 12-month-continuous observation window — gap erodes Type 2 credibility.