How to Build an Inherent Risk Score for Third-Party Vendors
Most third-party risk programs start with a deceptively simple question: how risky is this vendor before we've done anything about it? That's inherent risk โ the exposure a vendor represents based purely on what they'll touch and what they'll do, independent of any controls they have in place. Get it right and everything downstream gets easier: the high-risk vendors get the deep review they deserve, and the low-risk ones don't drown your team in unnecessary assessments.
The problem is that "how risky is this?" is usually answered by gut feel. A quantitative inherent risk score replaces that with something defensible, repeatable, and auditable. Here's how to build one.
Start with the inputs that actually drive exposure
Your inputs will vary by program, but a strong baseline covers four dimensions:
- Data type โ Is the vendor touching PII, PHI, cardholder data, or just public marketing copy? Regulated and sensitive data should carry the most weight.
- Data volume โ A vendor handling ten records is not the same as one handling ten million. Volume scales the blast radius of any incident.
- Business impact โ If this vendor goes down, what breaks? A payroll processor or a system in your revenue path is categorically different from a tool one team uses occasionally.
- Integrations โ How deeply does the vendor connect to your environment? API access, SSO, network connectivity, and privileged credentials all expand the attack surface.
The point isn't to capture everything โ it's to capture the few factors that genuinely move the needle on exposure. This is the same logic behind the two-axis framework: vendor size and inherent risk are what separate the vendors worth worrying about from the ones that don't need deep review.
Weight the inputs against each other
Not every input deserves equal say. A vendor handling PHI is inherently riskier than one with a deep integration but no sensitive data, so your model should reflect that. Assign each dimension a weight that sums to 100, score each on a consistent scale, and combine them into a single number.
A simple worked example. Suppose you weight the four dimensions like this:
| Dimension | Weight | Vendor score (0โ10) | Contribution |
|---|---|---|---|
| Data type | 35% | 9 (handles PHI) | 31.5 |
| Data volume | 25% | 8 (~2M records) | 20.0 |
| Business impact | 25% | 6 (important, not critical) | 15.0 |
| Integrations | 15% | 7 (API + SSO) | 10.5 |
| Total | 100% | 77.0 |
That vendor lands at 77 โ and now you have a number you can act on, rather than an argument you have to have.
Translate the score into tiers
A raw number is only useful if it maps to a decision. Define bands up front so the score automatically routes the vendor to the right level of review:
- High risk: 80โ100 โ Full assessment, evidence collection, executive sign-off, annual reassessment.
- Medium risk: 40โ79 โ Standard questionnaire and control review.
- Low risk: 1โ39 โ Lightweight check or streamlined approval.
The vendor above, at 77, sits at the top of the medium band โ close enough to high that it's worth a second look, which is exactly the kind of nuance a tiered model surfaces. This tiering is also what determines whether a vendor falls into the small vendor, high inherent risk category that deserves your deepest attention.
Don't let the requester scope the risk
Here's where most programs quietly break. The business requester โ the person who wants the vendor โ is usually your source of truth for the inputs. They know what data the tool will touch and how it'll be used. But they're rarely security-literate, so their answers are often wrong in good faith. And there's a structural bias working against you: a lighter risk tier means a faster approval, so requesters are naturally inclined to under-scope. "It's just a small pilot." "We're not really sending them anything sensitive."
A quantitative model is your defense against this in two ways. First, it makes the inputs explicit and reviewable โ you're asking specific, factual questions ("does this vendor store health records?") instead of "how risky is this?", which is far harder to game. Second, it lets you validate requester answers against reality. Treat their input as a starting draft, not a final verdict: have your risk team confirm the high-weight dimensions, and require justification when a vendor scores suspiciously low for what it does.
The payoff
A scored, tiered model turns inherent risk from a debate into a calculation. It gives your team consistency across hundreds of vendors, an audit trail for every decision, and a way to focus your scarce review capacity where the real exposure is. The math doesn't replace judgment โ but it makes sure judgment is applied to the right vendors in the first place.
See How Docubark Scores Inherent Risk