A SOC 2 report is evidence, not a certificate

May 6, 2026 · 5 min read · HQT

A vendor responding to a solicitation will often attach a SOC 2 report or offer one under a non-disclosure agreement. It is long, formatted like an accounting document, and written for people who evaluate controls for a living. Procurement and IT staff are not that reader and do not need to become one. A small part of it should carry most of the weight in the decision.

SOC 2 is a reporting framework published by the AICPA. An independent CPA firm examines a service organization against the Trust Services Criteria and issues an opinion. Security, the category matching the common criteria, is in scope in every SOC 2 examination. Availability, confidentiality, processing integrity, and privacy are included only if the vendor asked for them. It is not a certification and not a pass or fail badge. It is a professional opinion plus the evidence behind it, and the evidence is the useful part.

Type 1, Type 2, and the neighbors

A Type 1 report addresses the design of controls as of a specified date. A Type 2 report addresses design and operating effectiveness over a period, which means the auditor tested whether the controls ran. Type 2 is the report to ask for. A Type 1 is a fair answer from a company too young to have completed an observation period, but it is not equivalent evidence. Observation periods vary, so read the exact start and end dates.

Two neighbors get confused with SOC 2. A SOC 1 report covers controls relevant to a customer's internal control over financial reporting, a different question. A SOC 3 report is a general-use summary with the test detail removed, which suits a public website and not a review.

The four places to look

1. The independent service auditor's report, which carries the opinion. Unmodified, often called unqualified, is the clean result. Qualified, adverse, and a disclaimer each mean something went wrong, and the paragraph explaining why is worth reading twice.
2. The scope language in that same report, which names the system, the services, and the period covered. Vendors often have one product in scope and others outside it, so confirm the product you are buying is the one examined.
3. The section with the control descriptions, the tests performed, and the results. This long matrix is where findings live.
4. The complementary user entity controls, which are the controls the vendor assumes the customer performs.

Where the exceptions hide

Exceptions are not announced. They appear in the results column of the control matrix, in a flat sentence describing what the auditor found. The normal result is a line stating that no exceptions were noted. Anything else deserves attention, and the specifics matter more than the count. A missed access review is a different problem from a control that did not operate at all.

An unmodified opinion can coexist with exceptions, so reading only the first pages will miss them. Management responses to exceptions typically sit in a section of other information that the report does not cover. Those responses are assertions, not tested evidence. Ask for the prior period's report too, because a repeated exception says more than either report alone.

The controls the report expects you to run

Complementary user entity controls are the part agencies skip most often. They list what the report assumes the customer does: managing user accounts, configuring the security settings the product offers, reviewing access, and protecting credentials. If the agency does not do them, the control environment described in the report is not the one the agency is operating in. Treat that list as requirements for whoever runs the system, with a named owner for each item before go-live.

Complementary subservice organization controls work the same way one level down. A vendor using the carve-out method for a subservice provider, commonly its cloud host, has excluded that provider's controls from testing. Ask which subservice organizations were carved out and how the vendor monitors them.

Dates, gaps, and what SOC 2 does not answer

A report describes a period that has already ended, and the time between that end date and today is uncovered. Vendors close the gap with a bridge letter, signed by vendor management rather than by the auditor. Ask for one and file it as a management statement, not as tested evidence.

SOC 2 also leaves agency questions unanswered. It is not a FedRAMP authorization or an authorization under a state cloud security program. It does not by itself establish that a service meets the FBI CJIS Security Policy requirements for criminal justice information. It says nothing about data residency, records retention, or public records obligations. Those belong in the contract.

We read these reports for the third party services in our own build and hosting environment, and keep a one page summary of each: scope, opinion, exceptions, user entity controls, and period end date.

What this means for an agency

• Ask for the Type 2 report, not a logo, a SOC 3, or a summary slide.
• Assign an owner for every complementary user entity control before the system goes live.
• Ask what was carved out, and request those reports too.
• Require each new report and any bridge letter in the contract for the term.
• Treat the report as one input to a security review, not as the review itself.