vendor security review template

vendor security review template

TL;DR

Tier your vendors by how much damage a breach of theirs would do to you, then review accordingly: a questionnaire and evidence for the risky ones, a light check for the rest. Approve, approve with conditions, or reject, and re-review on a schedule. The template keeps every review consistent so nothing gets a free pass.

vendor security review template

Use this when

• You are about to buy or integrate a new SaaS tool or vendor
• A vendor will touch customer data, production systems, or credentials
• An auditor asks how you vet third parties
• You need to re-review vendors you approved years ago and never revisited

Not for this skill when

• The vendor touches no sensitive data and has no system access (a light check is enough)
• You are reviewing your own company's security (that is an internal assessment)
• You need the legal review of the vendor contract (related, separate owner)

Steps

1. Tier the vendor before you review it.

Tier 1: touches customer personal data or production. Tier 2: touches internal data or has limited integrations. Tier 3: no data, no access. The tier sets how deep the review goes. Do not spend Tier 1 effort on a Tier 3 font library.

Expected: every vendor tagged with a tier and the reason for it.

2. Send the tier-appropriate questionnaire.

Tier 1 gets the full set: encryption, access control, incident response, backups, pen testing, subprocessors, compliance reports. Tier 2 gets a short form. Tier 3 gets a one-page attestation or nothing at all. Reuse the vendor's SIG or CAIQ if they have one; do not make them rewrite answers you can read.

Expected: completed answers plus evidence for every Tier 1 vendor.

3. Review the evidence, not just the answers.

A SOC 2 report, a pen test summary, a security page with real content. Check the report date: a three-year-old SOC 2 is a history lesson. Note gaps between what they claim and what the evidence shows.

Expected: an evidence list per vendor with dates, and gaps written down honestly.

4. Decide: approve, approve with conditions, or reject.

Approve means the risk is acceptable. Approve with conditions means they fix specific gaps by a date, in writing. Reject means the risk is not worth it, and you say so plainly with reasons. "Approve and hope" is not a decision.

Expected: a recorded decision with conditions and dates where applicable.

5. Put the security terms in the contract.

DPA where personal data is involved, breach notification timelines, right to audit or at least to receive reports, and deletion at contract end. The review finds the risks; the contract makes the mitigations enforceable.

Expected: signed terms covering the gaps the review found.

6. Re-review on a schedule, and on bad news.

Tier 1 annually, Tier 2 every two years, Tier 3 when something changes. Plus an immediate re-review if the vendor reports a breach or lands in the news for the wrong reasons.

vendorctl list --review-due-before 2026-12-31

Expected: a due list with no Tier 1 vendor overdue.

Variant: third party risk assessment template

This skill is the template: tier, questionnaire, evidence, decision, contract terms, re-review. Copy the section headers into your own doc and you have the assessment.

Variant: how to vet a SaaS vendor

For SaaS specifically, weight the questionnaire toward data handling: where is data stored, who can access it, how is it encrypted, how do you get your data out, what happens at cancellation. The answers to those five predict most SaaS risk.

Variant: vendor questionnaire for startups

Keep it short enough that vendors actually answer: twenty focused questions beat eighty ignored ones. Ask for their SOC 2 or CAIQ first; only questionnaire the gaps.

Variant: subprocessor review process

Your subprocessors are Tier 1 by definition if they touch personal data. They need DPAs, evidence of their controls, and a place in your public subprocessor list with change notifications.

Why this happens

Your security is only as good as your vendors' security, and vendors are where breaches love to start: a support tool with broad access, an analytics script on every page, a contractor with production keys. Reviews feel bureaucratic until the vendor breach notification lands and you are glad you knew exactly what they could touch.

Edge cases and pitfalls

• The vendor refuses the questionnaire: big vendors often do. Accept their published SIG, CAIQ, or SOC 2 instead, and document the substitution. Refusing everything is itself a signal.
• A critical vendor fails the review: you may have no alternative. Then it is approve-with-conditions plus mitigations on your side: limit the data they get, encrypt before sending, monitor the integration.
• Shadow IT vendors nobody reviewed: check expense reports and SSO logs for apps the business adopted without you. Every one of them needs at least a tiering pass.
• The review lives in email: keep one vendor register with tier, decision, evidence, and next review date. Email threads are where reviews go to be forgotten.
• Acquisitions and pivots: re-tier when the vendor is acquired or pivots into handling your data differently. The vendor you approved three years ago may not be the vendor you have today.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_onoPGaOUbnFv0q9CIPvTDA