A Vendor Risk Assessment Checklist That Won't Waste Everyone's Week
A tiered checklist that matches the depth of review to how risky the vendor actually is.
The fastest way to kill a vendor risk program is to use the same 200-question review on every vendor. Your engineers stop responding. Sales starts routing around you. The snack-delivery company gets a SOC 2 interrogation while the analytics tool quietly siphoning customer emails sails through because everyone was exhausted. I've watched it happen more than once.
The fix isn't a better questionnaire. It's tiering. Decide how risky a vendor actually is first, then apply only the checks that tier deserves. Below is the checklist I hand to teams who don't have a GRC department — four tiers, with the exact checks for each. Skip nothing in the right tier; skip almost everything in the wrong one.
How to tier a vendor in two minutes
Before any checks, place the vendor in a bucket using two questions:
- What data or access do they get? None, internal-only, customer/employee PII, or your crown jewels (source code, payment data, secrets, health data)?
- What happens if they go down or get breached? Mild annoyance, a bad day, or your product stops working?
Take the higher of the two answers. A vendor with crown-jewel access is critical even if you could technically live without them for a day. When you're genuinely unsure, round up — the cost of over-reviewing a medium vendor is an hour; the cost of under-reviewing a critical one is a breach notification.
This tiering is the backbone of the broader program I lay out in the vendor risk guide. The checklist below is the operational half.
Low tier — no access to your data or systems
These get a name in the register and a sanity check. That's the whole job. Spending more here is theater.
- [ ] Confirm they genuinely have no access to your data, systems, or accounts
- [ ] Record vendor name, internal owner, and what they're for
- [ ] Note the renewal date so a scope change doesn't sneak past you
- [ ] Done. Move on.
Medium tier — limited or internal-only data, easily replaced
Light-touch review. You want basic assurance they aren't reckless, not a full audit.
- [ ] Confirm exactly what data they touch (should be internal or non-sensitive)
- [ ] Check for a public trust center, security page, or listed certifications
- [ ] Grab their SOC 2 or ISO 27001 if they have one handy — don't chase it
- [ ] Verify there's a sane way to offboard them and delete data later
- [ ] Record the decision and a 24-month reassessment date
Your ad-network slot renders here
High tier — real customer or employee data, important to operations
Now it's a proper review. These vendors hold data you'd have to disclose if it leaked.
- [ ] Map the exact data: PII, employee data, support content, anything regulated
- [ ] Request a current SOC 2 Type 2 (within the last 12 months) or ISO 27001 certificate
- [ ] Read the auditor's opinion and skim the exceptions section of the SOC 2
- [ ] Confirm encryption in transit and at rest
- [ ] Confirm SSO/MFA support so you control access on your side
- [ ] Send a short questionnaire only for gaps the SOC 2 doesn't cover — see security questionnaires for which to use
- [ ] Get a DPA signed if they process personal data
- [ ] Identify their sub-processors (who they trust with your data)
- [ ] Record decision, conditions, and an annual reassessment date
Critical tier — crown-jewel data, or you go down if they do
Identity providers, cloud infrastructure, your primary database, your payment processor. Get this tier wrong and nothing else in your program matters. Do every check, and document every one.
- [ ] Full data and access mapping, including admin-level access to your environment
- [ ] Current SOC 2 Type 2 and, ideally, ISO 27001 — read both in full, not just the cover
- [ ] Review the SOC 2 exceptions and the management response to each
- [ ] Request a penetration test summary or attestation from the last year
- [ ] Confirm a documented, tested incident response plan and a breach-notification SLA in writing
- [ ] Confirm encryption, key management, and data-residency commitments
- [ ] Review their sub-processor list and how they notify you of changes
- [ ] Signed DPA, and a BAA if any health data is involved
- [ ] Confirm uptime/SLA terms and a realistic exit/data-portability plan
- [ ] Get a second set of eyes on the decision; record it with full reasoning
- [ ] Reassess annually and on any trigger (breach, acquisition, lapsed report)
What each tier actually requires, side by side
When someone asks why the analytics tool got more scrutiny than the CRM, this table is your answer.
| Check | Low | Medium | High | Critical |
|---|---|---|---|---|
| Register entry & owner | Yes | Yes | Yes | Yes |
| Trust center / security page | — | Check | Check | Check |
| SOC 2 Type 2 | — | Optional | Required | Required |
| ISO 27001 | — | Optional | Nice to have | Strongly preferred |
| Pen test summary | — | — | Optional | Required |
| Security questionnaire | — | — | Gaps only | Yes |
| DPA | — | If personal data | If personal data | Yes |
| BAA | — | — | If health data | If health data |
| Sub-processor review | — | — | Yes | Yes |
| Reassessment cadence | On change | 24 months | Annual | Annual + triggers |
Where this connects to your other compliance work
This isn't a side quest. The same evidence you collect here — SOC 2 reports, DPAs, a clean register — is exactly what your own auditor asks for when you pursue certification. Vendor reviews are a control, and a sloppy register is a finding. If you're heading toward your first audit, line this up alongside the SOC 2 readiness checklist so you're not building the same evidence twice.
Run the tiers honestly for one quarter and you'll notice the program almost disappears into the background — which is the point. The reviews that matter get real attention, and the ones that don't stop eating your week.