Vendor Risk Scoring for Regulated SMBs

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.

Template included

Vendor risk scoring rubric

Copy as markdown to paste into your repo, or download a branded PDF for sharing with non-technical stakeholders.

Download PDF

The Problem

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.

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.

The Approach

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.

Data sensitivity

What can they touch?

Access + depth

How wired in are they?

Attestation gap

What have they proven?

Blast radius

What if they're breached?

Risk score

Tier

Critical / High

review at procurement

+ annually

Medium / Low

review at procurement

+ on change

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.

VendorData sensitivity (1-3)Access depth (1-3)Attestation gap (1-3)Blast radius (1-3)Score (4-12)TierNext review
Example: analytics vendor22127High+ annual
Example: PHI data processor332311Critical+ annual
Example: image CDN11114Lowat 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.

Vendor sprawl outrunning your review process?

You inherited every vendor's security posture. Score it.

By the time an SMB has 40 SaaS vendors, nobody remembers which ones can read customer data. When you want the scoring rubric stood up and the material vendors actually reviewed, talk to us — it's part of how we run compliance operations.

Open a conversation