The last item in the readiness guide asks whether anyone has reviewed your critical vendors' security. For a team without a security function, that question can sound like it requires a capability you do not have.
It does not. Nobody expects you to audit a cloud provider. What a reviewer is actually asking is whether you chose your vendors with your eyes open, or whether you signed up and never thought about it again.
Deciding who gets reviewed
Reviewing everything to the same depth is not possible and produces uniformly shallow work. Sort your vendor list and pick the ones that matter on two axes.
How much customer data do they hold? A support desk holding every conversation you have ever had with a customer is a different proposition from a tool that sees aggregate page counts.
How badly would their failure hurt? Your database host and your authentication provider can take you off the air; a scheduling tool cannot.
Anything high on either axis deserves an hour. For most small teams that is between three and six vendors. Everything else gets listed, given a DPA if it needs one, and left alone.
What to look at first, for free
Before asking anyone anything, twenty minutes of public reading tells you a surprising amount.
Their trust or security page. Most serious vendors have one. What you want to see: which certifications they hold and when they were issued, a current subprocessor list, a described incident response process, and a way to report vulnerabilities.
Their status page and its history. Not just whether it is green now. Read the last year of incidents. What you are judging is not whether they had outages, because everyone does, but whether the write-ups are specific and honest or vague and defensive. A vendor that publishes real post-incident detail is a vendor with a functioning process.
Their external hygiene. You can scan a vendor's domain the same way you would scan your own. TLS configuration, security headers, email authentication and exposed assets are all publicly observable and require no permission to look at, because every visitor sees them.
Be proportionate about what that tells you. A vendor missing a
Permissions-Policy header is not a finding worth raising. A vendor
with an expired certificate, no DMARC record and an exposed admin panel is
showing you something about how they operate. It is weak evidence pointing in a
consistent direction, which is exactly how to treat it.
The five questions
When you do ask, keep it short. A five-question email gets answered; a forty-question spreadsheet gets deprioritised, and you will not read the answers carefully anyway.
- Do you hold a current SOC 2 Type II report or ISO 27001 certificate, and can we see it under NDA?
- Where is our data processed and stored, and which subprocessors have access to it?
- How do you detect and respond to security incidents, and what is your notification commitment to customers?
- How do you manage employee access to customer data?
- What happens to our data if we leave?
Notice that three of these are about process rather than technology. For a vendor you cannot inspect, how they behave when something goes wrong matters more than their current configuration.
Reading a SOC 2 report without being an auditor
If one arrives, four things tell you most of what you need.
Type I or Type II. Type I says controls were designed appropriately on one date. Type II says they operated effectively over a period, usually six to twelve months. Type II is substantially stronger.
The period covered. Reports are for a window that has ended. One covering a period ending eighteen months ago is stale, and a vendor with a functioning programme will have a more recent one or a bridge letter explaining the gap.
The scope. Which systems and which products. A report covering a vendor's flagship platform says nothing about the newer product you actually bought.
The exceptions. In the auditor's opinion section. Findings are normal and not disqualifying. What matters is whether they are material to the way you use the service, and whether management's response reads like a plan or a deflection.
Weighing what comes back
Answers vary enormously in quality, and reading them well is most of the skill.
Specific beats polished. "Access to production data requires a ticket and is granted for a fixed period; we review access quarterly and can show you the last review" is worth more than a page of assurance language. Detail is hard to fabricate.
Watch for scope sleight of hand. A vendor answering a question about the product you use with information about a different one, or describing controls that apply to their corporate systems rather than their platform, is a common pattern and usually not deliberate. Asking a clarifying question resolves it quickly.
Notification timelines are the clause to pin down. "We will notify affected customers without undue delay" means very little. A stated number of hours means something, and it is the commitment you will care about most if their bad day becomes yours.
Where an answer is vague on something that matters, ask once more, plainly. Most vendors respond well to a direct follow-up, and the ones that do not have told you something useful.
Writing it down
The review only becomes a control when it is recorded, and the record can be short. Half a page per vendor:
- Who reviewed it and when.
- What evidence you saw: report type and date, trust page, scan results.
- What data they hold and how critical they are.
- Anything that concerned you.
- The decision: proceed, proceed with conditions, or replace.
The last line is the point. A review that ends without a decision is reading, not reviewing. "Proceed. Residual risk accepted: no SOC 2, small vendor, holds customer email addresses only. Owner Jane, review March 2027" is a complete and defensible entry.
When there is nothing to review
Plenty of useful small vendors have no certification, no trust page and no formal process. That does not make them unusable. It makes them a decision.
Ask the questions anyway. A thoughtful answer from a two-person company explaining exactly how they handle data can be more informative than a polished trust page, because it is specific and you can tell it was written by someone who has thought about it.
Then decide deliberately, note the reasoning, and put a date on it. The difference between an accepted risk and an ignored one is entirely in whether it is written down.
Keeping it from becoming an annual scramble
Two triggers are enough. Review a critical vendor when you first adopt it, which is also the moment you have the most leverage to ask questions. Then annually, and any time something changes: they are acquired, they announce a breach, or you start sending them materially more sensitive data.
Three to six vendors at an hour each, once a year, is an afternoon. That is a real, evidenced control, and it is achievable by a team of four.
The last item
This is the final question in the readiness guide, and it closes a loop that started with your own domain. Everything you have asked about yourself, whether access is controlled, whether data is isolated, whether there is a plan when things go wrong, applies equally to everyone you have handed your customers' data to.
You cannot verify most of it. You can ask, read what comes back, and write down what you decided. That is what a reviewer is looking for, and it is genuinely what the control is.