.svg){kind=logo}
An auditor asks how many of your critical vendors are current on their security assessments. You have a policy. You have a spreadsheet. You don't have an answer, because nobody's been tracking it as a number.
Vendor risk management metrics, sometimes called third party risk management metrics depending on which team names the program, are the measurements that turn a vendor risk process from a document into an operating practice.
KPIs show how well the program itself is running: coverage, speed, completion rates. KRIs, key risk indicators, show how exposed you actually are right now: scores trending down, certifications lapsing, remediation sitting overdue. Together they're what separates "we have a vendor risk process" from "we can prove it's working."
This isn't a guide to building a vendor risk program from scratch or writing the policy behind it. If that's what you need, ComplyJet's guides to the TPRM lifecycle and third-party risk management policy cover exactly that. This one assumes the program already exists and answers a narrower question: what to actually measure, how to map it to what a SOC 2 auditor wants as evidence, and how often to report it.
By the end, you'll have a curated set of vendor risk management metrics worth tracking, know the difference between a KPI and a KRI well enough to stop mixing them up, and have a simple maturity model to place your own program on. Here's what's ahead:
- KPIs vs. KRIs, and why the distinction changes what you report and to whom
- Why these metrics matter specifically for a SOC 2 program
- The KPIs worth tracking, and the KRIs that actually predict trouble
- What a SOC 2 auditor wants to see as evidence, mapped to a specific trust services criterion
- A simple three-tier maturity model
- How often to report, and what should trigger an off-cycle update
Vendor Risk Management Metrics and Third Party Risk Management Metrics: KPIs vs. KRIs
Vendor risk management metrics split into two categories that measure two different things, and conflating them is the single most common mistake in how companies report on vendor risk.
KPIs (key performance indicators) measure how well the vendor risk program is operating: how fast assessments happen, how much of the vendor list is actually covered, how quickly findings get closed. A strong KPI doesn't tell you a vendor is safe. It tells you the process around that vendor is functioning.
KRIs (key risk indicators) measure the risk itself: which vendors are trending toward a problem, which certifications have lapsed, which remediation items are sitting untouched past their deadline. A KRI is a warning sign, not a process metric.
The distinction matters most when you're reporting up. A security lead reviewing KPIs weekly wants to know whether the assessment pipeline is keeping pace. A founder or board member being briefed quarterly doesn't want a process update, they want to know which vendors currently represent real risk. Handing either audience the wrong category of metric either buries the real signal in operational noise or drowns a business conversation in process detail nobody in the room can act on.
| Activity | KPI (program health) | KRI (risk exposure) |
|---|---|---|
| Vendor assessments | Assessment completion rate by tier | % of Tier 1 vendors below minimum risk score |
| Security certifications | Questionnaire response rate | Vendors with lapsed security certifications |
| Remediation | Average days to finding closure | Overdue remediation findings for Tier 1 vendors |
| Ongoing monitoring | Re-assessment rate after a material risk event | Vendor risk score decline rate over a recent period |
Why Vendor Risk Management Metrics Change What You Report
A vendor risk management metrics program that only tracks KPIs looks efficient right up until a vendor with a perfect assessment-completion record has a breach nobody saw coming, because completion rate was never the metric that would have caught it. Track both categories deliberately, not one by default because it's easier to measure.
Why Vendor Risk Management Metrics Matter for a SOC 2 Program
A vendor risk policy with no measurement behind it is exactly the shape of finding a SOC 2 auditor flags: a control that exists on paper but can't be shown operating in practice. Auditors don't take a policy document's word for it. They ask for evidence the process actually ran, on a schedule, across the vendors it was supposed to cover.
That evidence has to be a number, not a description. "We review vendor risk periodically" isn't evidence. "94% of Tier 1 vendors were reassessed within the last 12 months, tracked in this register" is.
This is also where a vendor risk metrics program earns its keep outside of audit season. A vendor scoring worse quarter over quarter, a certification quietly lapsing, a remediation item sitting untouched for months, none of that shows up if nobody's tracking the number. By the time it becomes a visible incident, the metric that would have flagged it early was already there, just not being reported.
Vendor Risk Management Best Practices: KPIs, Coverage, and the Vendor Management Risk Matrix
A vendor risk management metrics program doesn't need twenty tracked numbers. It needs a small, curated set that actually gets reviewed, not a dashboard nobody opens. One of the more overlooked vendor risk management best practices is resisting the urge to track everything at once. Below is the set worth starting with, organized into two groups.
Coverage and Cadence Metrics
These answer a simple question: is the process actually running, on time, across every vendor it's supposed to cover?
- Vendor inventory completeness rate. What share of your actual vendor footprint (including the ones engineering signed up for without telling anyone) is in the register at all. This is the metric underneath every other one, since a vendor that isn't tracked can't be assessed.
- Assessment coverage rate by tier. What share of Tier 1, Tier 2, and Tier 3 vendors have a current assessment on file, broken out by tier rather than blended into one number that hides a Tier 1 gap behind a healthy Tier 3 average.
- Assessment cycle time. How long it takes from kicking off a vendor assessment to closing it out. According to Atlas Systems' breakdown of third-party risk management metrics, the industry average runs 30 to 45 days, with best-in-class programs closing assessments in under 10.
- Re-assessment rate after a material risk event. When a vendor has a breach, a lapsed certification, or a significant score drop, does a re-assessment actually get triggered, and how quickly.
Assessment and Remediation Metrics
These answer the next question: when a gap is found, does it actually get closed?
- Finding closure rate by severity. What share of findings get resolved, split by how serious they are. A high overall closure rate can still hide a stack of untouched critical findings.
- Average days to finding closure. How long a finding sits open once it's identified, again broken out by severity rather than averaged flat.
- Questionnaire response rate. How many vendors actually complete a security questionnaire when asked. The same Atlas Systems analysis notes that a response rate below 70% signals a process problem worth investigating on the vendor-facing side, not just chasing harder.
- SLA adherence rate. How often a vendor meets the service-level and security commitments in its contract, with a common target of staying above 90%.
A vendor management risk matrix, a simple grid plotting vendor criticality against assessed risk level, is the tool most teams already use to decide which of these metrics gets tracked at what frequency for which vendor tier. Tier 1 vendors sitting in the high-criticality, high-risk quadrant warrant every metric above tracked monthly. A low-criticality Tier 3 vendor doesn't need the same cadence.
| Metric | What it measures | Why it matters |
|---|---|---|
| Assessment coverage rate by tier | % of vendors with a current assessment, per tier | Surfaces gaps a blended average would hide |
| Assessment cycle time | Days from assessment start to close | Slow cycles mean vendors operate unassessed longer |
| Finding closure rate by severity | % of findings resolved, by severity | A high overall rate can hide open critical findings |
| SLA adherence rate | % of contractual commitments met | A leading signal of a vendor relationship drifting |
For the mechanics of actually running one of these reviews end to end, ComplyJet's help center has a dedicated walkthrough:
The Key Risk Indicators for Vendor Management That Actually Predict Trouble
Most public guides on vendor risk metrics, including the ones written by compliance-platform vendors, stop at generic procurement KRIs: on-time delivery, cost overruns, defect rates. Those matter for vendor performance. They don't measure security or compliance risk exposure, which is the category that actually matters heading into a SOC 2 audit.
The key risk indicators for vendor management worth tracking instead:
- Percentage of Tier 1 vendors below your minimum acceptable risk score. The single clearest exposure number, since it's the vendors with the most access and the most impact that this indicator is watching.
- Number of vendors with lapsed security certifications. A vendor whose SOC 2, ISO 27001, or equivalent attestation has expired is operating on an assumption you can no longer verify.
- Vendor risk score decline rate over a recent period. A vendor doesn't usually go from safe to a breach overnight. The score trending down over 90 days is the leading indicator that shows up before the incident does.
- Overdue remediation findings for Tier 1 vendors. Not just open findings, specifically the ones already past their agreed deadline on your highest-criticality vendors.
- Undisclosed fourth-party sub-processor exposure. Vendors that hand your data to their own subcontractors without disclosure.
Fourth-Party Risk Deserves Its Own Line Item
Fourth-party risk, the exposure created by your vendor's own vendors, rarely gets its own metric, and that's a real gap. A cloud infrastructure provider using a subprocessor for backups, a SaaS tool routing support tickets through a third-party helpdesk platform, a payment processor relying on a downstream fraud-detection vendor: all of these extend your actual risk surface past the vendor you signed a contract with.
Tracking "undisclosed fourth-party sub-processor exposure" as its own number, rather than folding it into a generic vendor-risk score, keeps this visible instead of buried inside an aggregate that looks fine on average.
What a SOC 2 Auditor Wants From Your Vendor Risk Management Metrics
SOC 2's Trust Services Criteria include a specific criterion for this: CC9.2, under the Risk Mitigation category, which requires an organization to identify, assess, and manage the risks that vendors and business partners introduce, on an ongoing basis, not just at onboarding.
An auditor testing CC9.2 isn't looking for a policy statement. They're looking for evidence the process ran, which means they'll typically ask for some combination of: the current vendor inventory with tiers assigned, proof that Tier 1 vendors were reassessed on the schedule your own policy commits to, an open findings list with remediation status, and confirmation that a vendor's own attestation (SOC 2, ISO 27001, or similar) is current rather than expired.
An auditor doesn't ask if you have a vendor risk policy. They ask you to pull up the register and show them the last three reassessments that were actually due. If the metric behind that isn't tracked, there's nothing to pull up. — Upendra Varma, CTO at ComplyJet
This is the piece most vendor risk metrics content skips: naming which specific number maps to which specific piece of audit evidence.
Assessment coverage rate by tier is the evidence for "vendors were assessed." Overdue remediation findings for Tier 1 vendors is the evidence for "risks identified were actually managed," not just logged. Vendors with lapsed certifications is the evidence an auditor will check directly, since a lapsed SOC 2 report on a critical vendor is often the first thing that gets flagged in a walkthrough.
The mapping below shows three of those metrics lined up against exactly what they prove during a walkthrough.
ISO 27001 asks a parallel question through its own supplier relationship controls (Annex A 5.19 through 5.23), so a program built around these metrics holds up under either framework, not just SOC 2.
What that looks like in practice, for a team that had none of this in place a few months earlier:
That's the same coverage-rate and lapsed-certification tracking covered above, just seen from the inside of a program that went from nothing to audit-ready.
A Vendor Risk Management Maturity Model in Three Tiers
Most vendor risk programs sit somewhere on a maturity curve, and knowing where helps decide which metric to add next rather than trying to track everything at once from day one.
The table below breaks each tier down further, including what's missing to move up a level.
| Tier | What it looks like | What's missing to move up |
|---|---|---|
| 1. Ad hoc | A spreadsheet, reassessment happens when someone remembers, no consistent metrics tracked | Vendor tiering and at least one coverage metric tracked on a schedule |
| 2. Tiered and scored | Vendors classified by criticality, KPIs tracked manually, reporting happens but isn't automatic | KRIs tracked alongside KPIs, and a defined reporting cadence to leadership |
| 3. Continuously monitored and audit-ready | KRIs tracked in near-real-time, metrics feed directly into audit evidence, lapsed certifications and score declines trigger action automatically | Ongoing refinement of thresholds as the vendor list grows |
Tier 3 is where this stops being a manual reporting exercise:
Vendor Risk Management Reporting: How Often to Update Leadership
Vendor risk management reporting works best on two different clocks. Operational metrics, the KPIs measuring whether the program is functioning, get reviewed by whoever owns vendor risk on a tight cycle, typically weekly or monthly. Leadership and the board don't need that level of detail or that frequency. A quarterly summary focused on KRIs, the handful of vendors trending toward risk, is the more useful cut for that audience.
Some events should trigger a report outside that normal cycle regardless of where you are in the quarter: a Tier 1 vendor's certification lapsing, a vendor disclosing a breach, or a risk score dropping sharply in a short window. Waiting for the next scheduled report to surface any of these defeats the purpose of tracking them as leading indicators in the first place.
How ComplyJet Helps With Vendor Risk Management Metrics
Vendor risk management is one part of ComplyJet's broader compliance-automation platform, not a standalone dedicated vendor-risk tool. It automatically builds a vendor inventory from connected integrations, tiers vendors by criticality and data access, sends automated assessment questionnaires with follow-up reminders, and flags real-time breach alerts for tracked vendors. Annual reassessment reminders keep Tier 1 vendors from quietly lapsing, and sub-processor tracking keeps fourth-party exposure visible instead of implicit.
When it's time to show an auditor the evidence behind CC9.2, or any equivalent ISO 27001 supplier-relationship control, that same data exports as an audit-ready vendor risk register, the metrics this article covers, generated as a byproduct of the workflow rather than assembled by hand the week before fieldwork.
Here's what running a vendor review actually looks like inside the platform:
That same review workflow is what feeds every KPI and KRI in the tables above, without a separate spreadsheet to keep in sync.
FAQs
What are vendor risk management metrics?
They're the measurements that show whether a vendor risk program is actually running and how exposed you currently are. KPIs cover the first question (coverage, speed, completion rates), KRIs cover the second (risk scores, lapsed certifications, overdue remediation).
What is the difference between vendor risk KPIs and KRIs?
A KPI measures how well the program operates, things like assessment cycle time or coverage rate. A KRI measures the risk itself, things like a vendor's score trending down or a certification lapsing. Both matter, but they answer different questions for different audiences.
Why is vendor risk management important to measure, not just document?
A policy with no metrics behind it can't prove the process actually ran. Auditors, and your own leadership, need a number showing vendors were assessed on schedule and findings were closed, not just a description of what's supposed to happen.
What is a vendor risk management maturity model?
A simple way to place your own program on a curve, from ad hoc (a spreadsheet, no consistent tracking) through tiered and scored (KPIs tracked, manual reporting) to continuously monitored and audit-ready (KRIs tracked in near-real-time, feeding directly into audit evidence).
What are key risk indicators for vendor management?
The metrics that show current exposure rather than program health: the percentage of Tier 1 vendors below your minimum risk score, vendors with lapsed certifications, score decline rate over a recent period, overdue remediation on your highest-criticality vendors, and undisclosed fourth-party exposure.
How often should vendor risk management metrics be reported?
Operational KPIs on a tight cycle, weekly or monthly, to whoever owns the program. KRIs summarized to leadership or the board quarterly. Certain events, a lapsed certification, a vendor breach disclosure, a sharp score decline, should trigger an off-cycle report regardless of the calendar.
What metrics do SOC 2 auditors want to see for vendor risk management?
Evidence tied to CC9.2: the current vendor inventory with tiers assigned, proof that Tier 1 vendors were reassessed on schedule, an open findings list with remediation status, and confirmation that vendor attestations like SOC 2 or ISO 27001 reports are current rather than expired.
Related Reading
- TPRM Lifecycle: The 5 Stages of Building a Vendor Risk Program, for building the program these metrics measure.
- Third-Party Risk Management Policy: Guide + Free Template, for the policy document and its SOC 2/ISO 27001 tie-in.
- How to Review a SOC 2 Report From a Vendor, for reading a single vendor's report in detail.
- SOC 2 Audit Process, Start to Finish, for how vendor risk evidence fits into the broader audit.
