SOC 2

What is SOC 2?

SOC 2 (System and Organisation Controls 2) is an auditing framework developed by the American Institute of Certified Public Accountants (AICPA) that evaluates whether a service organisation has controls in place to protect the security, availability, processing integrity, confidentiality, and privacy of customer data. It produces a third-party auditor's report that customers can use to assess vendor risk.

SOC 2 is not a certification. There's no certificate to hang on the wall and no central registry of SOC 2-compliant organisations. It's an audit report and a document produced by a licensed CPA firm stating that it examined an organisation's systems and controls, found that those controls were suitably designed, and in the case of a Type II report, that those controls operated effectively over a defined period.

That distinction matters operationally. Achieving SOC 2 isn't about meeting a fixed checklist. It's about designing controls appropriate to your systems and risks, documenting them rigorously, and demonstrating through evidence that they work.

The five Trust Service Criteria

SOC 2 is built around five Trust Service Criteria (TSC). Only the Security category is required for every SOC 2 engagement. The others are included based on what's relevant to the organisation's services and what customers care about.

Security (CC) — the Common Criteria is the mandatory foundation. It covers the controls protecting systems against unauthorised access, both logical and physical: access controls, authentication, monitoring, incident response, change management, risk assessment, and vendor management. Every SOC 2 engagement includes Security. An engagement covering only Security is the most common starting point.

Availability covers whether systems are available for operation and use as committed or agreed. Uptime monitoring, capacity management, disaster recovery, backup procedures, and incident management are the primary control areas. Relevant for organisations whose customers' operations depend on service availability guarantees.

Processing Integrity covers whether system processing is complete, valid, accurate, timely, and authorised. Relevant for organisations processing transactions or data where completeness and accuracy matter to customers — payment processors, data analytics firms, payroll providers.

Confidentiality covers whether information designated as confidential is protected as committed or agreed. Encryption, access controls, and data handling procedures for customer confidential information are the primary areas. More specific than Security's broad access control requirements, focusing on what happens to information once accessed.

Privacy covers whether personal information is collected, used, retained, disclosed, and disposed of in conformity with the organisation's privacy notice and with the AICPA's Generally Accepted Privacy Principles. Relevant for organisations processing significant volumes of personal data.

Most organisations starting a SOC 2 programme begin with Security only. Adding Availability and Confidentiality is common for SaaS companies whose enterprise customers are most focused on those categories. Privacy is added when the organisation's data processing activities make it relevant to customer assessments.

SOC 2 Type I vs SOC 2 Type II

This is the most frequently misunderstood distinction in SOC 2, and it matters significantly for what a report actually tells customers about an organisation's security programme.

SOC 2 Type I reports on whether an organisation's controls are suitably designed to meet the Trust Service Criteria as of a specific point in time. The auditor evaluates the design of the controls — are the right controls documented and in place? — but does not test whether those controls actually operated effectively over a period.

Type I is a snapshot. It answers: on this date, did the organisation have controls designed appropriately? A Type I report can be achieved relatively quickly once controls are designed and documented, because it requires no observation period.

SOC 2 Type II reports on whether an organisation's controls were suitably designed and operated effectively over a defined period — typically six to twelve months. The auditor samples control operations across the observation period: reviewing access logs, testing whether user access reviews were performed, verifying that change management procedures were followed, confirming that security monitoring was operating continuously.

Type II is a period review. It answers: over this period, did the organisation's controls actually work? Type II is what most enterprise customers require, because it demonstrates operational effectiveness, not just design intent. A vendor can design excellent controls and get a Type I report in three months. Getting a Type II report requires running those controls effectively for at least six months while collecting the evidence to prove it.

That's the practical operational difference. Type I requires building and documenting controls. Type II requires running them consistently for an extended period and producing evidence that the auditor can sample. The evidence collection burden is where most SOC 2 programmes underperform.

What the Security Trust Service Criteria actually require

The Security Common Criteria map to nine control categories. For security engineers building a SOC 2 programme, understanding what the auditor will examine in each category is more useful than the abstract criteria language.

CC1 — Control Environment

Board and management commitment to security, organisational structure, policies, accountability, and values. The auditor looks for documented security policies, a designated security function, and evidence that leadership takes security seriously.

CC2 — Communication and Information

Internal and external communication about security responsibilities, relevant controls, and obligations. Security policies must be communicated to employees. Customers must have access to information about your security programme.

CC3 — Risk Assessment

Regular identification and analysis of risks to achieving security objectives. Annual risk assessments with documented findings and treatment decisions are the baseline. The auditor looks for evidence that risk assessment happened and informed control design.

CC4 — Monitoring Activities

Monitoring of controls to verify they're operating effectively, and evaluation of whether deviations from standards are occurring. Security monitoring, vulnerability management, and internal audit activities are the primary evidence points.

CC5 — Control Activities

Specific controls deployed to mitigate risks: access controls, change management, configuration management, incident response procedures. The auditor samples evidence of these controls operating during the audit period.

CC6 — Logical and Physical Access Controls

This is typically the heaviest section of a SOC 2 Type II audit. Unique user IDs, MFA, access provisioning and deprovisioning processes, access reviews, privileged access management, physical access controls. The auditor tests: were access reviews performed? Were terminated employees' access revoked promptly? Were access provisioning requests approved?

CC7 — System Operations

Monitoring of system components, detection of security events, incident response, and recovery procedures. Logging, alerting, incident response records, and evidence that security events were investigated are all sampled.

CC8 — Change Management

Controls over changes to infrastructure, software, and processes. Change request approvals, testing procedures, and rollback capabilities are examined.

CC9 — Risk Mitigation

Risk transfer, acceptance, and vendor risk management. Vendor assessments, business continuity planning, and insurance are the primary areas.

The evidence problem

Most organisations that struggle with SOC 2 Type II don't struggle because their controls are inadequate. They struggle because they didn't collect sufficient evidence that their controls operated during the audit period.

The auditor selects a sample of instances for each control typically 25 to 60 depending on the control frequency and audit firm methodology. For a quarterly access review, the auditor might sample all four quarters. For a daily log review, they might sample 25 days. For each sampled instance, they need to see the evidence that the control was performed: the access review report, the log review record, the change request approval, the security alert investigation record.

If the evidence doesn't exist for a sampled instance, the control has an exception which appears in the audit report. A small number of exceptions with good explanations typically doesn't prevent an unqualified opinion. Pervasive exceptions, or exceptions in high-risk control areas, result in a qualified or adverse opinion that customers notice.

Building evidence-generating processes from the start controls that produce documented outputs as a natural byproduct of normal operations rather than requiring manual evidence assembly before each audit is what separates organisations that maintain SOC 2 Type II sustainably from those that treat each renewal as a fire drill.

That's the operational argument for continuous compliance monitoring: immutable audit logs that exist before the auditor asks for them, access review reports generated on schedule, security monitoring records maintained automatically. The evidence is available because the controls produce it continuously, not because someone assembled it in the week before the audit.

SOC 2 vs ISO 27001: the common comparison

Enterprise customers from European organisations and global enterprises often ask for ISO 27001 in addition to or instead of SOC 2. Understanding the difference helps organisations decide which to prioritise.

SOC 2 is a US-origin framework, most commonly required by US-based enterprise customers. It's a report produced by an auditor after examining specific controls. Different organisations can have SOC 2 reports that cover different trust criteria and use different control implementations there's significant flexibility in how controls are designed.

ISO 27001 is an international standard that specifies requirements for an information security management system (ISMS). Certification is achieved by demonstrating that the ISMS meets the standard's requirements, verified by an accredited certification body. It's more prescriptive about the management system requirements, less flexible about what constitutes an acceptable control framework, and recognised globally rather than primarily in North American enterprise procurement.

Many organisations achieve both, particularly those selling to enterprise customers across North America and Europe. The control frameworks overlap substantially, and building for both from the start is more efficient than treating them sequentially.

Frequently asked questions

What is SOC 2?

SOC 2 is an auditing framework developed by the AICPA that evaluates whether a service organisation has effective controls to protect customer data across five Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. It produces an auditor's report not a certification that customers use to assess vendor security.

What is the difference between SOC 2 Type I and Type II?

\A SOC 2 Type I report evaluates whether controls are suitably designed as of a specific point in time. A SOC 2 Type II report evaluates whether those controls were suitably designed and operated effectively over an observation period of six to twelve months. Enterprise customers typically require Type II because it demonstrates operational effectiveness, not just design intent.

What does SOC 2 cover?

SOC 2 covers five Trust Service Criteria. Security (the Common Criteria) is mandatory and covers access controls, monitoring, incident response, change management, and risk assessment. Availability, Processing Integrity, Confidentiality, and Privacy are optional additions based on what's relevant to the organisation's services and customer expectations.

How long does SOC 2 Type II take?

SOC 2 Type II requires a minimum observation period — typically six months, though twelve months is common for the annual audit cycle. Before the observation period begins, organisations need time to design and implement their controls. Total timeline from starting a SOC 2 programme to receiving a Type II report is typically nine to eighteen months.

Is SOC 2 a legal requirement?

SOC 2 is not legally mandated by government regulation. It's contractually required by many enterprise customers as a condition of their vendor security programmes, and some regulated industries treat SOC 2 Type II as a threshold requirement for vendor selection. The requirement is commercial and contractual rather than regulatory.