The KRIs in this domain measure whether your TPRM program is providing genuine risk signal or generating compliance artifacts. The distinction is critical: a questionnaire completed by a vendor's security team and returned to your procurement team is evidence of process, not evidence of security posture. What produces risk signal is continuous monitoring, contract security requirements with teeth, and a tiering model that concentrates your assessment resources where the actual risk is concentrated.
If you are standing this up from scratch, start with how to build a KRI program and the consolidated KRI reference library, which maps every domain to one CIS-aligned catalog.
KRI inventory
1. Vendor tier coverage and assessment currency
What to measure. Percentage of vendors in each tier with a security assessment completed within the tier-appropriate cycle, Tier 1 (critical vendors with data access or operational dependency) within 12 months, Tier 2 (significant vendors) within 24 months, Tier 3 (low-impact vendors) within 36 months or at onboarding.
Why it matters. Assessment currency is the most fundamental TPRM metric. A vendor assessed three years ago may have had significant security program changes, leadership turnover, or a breach that wasn't disclosed. Stale assessments provide false confidence, you're making risk decisions based on a snapshot of a posture that may no longer exist.
- TPRM platform (ProcessUnity, Prevalent, OneTrust TPRM, Draxis): vendor inventory with tier classification and last assessment date
- Procurement/vendor management system: active vendor roster cross-referenced with TPRM platform
- Contract management: vendor contracts with data access or critical service classification
- Security ratings platform (BitSight, SecurityScorecard): last assessed date and current score per vendor
How to calculate. Per tier: (Vendors with assessment within tier-appropriate cycle) ÷ (total vendors in tier) × 100
| Status | Criteria |
|---|---|
| Green | >95% Tier 1 current; >85% Tier 2 current; all Tier 1 vendors with continuous monitoring active |
| Amber | 80–94% Tier 1; or Tier 2 assessment cycle slipping to 30+ months |
| Red | <80% Tier 1; or any Tier 1 vendor with data access unassessed for >24 months; or no formal vendor tiering |
2. Vendor security ratings and posture trend
What to measure. Distribution of external security ratings (BitSight, SecurityScorecard, or equivalent) across your Tier 1 and Tier 2 vendor portfolio, and the trend in those ratings over the trailing 12 months.
Why it matters. Security ratings provide continuous external validation of vendor posture without requiring the vendor's cooperation. A vendor's rating declining while their questionnaire answers remain positive is a meaningful signal, and one that most questionnaire-only programs miss entirely.
- BitSight for Third Parties: security rating per vendor, grade distribution, rating history, issue categories contributing to score
- SecurityScorecard: vendor portfolio scorecard, grade changes, factor breakdown
- RiskRecon: detailed technical findings per vendor without vendor engagement
- TPRM platform integration: ratings APIs fed into vendor risk records automatically
How to calculate.
- Portfolio distribution: percentage of Tier 1/2 vendors in each rating band (A/B/C/D/F or equivalent)
- Declining vendors: count of Tier 1 vendors with rating decline >10 points in trailing 90 days
- Below-threshold vendors: count of Tier 1 vendors below your defined minimum acceptable rating
| Status | Criteria |
|---|---|
| Green | >80% of Tier 1 vendors in "A" or "B" rating band; declining vendors flagged and reviewed within 30 days; minimum rating threshold defined and enforced at onboarding |
| Amber | 60–79% of Tier 1 in acceptable rating band; or declining vendor alerts reviewed >30 days |
| Red | <60% of Tier 1 in acceptable band; or no continuous ratings monitoring; or vendors below threshold retained without documented risk acceptance |
3. Fourth-Party risk concentration
What to measure. The degree to which your critical vendors share common sub-processors, infrastructure providers, or software dependencies, specifically, the number of Tier 1 vendors that share a single critical sub-processor whose failure or compromise would produce correlated loss across multiple vendors simultaneously.
Why it matters. Fourth-party risk is the supply chain risk beneath your supply chain risk. The CrowdStrike event was a fourth-party event for many organizations, their security vendor was a vendor to their security vendor. MOVEit was similarly a sub-processor used by dozens of vendors simultaneously. Concentration in shared sub-processors is the mechanism behind systemic supply chain incidents.
- Vendor security questionnaires: sub-processor disclosure sections
- TPRM platform: sub-processor inventory fields
- Vendor contracts: data processing agreements with sub-processor lists (GDPR DPAs require this disclosure)
- Threat intelligence: vendor technology fingerprinting, shared software components across vendor portfolio
How to calculate.
- Shared sub-processor concentration: for each sub-processor used by >2 Tier 1 vendors, flag as concentration risk
- Single-point-of-failure sub-processors: those used by >5 Tier 1 vendors with no alternative
- Portfolio coverage: (Tier 1 vendors with documented sub-processor inventory) ÷ (total Tier 1 vendors) × 100
| Status | Criteria |
|---|---|
| Green | >90% of Tier 1 vendors with sub-processor inventory; no single sub-processor shared by >3 Tier 1 critical vendors without documented contingency |
| Amber | Sub-processor inventory incomplete; or known concentration without mitigation plan |
| Red | Single sub-processor shared by >5 Tier 1 vendors; or major cloud/software provider concentration with no contingency; or no sub-processor visibility |
4. Vendor breach and incident notification rate
What to measure. Rate at which vendors in your portfolio notify you of security incidents, breaches, or material security events affecting your data or service dependency, compared against incidents discovered through external sources rather than vendor notification.
Why it matters. Vendors who notify you promptly when they have security incidents are vendors you can manage risk with. Vendors you discover have been breached from a news article, or whose breach you discover during a customer security review, are vendors who either lack the detection capability to know they've been breached or have chosen not to notify you. Both are material risk signals.
- TPRM platform: incident notification records per vendor
- Threat intelligence feed: breach intelligence for vendors in your portfolio
- News monitoring (Google Alerts, threat intel platforms): vendor breach news cross-referenced against vendor roster
- DPA/contract: documented notification obligation timelines per vendor
How to calculate.
- Notification compliance rate: (Breach events where vendor notified within contractual window) ÷ (total breach events involving portfolio vendors) × 100
- Self-discovery rate: (Incidents discovered through external sources rather than vendor notification) ÷ (total incidents) × 100, this rate should be low
| Status | Criteria |
|---|---|
| Green | >90% of incidents notified within contractual window; low self-discovery rate; notification obligations in all Tier 1 contracts |
| Amber | 70–89% notification compliance; or notification obligations missing from some Tier 1 contracts |
| Red | <70% compliance; or recurring pattern of self-discovery rather than vendor notification; or no contractual notification requirements |
5. Vendor contract security requirements coverage
What to measure. Percentage of active vendor contracts in each tier that include defined security requirements, minimum control standards, breach notification timelines, audit rights, and data handling obligations, commensurate with the vendor's access and risk level.
Why it matters. Without contractual security requirements, you have no mechanism for enforcing vendor security standards and no recourse when a vendor's failure exposes your data. Contracts are the governance layer that makes vendor risk management binding rather than advisory.
- Contract management system (Ironclad, DocuSign CLM, Agiloft, SharePoint): contract inventory with security clause presence
- Legal team review: contract clause analysis, security requirements, notification windows, audit rights, liability provisions
- Procurement process: security review sign-off as a contract approval gate
- DPA registry: data processing agreements for all vendors processing personal data
How to calculate. (Contracts with security requirements + notification obligation + audit right) ÷ (total contracts in scope for security requirements) × 100 Scope: all contracts where vendor has data access or operational dependency
| Status | Criteria |
|---|---|
| Green | >95% of Tier 1 contracts with all three elements; 100% have DPAs where personal data is processed; security requirements in procurement template for all new contracts |
| Amber | 80–94%; or DPAs present but security requirements absent; or audit rights not contractually established for Tier 1 vendors |
| Red | <80%; or Tier 1 vendors with data access and no contractual security obligations; or no DPAs for vendors processing personal data |
6. Vendor access offboarding timeliness
What to measure. Average hours from vendor relationship termination (contract end, project completion, or vendor offboarding initiation) to confirmed revocation of all system access granted to vendor personnel and systems.
Why it matters. Terminated vendor access is a direct insider threat vector. A vendor whose contract ended six months ago but whose service account still has database access is a privileged, unmonitored credential with no legitimate owner. Vendor offboarding is frequently slower than employee offboarding because no single team owns it end-to-end.
- Vendor management system: vendor offboarding events and dates
- Identity provider: service accounts and federated identities associated with vendor organizations, last disable date
- PAM platform: vaulted vendor credentials, last rotation or disable date post-offboarding
- Network access control: VPN access profiles for vendor personnel, revocation logs
- Procurement/legal: contract end dates as offboarding trigger
How to calculate. (Access revocation date) − (Vendor offboarding initiation date), averaged across offboarding events Critical gap: active vendor access for vendors with terminated contracts, count should be zero
| Status | Criteria |
|---|---|
| Green | Access revoked within 24 hours of offboarding initiation; automated offboarding trigger from vendor management system; zero active access for terminated vendors |
| Amber | 24–72 hours; or manual process without automated trigger |
| Red | >72 hours; or any active access for terminated vendors discovered; or no formal vendor offboarding process |
7. Critical vendor resilience and concentration risk
What to measure. Percentage of critical business functions dependent on a single vendor with no tested alternative or fallback, and whether those vendors have documented incident response plans, SLAs, and recovery commitments that have been reviewed.
Why it matters. Vendor concentration risk is not just about security incidents, it's about operational resilience. A vendor outage, whether security-related or operational, that stops your business from functioning is a business risk regardless of cause. Concentration in critical functions is the risk that organizations most commonly discover for the first time during an incident.
- Business impact analysis (BIA): critical business functions and their single-vendor dependencies
- Vendor contracts: SLA commitments, recovery time obligations, force majeure clauses
- Vendor security assessments: business continuity and disaster recovery sections
- Procurement: sole-source vendors in the contract inventory, flags concentration without requiring BIA
How to calculate. (Critical business functions with single-vendor dependency and no documented fallback) ÷ (total critical business functions) × 100 Also: vendor SLA coverage rate, critical vendors with reviewed, contractual recovery commitments
| Status | Criteria |
|---|---|
| Green | Zero undocumented single-vendor critical functions; all Tier 1 vendors with reviewed recovery commitments; concentration risks on roadmap for mitigation |
| Amber | 1–2 single-vendor critical functions with mitigation plans in progress |
| Red | >2 undocumented single-vendor critical functions; or major operational dependency with no SLA or recovery commitment reviewed |
Deriving these KRIs by source type
From TPRM Platforms (ProcessUnity, Prevalent, OneTrust)
- Assessment currency: Filter vendor records by
last_assessment_date < (TODAY - tier_cycle_days)per tier, surface overdue assessments - Finding remediation: Vendor findings with open status and past-due remediation commitments, vendor accountability tracking
- Workflow metrics: Assessment completion rate, average assessment cycle time, vendor response rates
From Security Ratings (BitSight, SecurityScorecard, RiskRecon)
- Portfolio score distribution: API:
GET /portfolio/companieswith rating and grade fields, aggregate distribution - Score alerts: Webhook/API polling for score changes >10 points for Tier 1 vendors, trigger review workflow
- Issue category breakdown: Which security categories (application security, network security, patched systems) are driving low scores, prioritize remediation conversations with vendors
From Contract Management Systems
- Security clause presence: Tag or custom field on contracts indicating security requirements status, query for Tier 1 contracts missing the tag
- DPA registry: Filter active contracts involving personal data; cross-reference DPA execution date
- Contract expiry calendar: Upcoming contract renewals, trigger reassessment before renewal rather than during
From Identity and Access Management
- Vendor service accounts: Filter identity provider for accounts associated with vendor email domains or labeled as vendor service accounts; cross-reference against active vendor roster
- Vendor federated access: AWS IAM roles with trust policies to vendor AWS accounts; Azure B2B guest users from vendor domains; cross-reference against active vendor list
- Last access date: Vendor accounts with no activity in >30 days post-contract end, orphaned vendor access
From Threat Intelligence Platforms
- Vendor breach intelligence: Query threat intel feeds for breach disclosures involving companies in your vendor portfolio; compare disclosure date to notification received date
- Dark web monitoring: Monitor paste sites and dark web forums for vendor-related credential leaks or data exposure, many threat intel platforms support organization-specific monitoring
- Vendor technology stack risk: Threat intel on vulnerabilities in software your vendors are known to use, proactive fourth-party risk signal
Draxis turns these KRIs into a live signal
Draxis connects to the tools you already run (security ratings, vendor inventories, and access governance tooling) and computes these third-party risk KRIs automatically, with the green/amber/red bands, trend lines, and drift alerts described above. No spreadsheets, no manual stitching.
See how Draxis reads your stack →