Your payroll SaaS vendor emails its SOC 2 Type II report covering January to December. The risk committee marks the vendor risk as covered and closes the item. What has that report actually given you?

What the report is

A SOC 2 Type II report is independent assurance over the service organisation's controls, for a stated period that has already ended — commonly 180 or 365 days. It is the vendor's third line (an external auditor) reporting on the vendor's first and second lines, which is the separation the Institute of Internal Auditors restated in its 2020 Three Lines Model. It is not your assurance, and it never covers your use of the product, because the auditor tested the platform rather than your tenant.

Two sections decide what it is worth to you, and both sit near the back where nobody reads:

• The exceptions. A Type II report lists every instance where a control did not operate. A report with no exceptions across twelve months and forty controls is either a very disciplined vendor or a very narrow scope. Read the scope statement next to it.
• The complementary user entity controls (CUECs). These are the controls the auditor assumed you operate when concluding the vendor's controls were effective. A typical report lists 10 to 30 of them: you remove leavers within 5 days, you enforce MFA on your tenant, you review administrator roles, you configure retention. If you do not operate them, the opinion does not extend to your instance of the service — the auditor's conclusion was conditional on work you never did.

Why the other options fail

"Assurance that your own configuration is compliant." This is the CUEC trap. The report describes the vendor's platform; almost every real breach of a SaaS product is a customer-side configuration, and the report explicitly hands those back to you. It would be right only if the vendor operated the tenant configuration on your behalf under contract.

"Coverage of every subservice provider." Most reports use the carve-out method: the cloud provider, the payment processor and the email gateway the vendor depends on are excluded, with a note that their controls were not tested. The inclusive method exists and is rarer. Reading which method was used tells you how much of the supply chain is still unexamined — for a vendor that is mostly a thin layer over other services, that can be most of it.

"Grounds to close the risk register entry." The risk is yours; only some of the control is theirs. Closing the entry also loses the date, and a report covering a period that ended in December is stale by the following summer. The usual patch is a bridge letter from the vendor covering the gap between the period end and today, which is management's assertion rather than audited evidence.

What to do with it, in order

1. Read the scope — which systems and which trust services criteria. Availability and confidentiality are often out of scope even when security is in.
2. Extract the CUECs into your own control set, each with an owner. This is the only part of the exercise that changes anything in your architecture.
3. Read the exceptions and management's response. A repeated exception in access removal tells you more than the opinion does.
4. Diarise the period end. Ask for the next report before the gap exceeds 90 days, and price the effort honestly: reading one report properly and wiring its CUECs into your own control set costs a day or two of a senior person's time, which is why most organisations skim it instead.

When this is not worth the effort

For a low-consequence vendor — a design tool with no customer data, a status-page service — a CUEC programme is theatre. Record that you accepted the vendor on the strength of the report, note the two configuration settings that matter, and move on. Reserve the full treatment for vendors whose failure shows up in your incident report: identity, payments, data processing, anything holding production data.