Frameworks /  US

SOC 2

SOC 2 is a US attestation report, issued by an independent licensed CPA firm, describing a service organisation's controls against the AICPA Trust Services Criteria. It is a report on your controls, not a certification.

What it requires

SOC 2 is built on five Trust Services Criteria categories: Security (the "common criteria", CC1-CC9, mandatory in every report), plus optionally Availability, Confidentiality, Processing Integrity and Privacy. The Security common criteria are structured on the COSO internal control framework and cover control environment, communication, risk assessment, monitoring, control activities, logical and physical access, system operations, change management and risk mitigation. A Type I report assesses whether controls are suitably designed at a single point in time; a Type II report assesses whether they operated effectively across a review period: commonly 3 months for a first report and 12 months thereafter. The auditor samples evidence across the period, so controls that were not performed during the window become exceptions in the report. There is no pass/fail certificate: the deliverable is a report containing the auditor's opinion, the description of the system, and any exceptions found.

SOC 2 applies to service organisations (typically SaaS, hosting, data-processing and BPO providers) whose customers depend on their controls. It is not required by any law. The trigger is commercial: a US enterprise customer, or a US-headquartered acquirer, asks for the report and the deal stalls without it. Israeli B2B SaaS companies selling into the United States hit this almost universally at the point they move from SMB customers to enterprise.

The controls people actually fail

  • Controls were designed but not performed during the observation window: the quarterly access review was skipped in Q2, so the Type II report carries an exception for the whole period.
  • Offboarding is not evidenced: employees left, access was eventually removed, but there is no ticket, timestamp or approval showing it happened within the timeframe the policy promises.
  • Change management is bypassed for "urgent" production changes: deploys with no approval, no ticket and no linkage between the code change and the reviewer.
  • Vendor management exists on paper only: no current vendor list, no evidence that subservice organisations' own SOC 2 reports were reviewed, and no assessment of complementary user entity controls.
  • Security awareness training is delivered but completion is not tracked, so the auditor cannot verify that all in-scope personnel completed it.
  • The system description overstates reality: it describes a monitoring or alerting capability that exists in the diagram but that no one actually responds to.
SOC 2 Type II is the framework most explicitly designed to catch drift, and it still misses it, because it looks backwards, once a year, at a sample. The exception in your next report has usually already happened; you just do not know about it yet. The control that quietly stopped being performed in March shows up in an auditor's finding in December, in a document your biggest customer reads.

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

A Type I report gives an opinion on whether your controls are suitably designed as of a single date. A Type II report gives an opinion on whether those controls also operated effectively throughout a defined period: typically 3 to 12 months. Type I can be produced quickly and is sometimes accepted as a stopgap to unblock a deal, but most enterprise buyers ultimately require Type II, because a design-only opinion says nothing about whether anyone actually did the work.

How long does a SOC 2 audit take?

Readiness work for a mid-market company typically takes 2 to 4 months. After that, a Type I can be issued within weeks. A Type II additionally requires an observation period (commonly 3 months for a first report, then 12-month periods on an annual cadence) during which the auditor collects evidence, followed by several weeks of fieldwork and report drafting. The observation period is the immovable part: you cannot compress time in which the controls must be seen operating.

Is SOC 2 a certification?

No. SOC 2 is an attestation engagement performed under AICPA standards, and the deliverable is a report containing an independent CPA's opinion, the description of your system, the controls tested, the tests performed, and any exceptions. There is no certificate, no accreditation body and no pass mark. Any vendor claiming to be "SOC 2 certified" is using the term loosely: what they have (or do not have) is a report, and you should ask to read it, including the exceptions section.

Which Trust Services Criteria should we include in scope?

Security (the common criteria) is mandatory in every SOC 2 report. Availability, Confidentiality, Processing Integrity and Privacy are optional and should be added only where your customer contracts or SLAs actually depend on them: Availability if you commit to uptime, Confidentiality if you handle customer data under confidentiality obligations, Processing Integrity if you perform transactional or computational processing on customers' behalf, Privacy if you handle personal information as a controller-like party. Each added category expands the audit scope, cost and evidence burden, so add them because a customer asked, not for completeness.

Find out how far you have drifted.

A free exposure assessment. We connect to what you already have, and show you what your dashboards are not showing you.

No obligation. Results in 10 business days.