A vendor sends a SOC 2 report. Somebody confirms it exists, notes the date, files it, and marks the assessment complete. That sequence happens in most organisations, and it converts an independent examination into a box-ticking exercise that provides no assurance whatsoever.
Reading one properly takes about twenty minutes. Here are the five checks, in the order that catches the most with the least effort.
Check 1: Does the scope cover the service you are buying?#
Two minutes, and it invalidates more reports than the other four combined.
Find the system description — usually Section 3, and the longest part of the document. It names the system the examination covered: the product, the infrastructure, the locations, the people.
Vendors with several products frequently hold a report covering one of them. A company selling you a data platform may have a SOC 2 covering its original workflow product. The certificate-equivalent looks identical from the outside; the coverage is entirely different.
Ask two questions of the description: is the product you are purchasing named, and are the environments it runs in named? If your deployment is in an Indian region and the description covers only US-East infrastructure, the report does not describe your service.
Check 2: Is the period current, and is it Type II?#
One minute.
Type I is a point-in-time opinion on whether controls are suitably designed. Type II covers whether they operated effectively across a defined period. Type I tells you the vendor drew a good plan; Type II tells you they followed it. For anything material, Type II is the only one that answers the question.
Then check the period end date. A report covering January to December, reviewed in the following August, leaves eight months unexamined. That gap is normal — reports are periodic — but it should be covered by a bridge letter: a management assertion that the control environment has not materially changed since the period end, disclosing anything that has.
Ask for one if it is not included. A vendor who cannot produce a bridge letter is telling you something about how actively the programme is maintained.
Check 3: What is the opinion, and what is in Section 4?#
Five minutes, and this is where the substance is.
The auditor's opinion sits near the front. Unqualified means the auditor concluded the controls were suitably designed and operating effectively. Qualified means they did not, in some specified respect. A qualified opinion is not automatically disqualifying, but it is a conversation, and the qualification tells you exactly where to have it.
Then go to Section 4, which lists the controls tested, the tests performed, and any exceptions found. Most reviewers stop at the opinion; the exceptions are where the useful information lives.
Read every exception and ask one question of each: does this relate to a control I am relying on?
An exception in physical security at a data centre may be irrelevant to you if your concern is data segregation. An exception in logical access review — say, three of forty sampled quarterly reviews were completed late — is directly relevant if your risk assessment assumed access to your data was tightly governed.
A handful of well-explained exceptions is normal and does not indicate a weak programme. Zero exceptions across a twelve-month Type II at a company of any size is more likely to indicate a narrow scope than a perfect year.
Check 4: Complementary user entity controls#
Three minutes, and this is the one almost nobody reads.
Somewhere in the report — usually at the end of Section 3 or the start of Section 4 — is a list of complementary user entity controls. These are controls that you must operate for the vendor's controls to be effective.
Typical examples: you are responsible for provisioning and deprovisioning your own users, for configuring the security settings the platform exposes, for protecting the credentials issued to you, for reviewing audit logs the platform makes available.
This list is effectively a set of contract terms, and it shifts responsibility. If the report says the vendor relies on you to review access logs and you have never looked at them, then the control the report describes is not operating — regardless of what the vendor did.
Extract this list into your own control environment. It is the single most actionable page in the document.
Check 5: Subservice organisations, carved out or included#
Three minutes.
Most vendors depend on others — a cloud provider, a payments processor, an email service. The report handles these one of two ways.
Inclusive method: the subservice organisation's controls were examined as part of this report. Good for you; rarer in practice.
Carve-out method: the subservice organisation's controls were excluded, and the report describes only the vendor's own controls plus the complementary controls it expects the subservice organisation to operate. Far more common.
Under a carve-out, the report tells you nothing about the excluded party. If your vendor carves out its cloud provider, you are relying on that provider's own attestation, which you should confirm exists. If it carves out something less obvious — a specialised sub-processor handling a part of the workflow you care about — that is a gap worth raising.
The list of subservice organisations is also, usefully, a partial sub-processor list, which is directly relevant to your own data protection obligations.
What the report cannot tell you#
Five checks make a report useful. They do not make it sufficient, and knowing the boundary prevents over-reliance.
It is historical. A Type II describes a period that has ended. It says nothing about the architecture change shipped last month, the security lead who resigned, or the funding round that triggered a hiring freeze in the security team.
Scope is chosen by the vendor. They selected the criteria, defined the system boundary and decided what to carve out. A narrow, well-executed scope produces a clean report that covers less than you assumed. This is why check one comes first.
Controls operating is not controls being adequate. The auditor tests whether the vendor did what the vendor said it would do. If the vendor's stated control is a quarterly access review and yours would be monthly, an unqualified opinion confirms the quarterly review happened — not that quarterly is enough for your risk.
It says nothing about product security. SOC 2 examines the control environment, not whether the application has an authorisation flaw. A vendor can hold an unqualified Type II and ship an insecure product. For anything handling sensitive data at scale, ask for a penetration test summary as well — and read the scope on that too.
None of this argues against accepting SOC 2 reports. Proportionate assessment depends on accepting independent evidence for the tier-two population, and the alternative — assessing every vendor deeply — is what causes programmes to collapse. It argues for knowing what you accepted, so that tier-one vendors get the additional scrutiny the report does not provide.
Putting it into practice#
The twenty-minute review
- 1Scope — is the product and environment you are buying named in the system description?
- 2Type and period — is it Type II, and is the period recent enough or bridged?
- 3Opinion — unqualified? If not, what is the qualification and does it affect you?
- 4Exceptions — read Section 4 and flag any exception touching a control you rely on.
- 5Complementary user entity controls — extract them and assign owners on your side.
- 6Subservice organisations — note who is carved out and confirm their assurance separately.
Train your procurement team on these six lines and the reports you already collect start producing assurance instead of paperwork. It takes an afternoon to teach and it delivers more risk reduction than adding fifty questions to your questionnaire.
Why this matters more than the questionnaire#
Proportionate vendor assessment depends on being able to accept independent evidence for tier-two vendors rather than assessing everything deeply. That only works if somebody actually reads the evidence.
An organisation that collects reports and files them unread has the cost of a mature programme and the assurance of none. The five checks above are what convert one into the other — and they are the difference between "the vendor has a SOC 2" and "we know what the SOC 2 says about the thing we depend on."
Our Third Party & Supply Chain Risk practice builds these programmes, and the tiering model with all four proportionate question sets is published as our Vendor Risk Assessment Kit.
Enterprise & Third-Party Risk
Our risk practice specialises in quantified risk analysis, third-party risk management and operational resilience, with a FAIR-aligned methodology developed across banking, insurance and manufacturing engagements.
- FAIR Analyst
- CRISC
- CISA
Where do you actually stand?
Score your Digital Trust posture in fifteen minutes
Free, no sales call required. Privacy, security, governance, risk and AI readiness scored against sector benchmarks, with a prioritised gap list.

