Vendor security reviews, explained (with example record)

A vendor security review is third-party risk management pointed at your own supply chain: assessing the security posture of the companies whose software and services touch your data, and documenting the risk you take on by using them. It’s the mirror image of the questionnaires your customers send you.

Three moments trigger one. Onboarding: before the contract is signed and data flows — your only real leverage point, since a vendor’s attention to your requirements peaks the week before signature. On a schedule: annually for vendors with meaningful data access, longer cycles below that. On events: the vendor discloses a breach, gets acquired, or your usage changes materially — say, a marketing tool that suddenly starts receiving customer PII.

Your own auditors care because vendor management is a tested control in both SOC 2 and ISO 27001. Expect them to pull your vendor inventory, pick a sample, and ask for the review records. Records that don’t exist — or an inventory nobody maintains — is the classic finding in the vendor risk domain.

The mistake that kills vendor programs is uniform depth — a two-hundred-question assessment for the office snack vendor while your cloud provider sits in the same queue. Tiering fixes it: classify each vendor by what it can touch, and let the tier set both review depth and cadence.

Tier 1 — customer data or production access. Cloud infrastructure, subprocessors, anything holding customer records or with a path into production. Full review at onboarding and annually: a current SOC 2 Type II report or ISO 27001 certificate, a signed data processing agreement (DPA) where personal data is involved, the subprocessor list, and a short questionnaire for whatever the report doesn’t answer. Tier 2 — internal business data only. Tools holding financials, internal documents, or employee data but no customer data: certificate check plus an abbreviated questionnaire, refreshed every year or two. Tier 3 — no meaningful data. Reviewed once at onboarding for terms and authentication basics, then only on scope change.

Tier assignments need review too. The common failure is a tier-3 tool that quietly became tier-1 the day someone connected it to the data warehouse — access changes, not calendar time, should move vendors between tiers.

A review that ends in “looked fine” is not a control; the record has to land on a decision. Approved, approved with conditions (named, dated), or rejected. Where residual risk remains — a vendor with no audit report you need anyway, an exception you’re living with — someone with real authority accepts it by name, and the acceptance goes in the risk register with an expiry. “The security team was aware” is not risk acceptance; “[Name], CTO, accepted on [date], revisit by [date]” is.

When a vendor can’t produce a report or certificate, the answer is neither silence nor an automatic no. Collect compensating evidence — a completed questionnaire, a penetration test summary, architecture answers — then either accept the documented risk at the right level or decline the vendor. What auditors flag is the undocumented middle: the tool everyone uses that nobody assessed.

The other quiet failure is inventory decay. Teams adopt tools weekly, and a review program pointed at last year’s list reviews the wrong things. Tie intake to procurement and SSO — if a tool gets an SSO tile or an invoice, it exists in the inventory — so the review queue tracks reality.

On managed compliance, third-party risk runs as a standing workstream: Agency maintains the vendor inventory, assigns tiers, chases artifacts at renewal, reads the reports, tracks CUEC ownership, and keeps the risk register current in Vanta or Drata — so vendor management stops being the control that only exists the week before an audit.

And the flip side: when you’re the vendor — on the receiving end of these reviews, with customer questionnaires stacking up — that’s its own workflow, and Agency runs that too. See security questionnaire services.