Compliance Artifacts

Vendor security reviews, explained (with example record)

A vendor security review is how you manage third-party risk: before a vendor touches your data — and on a schedule afterward — you collect their audit artifacts, actually read them, and record a risk decision someone accountable signed. Here’s when to review, how to tier vendors, what reading a SOC 2 report involves, and a record to copy.

Talk to a Compliance Engineer

Last updated July 26, 2026

What a vendor security review is, and when to run one

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.

Tier vendors by data access, then match the effort

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.

What “reviewing a SOC 2 report” actually means

Filing the PDF is not a review. Six things to read before recording an outcome.

The opinion, in the auditor’s letter up front. Unqualified means controls were found effective; qualified means problems rose to the level of the opinion itself. Qualified isn’t automatic rejection — read what was qualified and decide whether it touches your use of the product.
Report type and period. A Type II covers operating effectiveness over months; a Type I is a point-in-time design snapshot and far weaker assurance. If the period ended more than a few months ago, ask for a bridge letter covering the gap.
Scope. Confirm the system described is the product you actually use — multi-product vendors sometimes scope the audit to the flagship, leaving yours outside it.
Test results and exceptions. The detailed section lists every control tested and any deviations, with management responses. A few minor, remediated exceptions is normal; exceptions in access control or change management at a tier-1 vendor deserve follow-up questions.
Complementary user entity controls (CUECs) — the controls the vendor’s auditor assumes you operate, like enforcing SSO, scoping API keys, or configuring retention. List the ones that apply and assign each an owner; the report’s assurance quietly depends on your side of the bargain.
Subservice organizations — the vendors your vendor relies on, usually carved out of the report. Know who they are: for a tier-1 vendor, their critical dependencies are part of your risk picture.

A vendor review record you can copy

Vendor security review record — condensed

Vendor: [CloudRelay, Inc.] — transactional email delivery · Tier: 1 (processes customer email addresses and message content)

Trigger: Annual review · Reviewer: [Name], Security Lead · Date: [July 14, 2026]

Artifacts collected: SOC 2 Type II report (period ended [March 31, 2026], unqualified opinion); bridge letter covering the months since period end, requested and on file; signed DPA on file; current subprocessor list; abbreviated questionnaire (12 items).

Notes: Two exceptions in the test results — a delayed offboarding and a missed patch window — both with management responses marked remediated. Three CUECs apply to us: enforce SSO for our tenant, rotate API keys, restrict sending domains. Owners assigned (ENG-3121).

Outcome: Approved for continued use. Residual risk accepted by [Name], CTO; recorded in risk register entry [VR-031].

Next review: [July 2027], or immediately on incident, acquisition, or a change in the data shared.

Document the outcome — especially risk acceptance

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.

How Agency handles vendor reviews — both directions

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.

Frequently asked questions

Do we have to review every single vendor?

Every vendor should exist in the inventory with a tier; only tiers with data access get real depth. Auditors don’t expect a full assessment of the office plant service — they expect you to know what each vendor touches and to scale scrutiny to it. What they flag is a data-handling vendor with no record at all.

What if a vendor has no SOC 2 report or ISO 27001 certificate?

Collect what they do have — a completed questionnaire, a penetration test summary, architecture documentation — and make an explicit call: accept the residual risk in writing with an expiry, add contractual terms, or walk away. Small vendors without audits are workable at low tiers; for a tier-1 vendor, missing attestation is a real signal.

What are CUECs in a vendor’s SOC 2 report?

Complementary user entity controls: the controls the vendor’s auditor assumed the customer — you — operates, such as enforcing SSO, managing your own users, or configuring encryption options. Ignore them and the report’s assurance doesn’t fully apply to your usage. List the relevant ones during the review and give each an owner.

How long does a vendor security review take?

For a tier-1 vendor with a clean, current report: an hour or two of actual reading and writing, spread across the days it takes to collect artifacts. Elapsed time is dominated by chasing — which is why anchoring reviews to renewal dates, when you have leverage and their attention, shortens everything.

Who should accept vendor risk?

Someone with authority over the business outcome, by name — typically the CTO or CEO at a startup, a formal risk owner later. The reviewer recommends; the executive accepts. Auditors look for that separation, because an analyst “accepting” company-level risk on their own signature is a decision nobody is accountable for.

Keep going

SOC 2 GDPR Vendor Risk Questionnaire Fatigue Managed Vanta

Vendor risk, run as a workstream

Agency keeps your vendor inventory, tiers, reviews, and risk register current — and answers the questionnaires coming the other way. Top-ranked Vanta & Drata partner · 1,000+ companies served since 2021 · 4.9/5 on G2.