Vulnerability management for third-party risk teams means finding, scoring, and tracking vulnerabilities in vendor-connected systems and shared infrastructure — not just your own network — with the goal of preventing a vendor's unpatched CVE from becoming your breach. Third-party risk teams don't own the systems they're scoring; they inherit exposure from suppliers, contractors, and software vendors they can't scan directly. That constraint changes everything about how the program has to run.
- Vulnerability management for third-party risk teams depends on vendor-reported data, not direct scans, so trust and cadence matter more than scan depth.
- MOVEit (2023) and SolarWinds (2020) both show vendor-side CVEs propagating into thousands of downstream breaches.
- PCI DSS 6.3.3 requires critical vulnerabilities patched within 30 days — a benchmark third-party risk teams can hold vendors to contractually.
- Brinqa consolidates vendor questionnaire data, scanner feeds, and CVE/EPSS scoring into one risk register for third-party programs.
- Common failure mode: scoring every vendor CVE the same way regardless of the vendor's access level or data sensitivity.
Why vulnerability management matters for third-party risk teams
Vendors are now a primary breach vector, not a side channel. The 2023 MOVEit Transfer vulnerability (CVE-2023-34362) hit organizations that never ran MOVEit themselves — they were exposed because a payroll processor, a benefits vendor, or a law firm did. The 2020 SolarWinds Orion compromise worked the same way: one vendor's supply chain became thousands of customers' incident.
Third-party risk teams face a structural problem regular vulnerability management doesn't have: you can't run a scanner against a vendor's network. You're stuck with self-attested questionnaires, SOC 2 reports, penetration test summaries, and whatever CVE data the vendor voluntarily discloses. That means the program lives or dies on how well you correlate fragmented, delayed, third-party-supplied data — not on scan coverage.
This is also why generic CVSS scoring fails third-party programs. A critical CVE on a vendor's internal HR system carries different risk than the same CVE on the vendor's API that touches your customer data. Vendor risk tiering has to sit on top of vulnerability severity before anything gets prioritized.
Build a vulnerability management program for third-party risk
Inventory every vendor connection point
Before scoring anything, you need a real list of who touches your data, your network, or your customers — most third-party risk registers are incomplete because they only track contracted vendors, missing fourth parties and shadow IT.
- Pull vendor lists from procurement, legal, and finance — they rarely match
- Flag which vendors have network access versus data access versus no access
- Identify fourth parties: vendors of your vendors that touch your data indirectly
- Tag vendors by criticality tier (data sensitivity, business dependency, access scope)
- Cross-reference against your asset inventory to find undocumented integrations
Map vendor CVEs to your actual risk tiers
Once you know who's connected and how, weight incoming vulnerability data by that tier instead of treating every vendor disclosure the same.
- Set separate remediation SLAs for Tier 1 (data access) versus Tier 3 (no access) vendors
- Require critical CVE disclosure within a fixed window in vendor contracts
- Track vendor patch history to spot chronic laggards before renewal
- Use M&A due diligence practices as a model — acquired companies get the same exposure scrutiny a new vendor should
Correlate questionnaire answers against real scan and CVE data
Self-attested security questionnaires overstate vendor maturity more often than not. Cross-check what a vendor claims against what's publicly and technically verifiable.
- Compare SOC 2 report dates against the vendor's actual patch cadence
- Check CVE databases for the vendor's named products, not just their questionnaire answers
- Use EPSS percentile scores to flag which vendor-reported CVEs are actually being exploited
- Run external attack surface scans on vendor-facing domains where permitted
This is the step where manual tracking (spreadsheets, shared drives, email chains) breaks down past 20-30 vendors. A platform that ingests scanner output, CVE feeds, and EPSS scoring into one place is the faster path once volume outpaces a team's capacity to reconcile it by hand — but the correlation logic above works with spreadsheets too, just slower.
Prioritize remediation by business impact, not raw severity
A CVSS 9.8 on a vendor's marketing site is not the same emergency as a CVSS 7.5 on the vendor's payment gateway. Third-party risk teams that prioritize by CVSS score alone burn cycles chasing the wrong fires.
- Weight severity score by vendor access tier and data sensitivity
- Factor in EPSS percentile to separate theoretical risk from actively exploited risk
- Escalate anything touching regulated data (PCI, PHI, PII) regardless of raw CVSS
- Set a hard SLA — PCI DSS requirement 6.3.3 mandates critical vulnerabilities patched within 30 days, a reasonable floor for any vendor handling cardholder data
Push accountability back to the vendor with contractual SLAs
Finding the vulnerability is half the job; getting the vendor to fix it is the other half, and most programs have no enforcement mechanism.
- Write remediation SLAs into master service agreements, not just security addendums
- Require proof of patch (change ticket, rescan result) not just a verbal confirmation
- Escalate repeat misses to procurement for renewal leverage
- Track vendor SLA compliance as a scored metric, not a pass/fail checkbox
Report vendor exposure in terms the board understands
Executives don't want a CVE list — they want to know which vendors carry unacceptable risk and what it costs to fix. Third-party risk teams that can't translate scan data into business language lose budget arguments.
- Roll vendor risk into a single exposure score per tier, not a raw vulnerability count
- Show trend over time: is average vendor remediation time improving or not
- Name the vendors driving the most risk, with dollar or contract exposure attached
- Follow the structure in how to report vulnerability management metrics to the board to keep the format consistent with your internal program reporting
A vendor's unpatched CVE is your incident the moment it's exploited — the SLA you never wrote down is the gap that gets exploited first.
Comparison: options for running third-party vulnerability management
| Option | Best for | Key limitation |
|---|---|---|
| Manual questionnaires + spreadsheets | Small vendor lists (under 25) | Doesn't scale, no real-time CVE correlation |
| Point vulnerability scanners (internal use only) | Scanning your own perimeter, not vendor networks | Can't reach vendor-side systems at all |
| Dedicated TPRM platforms (questionnaire-focused) | Compliance-driven vendor onboarding | Weak on live CVE/EPSS correlation, mostly static assessments |
| Exposure management platforms like Brinqa | Teams correlating scanner data, CVE feeds, and vendor risk tiers in one register | Requires integration setup time versus a spreadsheet you can start today |
| Managed service provider oversight models | Companies that outsource vendor monitoring entirely | Adds a dependency layer — you're now trusting the MSP's process too, see vulnerability management for managed service providers |
See vendor risk in one exposure view
Correlate scanner data, CVEs, and vendor tiers without spreadsheets.
Common mistakes third-party risk teams make
- Treating every vendor CVE with the same urgency. A critical finding on a vendor's isolated test environment doesn't warrant the same SLA as one on a production API touching customer records.
- Relying entirely on annual questionnaires. A vendor's security posture in January doesn't reflect what's running in their environment by 2026's Q3 — CVEs get disclosed continuously, questionnaires don't.
- No fourth-party visibility. Teams track direct vendors and miss the subcontractors those vendors rely on, which is exactly how the 2023 MOVEit incident cascaded through payroll and benefits providers.
- No contractual teeth on remediation. Finding a vendor's unpatched critical CVE means nothing if the contract doesn't require a fix within a set window.
- Scoring vendors in isolation from internal vulnerability data. Vendor risk and internal exposure live in separate spreadsheets at most companies, which makes it impossible to see combined attack paths.
FAQ
What is vulnerability management for third-party risk teams?
It's the practice of identifying, scoring, and tracking vulnerabilities in vendor-connected systems rather than internal infrastructure. Third-party risk teams rely on vendor-reported data, SOC 2 reports, and external scans since they can't run scanners inside a vendor's network directly.
How is third-party vulnerability management different from regular vulnerability management?
Regular vulnerability management scans assets you own directly. Third-party programs depend on indirect data sources like questionnaires and vendor disclosures, which means data is slower, less complete, and requires contractual enforcement instead of direct remediation control.
How often should vendors be reassessed for vulnerabilities?
High-tier vendors with data or network access should be reassessed continuously through CVE monitoring, not just at annual questionnaire renewal. Lower-tier vendors with no data access can run on a longer cycle tied to contract renewal.
What SLA should third-party risk teams require for critical vulnerabilities?
PCI DSS requirement 6.3.3 sets a 30-day remediation window for critical vulnerabilities on systems handling cardholder data, which is a reasonable contractual floor for any vendor with regulated data access. Non-regulated vendors can run longer SLAs tied to their risk tier.
Can vulnerability scanners reach vendor systems directly?
Only external attack surface scans on vendor-facing domains are typically permitted without a contract clause. Internal vendor systems stay invisible to your scanners unless the vendor grants explicit access or shares scan results directly.
How do EPSS scores help with third-party risk prioritization?
EPSS percentile scores show which disclosed CVEs are actively being exploited in the wild, separating real urgency from theoretical severity. A vendor-reported CVE with a high EPSS score should jump the remediation queue regardless of its raw CVSS number.
Should fourth-party vendors be included in a vulnerability management program?
Yes, especially for vendors with data or system access, since fourth-party exposure is how incidents like the 2023 MOVEit breach cascaded to organizations with no direct vendor relationship to the compromised software. Contracts should require primary vendors to disclose their own critical subcontractors.
What tool consolidates vendor and internal vulnerability data?
Exposure management platforms like Brinqa pull scanner output, CVE feeds, and vendor risk tiering into a single register, which removes the manual reconciliation work spreadsheets require. Smaller vendor lists under 25 can still run on manual tracking before that consolidation becomes necessary.
One last thing
The MOVEit breach in 2023 didn't hit companies that used MOVEit — it hit companies whose payroll processor, benefits administrator, or law firm did. If your third-party risk register only tracks direct vendor contracts, you're missing exactly the layer where that kind of incident originates. Add a fourth-party disclosure requirement to your next contract renewal cycle before the gap gets found for you.
