SOC 2

SOC 2 is an AICPA attestation report in which an independent auditor measures a service organisation's controls against the Trust Services Criteria. It is not a certificate but an examination report: a US-shaped proof of trust that complements the process-oriented claim of ISO 27001 rather than replacing it.

Anyone buying a cloud platform, a SaaS application or a hosting service wants to know whether the provider has its customer and operational data under control. In the US, SOC 2 has become the common form of evidence for this. The American Institute of Certified Public Accountants (AICPA) created the framework, and providers routinely present the report as soon as a customer asks about the security of their services. This page describes what SOC 2 attests to, why it is a report and not a certificate, and how it relates to ISO 27001.

A report, not a certificate

The most important point first, because it is the one most often confused: SOC 2 is an attestation, not a certificate. With ISO 27001, an accredited certification body audits the management system and, on success, issues a certificate confirming conformity. With SOC 2, an independent auditor (in the US a Certified Public Accountant, CPA) performs an examination of controls and issues a written opinion on it. The outcome is a detailed report, not a seal.

A practical difference follows from this. An ISO 27001 certificate is a short document that can be shown. A SOC 2 report is a confidential document, often several dozen pages long, containing the provider's system description, the controls tested, the examination methodology and the auditor's opinion. Providers typically share it with customers and prospects only under a confidentiality agreement. The statement lies not in a stamp but in the content of the report.

The five Trust Services Criteria

The substantive basis of SOC 2 is the AICPA's Trust Services Criteria (TSC), organised into five categories. Only the first is mandatory; the organisation selects the remaining four according to their relevance for its service:

Security. Protection of systems and data against unauthorised access. This category, also referred to as the common criteria, is the one mandatory basis of every SOC 2 report.
Availability. Is the system available and operational as committed?
Processing integrity. Is processing complete, valid, accurate and timely?
Confidentiality. Is information classified as confidential protected accordingly?
Privacy. Is personal information collected, used and deleted in line with the committed privacy practices?

Because the choice of categories rests with the provider, the mere existence of a SOC 2 report says nothing about its scope. Only a look at the scope shows which criteria were actually examined. A report covering security alone makes no statement about availability or privacy. This is exactly where careful reading pays off, the kind the technical view on Compliance also demands.

Type I versus Type II

SOC 2 has two report types that differ not in scope but in the point of examination:

Type I assesses whether the controls are suitably designed at a specific date. It answers the question: are the right controls in place and sensibly designed?
Type II additionally assesses whether those controls also operated effectively over a period of time. The auditor tests the controls over an observation period that typically spans several months up to a year. It answers the harder question: did the controls actually work in day-to-day operation?

For procurement the difference matters. A Type I report is a snapshot of the design, often a provider's first step. A Type II report evidences lived effectiveness over time and therefore carries the greater assurance value. Anyone requiring a SOC 2 proof should specify which type is meant.

flowchart TD
    A["SOC 2 examination<br/>by an independent CPA"] --> B["Define the scope<br/>which of the five criteria"]
    B --> C{"Point of examination?"}
    C -- "Specific date" --> D["Type I<br/>design of controls"]
    C -- "Period" --> E["Type II<br/>effectiveness over months"]
    D --> F["Examination report<br/>not a certificate"]
    E --> F

The flow shows the two forks of every SOC 2 examination: first the organisation defines the scope, that is which of the five criteria are examined, then the point of examination decides between Type I (design at a date) and Type II (effectiveness over a period). Both paths lead to a detailed examination report, not to a seal.

SOC 2 and ISO 27001 compared

SOC 2 and ISO 27001 pursue the same goal, demonstrable information security, by different routes. They do not exclude each other but overlap in large part:

Origin and reach. ISO 27001 is an international standard and in the European area the usual expectation. SOC 2 is US-shaped and the common form of evidence in the North American market and among cloud and SaaS providers.
Form of result. ISO 27001 leads to a certificate from an accredited body. SOC 2 leads to an attestation report from an auditor.
Object of examination. ISO 27001 audits a complete information security management system (ISMS) including the risk process and continual improvement. SOC 2 examines specific controls against the selected Trust Services Criteria.
Validity. An ISO certificate is valid for three years with surveillance audits. A SOC 2 Type II report covers a past period and is therefore usually renewed annually.

For Swiss organisations working with US partners or international customers, both may be required. Anyone already running an ISMS to ISO 27001 has already implemented a large share of the controls needed for SOC 2; the routes complement each other. Which proof fits which market is a question of provider steering.

What an examination report proves and what it does not

SOC 2 is not data protection law and replaces no statutory obligation. A SOC 2 privacy category examines whether a provider keeps its own committed privacy practices, not whether it meets the revised Swiss Data Protection Act (revFADP) or the GDPR. A SOC 2 report is therefore a useful indicator of a provider's maturity, but not proof of the legal conformity of a specific data processing.

There is also the sovereignty question. A US provider with a flawless SOC 2 Type II report may be technically excellently controlled and still fall under the US Cloud Act, which enables legal access to the data. The two layers, technical control maturity and legal access, must be assessed separately. A proof of trust about controls does not resolve the question of data sovereignty. Keeping this distinction clean is part of the evidence-and-supply-chain work.

What to watch for when reading one

Check the type. Type I is a snapshot, Type II evidences effectiveness over time. Only Type II carries the full assurance value.
Check the scope. Which of the five criteria does the report cover, and which systems? Security alone is not availability plus privacy.
Check the observation period. A Type II report over a very short period says less than one over twelve months.
Check the exceptions. The auditor documents the deviations found (exceptions). A report with no exceptions at all is not automatically the better one; what matters is how the provider deals with the documented deviations.
Check the date and the auditor. The report covers a past period. A two-year-old report says little about today's operation.

References

AICPA and CIMA Trust Services Criteria, 2017 with revised points of focus 2022. The five categories security, availability, processing integrity, confidentiality and privacy that underlie a SOC 2 examination. (30.09.2023). www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022
AICPA and CIMA System and Organization Controls (SOC) Suite of Services. The overview of the SOC report family (SOC 1, SOC 2, SOC 3) as examination services provided by auditors. (continuously updated). www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services

Ask AI

These links open external AI services, the conversation and its content are sent to their providers.