# Vendor Risk Scoring for Regulated SMBs

Canonical: https://kaansystems.com/library/vendor-risk-scoring
Topic: Security · Published: 2026-07-29 · Updated: 2026-10-12
Summary: A vendor breach becomes your breach. Most SMBs 'assess vendors' with a gut check at procurement and never again. A lightweight four-factor rubric produces a repeatable risk score, sorts vendors into tiers, and sets a review cadence that matches the risk.

## Key takeaways

- Third-party risk is a large share of a regulated SMB's attack surface, and it's the share zero-trust controls can't reach — you can't enroll a vendor in your MDM or put them behind your access proxy.
- Score each vendor 1-3 on four factors — data sensitivity, access and integration depth, attestation gap, and blast radius — then sum them for a 4-12 risk score.
- Data sensitivity is the biggest lever, so weight it heaviest: a vendor that can read patient records and one that resizes marketing images aren't the same risk, even with identical SOC 2 reports.
- The score maps to a tier — Critical 10-12, High 7-9, Medium 5-6, Low 4 — and the tier, not gut feel, decides how much review effort each vendor gets.
- Score every vendor at procurement before access is granted, and re-score immediately whenever a vendor discloses a breach, not just on the annual calendar.
- The rubric is triage, not certainty: it tells you which five vendors out of forty deserve deep review, turning 'review all our vendors' into 'review the five that matter'.

**How do you score vendor risk without a GRC platform?** Rate each vendor 1-3 on four factors — data sensitivity, access depth, attestation gap, and blast radius — and sum them into a 4-12 score. The score sorts vendors into tiers, and the tier sets the review cadence, so deep review goes to the five vendors that actually matter, not all forty.

## Why does a gut-feel vendor review fail?

Your security floor is your vendors' security floor. A vendor you gave access to sensitive data gets breached, and now you're breached — Snowflake credentials in 2024, MOVEit in 2023, and a long tail of quieter incidents that became someone else's disclosure notice. Third-party risk isn't a side concern for a regulated SMB. It's a large share of the actual attack surface — and the share the [zero-trust controls you apply to your own users and devices](/library/zero-trust-for-smbs) can't reach, because you can't enroll a vendor in your MDM or put them behind your access proxy.

The way most SMBs handle it: a gut-feel check at procurement ("seems legit, they have a SOC 2"), a signed order form, and then nothing, ever again. By the time the company has 40 SaaS vendors, nobody can say which ones can read customer data, which ones have an attestation, or which one would take the business down if it disappeared on a Tuesday.

You can't review 40 vendors deeply every year, and you shouldn't try. What you need is a cheap, repeatable way to **score** each vendor so the review effort goes where the risk is. Not a GRC platform. A rubric. Keep the attestation you accepted queryable in an [evidence pipeline](/library/evidence-pipelines-101), and reuse that proof when you [answer a security questionnaire](/library/reading-security-questionnaire). The [7-day Assessment](/assessment) is the read-only pass over the estate those vendors touch.

## How do you score a vendor on four factors?

Score each vendor on four factors. Multiply the sensitivity of the data by how deeply the vendor is wired in, adjust for how much assurance they've given you and how much a breach would cost — that's the risk. The score sorts vendors into tiers, and the tier sets the review cadence.

```mermaid
flowchart LR
  F1[Data sensitivity<br/>What can they touch?]
  F2[Access + depth<br/>How wired in are they?]
  F3[Attestation gap<br/>What have they proven?]
  F4[Blast radius<br/>What if they're breached?]

  F1 --> S[Risk score]
  F2 --> S
  F3 --> S
  F4 --> S
  S --> T{Tier}
  T --> C1[Critical / High<br/>review at procurement<br/>+ annually]
  T --> C2[Medium / Low<br/>review at procurement<br/>+ on change]

  classDef factor fill:#0d1f1a,stroke:#3FA585,stroke-width:1.5px,color:#E8F5EE;
  classDef score  fill:#1F4A3E,stroke:#3FA585,stroke-width:2px,color:#E8F5EE;
  classDef gate   fill:#0d1f1a,stroke:#3FA585,stroke-width:1.5px,color:#E8F5EE;
  classDef tier   fill:#1F4A3E,stroke:#3FA585,stroke-width:1.5px,color:#E8F5EE;
  class F1,F2,F3,F4 factor;
  class S score;
  class T gate;
  class C1,C2 tier;
```

### Factor 1: Data sensitivity

What class of data can this vendor touch? This is the biggest lever, so weight it heaviest.

- **3 — Regulated:** PHI, PII, cardholder data, or credentials to systems holding those.
- **2 — Confidential:** internal business data, customer lists, non-regulated but sensitive.
- **1 — Low / none:** public data, or a tool that never touches customer data at all.

A vendor that can read your patient records and a vendor that resizes your marketing images are not the same risk, no matter how similar their SOC 2 reports look.

### Factor 2: Access and integration depth

How wired in are they? A breach of a deeply-integrated vendor with standing API access is a very different event from a breach of a tool someone logs into occasionally.

- **3 — Deep / standing:** persistent API access, OAuth into your core systems, an agent on your infrastructure.
- **2 — Moderate:** regular data flow, scoped integration, SSO with meaningful permissions.
- **1 — Shallow:** occasional manual use, no standing access, easily revoked.

### Factor 3: Attestation gap

What have they actually proven about their security? This factor *reduces* risk when it's strong, so score the gap: high score means little assurance.

- **3 — Nothing:** no SOC 2, no ISO 27001, no security page, won't answer a questionnaire.
- **2 — Partial:** a trust page and some answers, or an attestation that's stale or narrow.
- **1 — Strong + current:** current SOC 2 Type II or equivalent, covering the relevant scope.

A current, in-scope attestation isn't proof of safety, but its absence is a real signal — especially from a vendor touching regulated data.

### Factor 4: Blast radius

If this vendor vanished or was compromised, what does it cost you? This captures operational dependence, not just data exposure.

- **3 — Business-critical:** losing them takes down your product or a core business function.
- **2 — Significant:** painful, workaround exists, degraded operations for days.
- **1 — Minor:** annoying, quickly replaced or lived without.

### From score to tier to cadence

Sum the four factors (4–12). The score sorts each vendor into a tier, and the tier — not your gut — decides how much review effort they get:

- **10–12 — Critical:** security review at procurement, annual re-review, notification requirement in the contract, on your sub-processor list if they touch customer data.
- **7–9 — High:** review at procurement, annual re-review, attestation on file.
- **5–6 — Medium:** review at procurement, re-review on material change (new integration, new data access).
- **4 — Low:** lightweight check at procurement, no scheduled re-review.

The point isn't the exact numbers. It's that a vendor with standing access to PHI and no SOC 2 scores an 11 and gets real scrutiny, while the image resizer scores a 4 and doesn't consume your limited review time.

## The Template

Score each vendor across the four factors. Multiply data sensitivity by nothing — just sum — but if you want the sensitivity to dominate, weight Factor 1 double. Keep it simple enough that you'll actually run it.

| Vendor | Data sensitivity (1-3) | Access depth (1-3) | Attestation gap (1-3) | Blast radius (1-3) | Score (4-12) | Tier | Next review |
|---|---|---|---|---|---|---|---|
| _Example: analytics vendor_ | 2 | 2 | 1 | 2 | 7 | High | + annual |
| _Example: PHI data processor_ | 3 | 3 | 2 | 3 | 11 | Critical | + annual |
| _Example: image CDN_ | 1 | 1 | 1 | 1 | 4 | Low | at change |
| | | | | | | | |
| | | | | | | | |

**Tier thresholds**
- 10-12 Critical — procurement review + annual + contract notification clause + sub-processor list
- 7-9 High — procurement review + annual + attestation on file
- 5-6 Medium — procurement review + re-review on material change
- 4 Low — lightweight check at procurement

**Scoring rules**
- Score at procurement, before access is granted, and record the score.
- Re-score any vendor immediately if they disclose a breach — a Critical vendor's incident is your incident.
- The sub-processor list on your trust page is the source of truth for who touches customer data; every vendor scoring on Factor 1 at 2+ belongs on it.

## Operating Notes

Score at the gate, not after. The cheapest time to assess a vendor is before you've integrated them, when "no" is still easy and you have leverage to ask for the DPA, the attestation, or the notification clause. A vendor scored after they're wired into production is a vendor you're stuck with. Make the score a required field on the procurement checklist.

Re-score on their breach, not just your calendar. The annual cadence is the floor. The real trigger for a re-score is a vendor disclosing an incident of their own — that's the moment their risk to you changed, and it's exactly when most SMBs do nothing because there's no process pointing at it. A Critical-tier vendor's breach notification should automatically open a review on your side.

The rubric's job is triage, not certainty. A four-factor score won't tell you a vendor is safe. It tells you which five vendors out of forty deserve the deep review your team actually has time for, and which thirty-five don't. That triage is the whole value: it turns "review all our vendors" — a task that never happens — into "review the five that matter," which does.

## Frequently asked questions

**Q: How do you score vendor risk for a small business?**

Rate each vendor 1 to 3 on four factors — data sensitivity, access and integration depth, attestation gap, and blast radius — then sum them into a 4-12 score. The score sorts each vendor into a tier, and the tier sets how often you review them. It's a rubric, not a GRC platform.

**Q: What are the four factors in the vendor risk rubric?**

Data sensitivity (what class of data the vendor can touch), access and integration depth (how wired in they are), attestation gap (how little they've proven about their security), and blast radius (what it costs you if they're compromised or vanish). Data sensitivity is the biggest lever, so weight it heaviest.

**Q: How often should I review my vendors?**

Let the tier decide. Critical (10-12) and High (7-9) vendors get a security review at procurement plus an annual re-review; Medium (5-6) vendors are re-reviewed on material change; Low (4) vendors get a lightweight check at procurement and no scheduled re-review.

**Q: When should I re-score a vendor?**

The annual cadence is the floor. Re-score immediately if a vendor discloses a breach of their own — that's the moment their risk to you changed, and a Critical-tier vendor's incident is your incident. Most SMBs do nothing here because no process points at it.

**Q: Does a vendor's SOC 2 report mean they're safe?**

No. A current, in-scope attestation isn't proof of safety, but its absence is a real signal — especially from a vendor touching regulated data. The rubric scores the attestation gap as one of four factors, not as a pass/fail verdict.

**Q: Do I need a GRC platform to do vendor risk scoring?**

No. The whole point is a cheap, repeatable rubric you'll actually run — four factors, a 4-12 score, and a tier that sets the review cadence. Its job is triage: telling you which five vendors out of forty deserve the deep review your team actually has time for.

Template: "Vendor risk scoring rubric" — branded PDF at https://kaansystems.com/templates/vendor-risk-scoring.pdf

Source: https://kaansystems.com/library/vendor-risk-scoring · Work with Kaan Systems: https://kaansystems.com/contact