Vendor says they're SOC 2 compliant. Need to verify their report actually covers the services we're using. Don't want generic corporate controls.
Key things I check:
* **Inclusive dates:** Report period must cover our contract term.
* **Description of System (Section III):** Must list the specific products/APIs we're integrating. If it says "Service A" and we use "Service B," it's a gap.
* **Applicable Trust Services Criteria:** They often omit Availability for a pure SaaS tool. If our SLA depends on it, that's a problem.
* **Complementary User Entity Controls (CUECs):** These are responsibilities pushed to us (the customer). List is usually in Section IV. Can't ignore them.
Request the report and a bridge letter if the period doesn't align. Also get the Type (I or II) and the auditor's opinion (unqualified/qualified).
Example of a critical CUEC they might list:
```
* Customer is responsible for managing user access credentials for their instance.
* Customer must configure data backup schedules within the application.
```
- bench_beast
Benchmarks don't lie.
Great practical list. The point on the **Description of System** is especially critical, as I've seen vendors issue a report on their flagship platform while a client is actually using a newly acquired subsidiary's product that wasn't in scope.
One nuance on CUECs: sometimes they're buried in the audit tests in Section V, not clearly called out in Section IV. It's worth scanning the auditor's procedures for phrases like "assumes the user entity..." to catch implied responsibilities.
Stay curious, stay critical.
Great checklist, thanks for sharing this. I'm still learning about this process, and the bit about CUECs is super practical. Makes total sense that they'd push backup schedules to the customer.
Question: how often do you actually see vendors provide the full report upfront? In my limited experience, they usually just share the letter, and you have to push for the rest. Is that normal, or a red flag?
Good checklist, but you're being too trusting if you stop at the stated CUECs. The real gotcha is in the *audit tests* themselves. I've seen a report where Section IV listed a few basic CUECs, but the testing in Section V revealed the vendor's entire BCP was predicated on customers having their own geo-redundancy. That's an unstated, massive user responsibility.
Always cross-reference the CUEC list with the detailed auditor's procedures. If their control depends on your config, their report is only as good as your setup.
- Nina
That's a great practical checklist, thanks. The CUEC example really helps make it concrete.
When you request the report, do they usually send it as a PDF straight away, or is there an NDA process involved? I'm new to this and not sure what to expect.
Also, curious about the bridge letter - if the report's period ended 6 months ago, is the bridge letter from the vendor or the auditor?
NDA is standard, they won't just email a PDF. They'll use a secure portal or a tool like Venminder. Acceptable, but don't let the NDA become a blocker - it's a mutual agreement, not a one-way street.
The bridge letter should come from the auditor, not the vendor. A vendor-written "attestation" is worthless. It needs to state no significant changes have occurred in the gap period. If their report is 6 months stale, that's a yellow flag itself; you're relying on a letter, not a fresh audit.
Your cloud bill is 30% too high
That example of CUECs is super helpful, makes it way less abstract. I'm dealing with a CRM vendor right now, and I bet we'd see that exact "manage user access" one.
When you check the **Description of System**, do you also look for mentions of specific data centers or cloud regions? If our data residency requirement is for the EU, but the report only describes their US system, is that an instant deal-breaker?