TPRM metrics and KPIs: what to measure, and which numbers to retire

A metric earns a place on a TPRM dashboard if someone would make a different decision depending on its value. By that test, a surprising share of common vendor-risk reporting fails. "Questionnaires sent this quarter" goes up when the team works harder and when the program is failing to prioritize. "Average vendor security rating" can sit flat at a comfortable number while one critical vendor degrades. Neither tells a risk committee whether to change anything.

The standards that address measurement are consistent on the discipline, if not on the specific numbers. NIST SP 800-55 Volume 1 is built around identifying and selecting information security measures that connect to objectives and support decisions, and ISO/IEC 27004 likewise treats measurement as a means of evaluating whether the security program is effective, not a reporting exercise in its own right. Neither document hands you a list of TPRM KPIs; what follows is a practitioner selection, organized by the question each group answers.

Start with the question, not the metric

Four questions cover what a risk committee needs from a vendor program. Each one maps to a small set of measures.

Coverage: the denominator problem

Every percentage on a TPRM dashboard has a denominator, and the denominator is usually the weakest number in the program. "98% of vendors assessed" means little if the inventory only contains the vendors procurement happened to onboard. Shadow SaaS, departmental purchases and acquired-company vendors sit outside it.

• Inventory completeness. Estimate it by reconciling the vendor list against an independent source - accounts-payable spend, SSO application catalogue, expense data - and report the unmatched share. It will not be zero; the trend matters more than the level. See vendor tiering for why this feeds everything below.
• Tiering coverage. Percent of inventoried vendors with an assigned tier and a documented rationale. An untiered vendor is by definition unassessed in proportion to its risk.
• Critical-vendor assessment currency. Of the vendors in your top tier, the percent whose last full assessment falls inside the policy window. Report this for the top tier only; blending tiers lets a long tail of low-risk vendors hide a handful of overdue critical ones.
• Fourth-party visibility. For critical vendors, the percent with a documented subprocessor list reviewed in the last cycle. See fourth-party risk. Regulators ask for this explicitly: the Register of Information under DORA exists to give supervisors an accurate view of ICT third-party dependencies, so for in-scope firms its completeness is itself a coverage metric.

Timeliness: measure the gaps, not the averages

Averages flatter a program with a long tail. A mean onboarding time of ten days is compatible with a handful of vendors that went live eight weeks before anyone looked at them. Report a median and a worst-case (90th percentile or maximum), and report them by tier.

• Onboarding cycle time, by tier. Time from intake request to approved decision. The number to watch is how many vendors went live before the decision - a control failure, not a speed problem.
• Time to re-assess after a trigger. Acquisition, breach disclosure, material scope change or a new integration should each open a reassessment. Measure the lag between the trigger and the reassessment starting. This is the metric that distinguishes calendar-driven programs from continuously monitored ones.
• Questionnaire turnaround. Useful as a diagnostic on your own process rather than on vendors: a long median usually points at questionnaire design, not vendor reluctance. See why manual assessment stalls.

Evidence quality: how much of the picture is verified

This is the family most programs do not measure at all, and the one a sceptical auditor will probe first. A completed questionnaire is a vendor's own account. A SOC 2 or ISO 27001 certificate is independent assurance over a defined scope and period. Externally observed signal is a third kind of evidence. The share of your critical-tier assurance that rests on each is a meaningful number.

• Verified-versus-attested ratio. For critical vendors, the percent of assessed controls backed by independent evidence (an audit report with matching scope, a validated artefact, an observed external signal) rather than a self-declared answer alone. See automated evidence collection.
• Scope-match rate. Of the audit reports on file, the percent whose stated scope actually covers the service you consume. A SOC 2 for a different product line counts as no evidence for yours. See SOC 2 in vendor assessment.
• Stale-evidence rate. The percent of evidence past its useful life - a report whose period ended more than twelve months ago, a certificate past expiry, an attestation with no bridge letter.

Outcomes: whether risk is moving

Outcome measures are the hardest to define and the most worth the effort, because they are the ones that show the program changing exposure rather than generating paper.

• Aged open findings by severity and tier. Count findings open beyond their SLA, grouped by severity and by vendor tier. A flat total can hide a growing critical backlog; the age profile cannot.
• Remediation SLA attainment. Of findings that came due in the period, the percent closed or formally risk-accepted on time. Pair it with the number of risk acceptances and who signed them - an SLA met by accepting everything is not a result.
• Known-exploited exposure. For internet-facing vendor assets you can observe, how many carry a vulnerability that appears in CISA's Known Exploited Vulnerabilities catalog, and how long they stay that way. CISA's BOD 22-01 binds federal agencies, not your vendors, but its remediation-by-date logic is a sound template for a vendor SLA on this specific class.
• Time to scope a vendor breach. When a vendor discloses an incident, how long until you can say which of your data, systems and business services it touches. Rehearse this: the number you get in a tabletop is more honest than the one in a policy. See incident response automation.
• Vendor-originated incidents. Incidents whose root cause or entry point was a third party, tracked as a count and as a share of all incidents. Small numbers make this noisy as a quarterly trend, but it is the figure that connects the program to business impact.
• Offboarding completion. Of vendors whose contracts ended in the period, the percent with confirmed access revocation and data return or destruction. See vendor offboarding.

Numbers worth retiring

• Raw counts of activity (assessments completed, questionnaires sent, vendors in the system). They measure effort and reward volume over prioritization.
• A portfolio-average security rating. Averaging across a large portfolio dilutes exactly the tail you care about. If you use outside-in ratings, track the number of critical vendors that dropped below a threshold or fell by more than a set amount in a period, not the mean. See security ratings versus evidence-based TPRM.
• Questionnaire completion rate used as a vendor-quality signal. A vendor that returns a questionnaire quickly has told you about its sales process.
• A single composite program score. One blended number hides which family is failing and invites tuning of the formula to move the figure.

Definitions that keep metrics honest

• Write the definition down - numerator, denominator, data source, owner, refresh cadence - and keep it stable. Changing a definition mid-year without restating the history breaks the trend.
• Report by tier, never blended. The 2023 interagency guidance on third-party relationships expects oversight commensurate with risk, which is what tiered reporting demonstrates.
• Separate leading from lagging. Coverage and timeliness are leading indicators; incidents are lagging. A program needs both, and should be suspicious of one improving while the other does not.
• Attach a threshold and an action to every metric: at what value does something change, and who decides. A metric with no trigger is a decoration.
• Be explicit about estimates. Inventory completeness and fourth-party visibility are partly estimated. Say so on the dashboard; a board forgives a labelled estimate and not a number that later proves to be soft.

A starter set

Programs that try to track thirty measures usually maintain none of them. A defensible starting set is small:

1. Inventory completeness estimate (coverage)
2. Percent of critical vendors with a current assessment (coverage)
3. Median and worst-case time to re-assess after a trigger event (timeliness)
4. Verified-versus-attested ratio for critical vendors (evidence quality)
5. Critical and high findings past SLA, with age profile (outcomes)
6. Time to scope a vendor breach, from the last exercise (outcomes)

Add measures when a specific decision needs one, not because a platform ships a widget for it.

Talk to an expert about the metrics in this guide.

Frequently asked questions