SOC 2

SOC 2 is a US attestation report, produced by a licensed CPA firm, that has become the default way a SaaS company proves its security to prospective customers. It is an auditor’s opinion, delivered as a report the customer’s own security team reads — not a certification, and not a government regime. Understanding what that report does and does not assert is most of what matters.

The Trust Services Criteria

SOC 2 is built on the Trust Services Criteria (TSC), five categories:

• Security (the “common criteria”) — always in scope. This is the baseline every SOC 2 covers.
• Availability, Confidentiality, Processing Integrity, and Privacy — optional, included only if relevant to the service and the commitments made to customers.

Most reports cover Security plus one or two of the others. Scoping matters: a SOC 2 that covers only Security is legitimate, but a customer relying on availability commitments needs to check that Availability was actually in scope rather than assume the report covers it.

Type I versus Type II: the distinction that trips people up

This is the single most important thing to get right about SOC 2:

• Type I attests that the controls are suitably designed at a single point in time. It says the right controls exist on paper as of a given date.
• Type II attests that the controls operated effectively over a period — typically 3 to 12 months. The auditor samples evidence across the window to confirm the control actually ran, repeatedly, the whole time.

Type II is the one customers actually want, because designed-but-not-operating is where most real control failures live. A control that was configured correctly on the audit date and silently broke the next week passes a Type I and fails the reality it was meant to describe. This is the same design-versus-operation gap that ISO 27001 surveillance audits are built to catch — SOC 2 just makes it the explicit axis of the report type.

Reading the report

A SOC 2 report is a document, not a pass/fail badge, and it has a predictable structure:

• The auditor’s opinion — unqualified (clean), qualified (exceptions noted), or worse. Read this first.
• Management’s assertion — the organization’s own statement of what it does.
• The system description — what is in scope: which service, which infrastructure, which controls.
• The control matrix — each control, the tests the auditor performed, and the results, including any exceptions. A report with noted exceptions is not a failed report; a mature reader looks at what the exceptions were and whether they matter to their use of the service.

Because the report covers a past window, a bridge letter (or gap letter) is the customary way an organization covers the time between the end of the audit period and the customer’s review date.

SOC 1, 2 and 3

Three reports get confused:

• SOC 1 is about financial-reporting controls (relevant when your service affects a customer’s financial statements), not security.
• SOC 2 is the security/availability/confidentiality report described here, and is restricted-use — shared under NDA with customers and prospects.
• SOC 3 is a public, seal-style summary of a SOC 2 with the detail removed, meant for a website rather than a security review.

Where this connects

SOC 2 is the US counterpart to ISO 27001, and the two are the most common mapping pair a growing company maintains together. Its evidence is generated by the rest of the site done deliberately: change-management and vulnerability controls are AppSec, and the logging and monitoring criteria are detection — collected as evidence rather than assembled by hand, which is the GRC engineering move. Its place among the frameworks is in Common Frameworks.