What does a SOC 2 actually verify?

Vendor diligence conversations reliably reach the moment where a SOC 2 report is produced the way a passport is: as if the document ends the inquiry. It begins one, and the beginning is knowing what the artifact is.

A SOC 2 is an auditor's attestation, under the AICPA's trust services criteria, that the controls a company chose to describe operated as described during a period. Read the italics twice. The vendor defines the system boundary and selects the controls; the auditor checks that the described machine ran as described. Nothing in the mechanism asks whether the described machine is the right machine, whether the boundary includes the parts you depend on, or whether the controls would impress your own security team for an afternoon.

So the report answers exactly one question: does this organization operate its own stated processes with discipline? That is genuinely worth knowing. Discipline correlates with everything. But the questions your risk actually turns on live in the details the summary page omits, which is why the reading order matters: the system description first, to check that the service you use is even in scope; the exceptions section second, because auditors record what failed and vendors do not volunteer it; the complementary user entity controls third, which is the list of things the vendor assumes you are doing, and which nobody in your organization has usually read.

Type I versus Type II is the other unread distinction: a point-in-time design review versus controls observed operating over months. A vendor offering a Type I for a mature product has answered a question you did not ask, quietly.

The five-minute protocol, then: scope page, exceptions, user-entity controls, report period, and one follow-up question in writing about anything your workload depends on that the boundary excludes. A vendor who answers plainly has told you something no badge can. A vendor who re-sends the PDF has also told you something.