# 16. Third-Party Risk Management

Supply chain compromise has gone from an edge case to one of the dominant attack vectors of the last five years. Yet most TPRM programs are still built around the same questionnaire-and-spreadsheet model that existed before SolarWinds. Let's fix that framing.

Context: Third-Party Risk Management (TPRM) is the discipline of understanding and managing the security risk that vendors, suppliers, partners, and service providers introduce into your environment. The scope has expanded dramatically:

• Traditional TPRM, sending security questionnaires to vendors, reviewing responses, filing them, and forgetting about them until next year's audit.
• Modern TPRM, continuous monitoring of vendor security posture, tiered risk-based assessment depth, contractual security requirements, supply chain attack surface management, and fourth-party risk (your vendors' vendors).

The threat landscape forcing this evolution:

• SolarWinds (2020), software supply chain compromise via a trusted vendor's build process; 18,000 organizations received malicious updates.
• Kaseya VSA (2021), MSP software compromise leading to downstream ransomware at hundreds of organizations through a single vendor.
• MOVEit (2023), single vulnerability in a widely used managed file transfer tool, exploited at scale across hundreds of organizations simultaneously.
• XZ Utils (2024), multi-year social engineering of an open-source project maintainer to insert a backdoor into widely deployed Linux infrastructure.

The pattern: attackers have figured out that targeting your vendors is often easier than targeting you. Every vendor with privileged access, software installed in your environment, or data you've shared is a potential entry point.

The market spans:

• Security ratings / continuous monitoring, BitSight, SecurityScorecard, Black Kite. Passive external scanning to measure vendor security posture.
• TPRM workflow platforms, ProcessUnity, Prevalent, Archer, OneTrust, Whistic. Questionnaire management, workflow, and tracking.
• Integrated platforms, Panorays, Bitsight (full platform), RiskRecon (acquired by MasterCard). Combining ratings with assessment workflow.
• Contract and procurement integration, Increasingly, TPRM is being embedded into procurement and legal workflows rather than existing as a standalone security function.

The core question for any TPRM investment: "Do we actually understand what risk our vendors introduce, or do we have evidence that vendors told us they're secure?"

14 Questions to Ask TPRM Vendors (and Yourself)

1. "What's the difference between a vendor completing your questionnaire and a vendor actually being secure, and how does your platform help me understand that gap?"
Why: This is the original sin of TPRM. Questionnaires measure what vendors say about their security. External ratings measure what's observable about their security posture. Neither measures what's actually happening inside their systems. Mature TPRM acknowledges this gap and helps triangulate across evidence types.
Good answer: Multi-source evidence model, questionnaire responses + external ratings + attestations + contract rights + findings from engagement. Red flag: "Our questionnaires are comprehensive and cover all major frameworks."

2. "How do you tier vendors by risk, and how is that tiering built, maintained, and challenged?"
Why: Not all vendors deserve the same scrutiny. A vendor with access to PII, admin credentials, or critical infrastructure warrants deep assessment. A vendor supplying office coffee deserves less. Without explicit, defensible tiering, TPRM programs either waste resources over-assessing low-risk vendors or under-assess high-risk ones, often both simultaneously.
Good answer: Risk-based tiering with defined criteria (data access, network access, business criticality, regulatory scope), automated tier suggestions with human review, periodic re-tiering as vendor relationships evolve. Red flag: "We send all vendors the same questionnaire."

3. "How do you handle continuous monitoring, between annual assessments, how do I know if a vendor's posture has significantly changed?"
Why: Annual assessments are snapshots. A vendor who was secure in January may have had a breach in March that you won't hear about until next January, or never. Continuous external monitoring of observable security signals (open ports, certificate issues, dark web mentions, patch cadence) provides an early warning layer that point-in-time assessments can't.
Good answer: Continuous external scanning and alerting, threshold-based re-assessment triggers, breach monitoring and vendor notification correlation. Red flag: "Our annual assessment cycle covers your requirements."

4. "Show me what your platform actually monitors externally, and be honest about what it can't see."
Why: External security ratings are useful but limited. They observe what's visible from the internet, which is genuinely valuable but represents a fraction of a vendor's internal posture. A vendor can have excellent external posture and terrible internal hygiene. Honest platforms acknowledge this; dishonest ones claim their ratings predict everything.
Good answer: Clear documentation of what's measured (internet-facing infrastructure, certificate health, web application security, email authentication, data breach detection) and explicit acknowledgment of what's not visible (internal network, endpoint security, access management). Red flag: "Our security score predicts breach likelihood with X% accuracy."

5. "How do you handle questionnaire fatigue, for my team sending them, and for vendors completing them?"
Why: Questionnaire fatigue is real on both sides. Security teams spend enormous time sending, chasing, and reviewing questionnaires. Vendors receive dozens of questionnaires per year, often with 200-500 questions each, and provide generic, copy-pasted responses that take 15 minutes to write and hours for you to review. The signal-to-noise ratio is poor.
Good answer: Questionnaire exchange networks (vendors complete once, share with multiple customers), adaptive questionnaires based on vendor tier and existing evidence, automation for common framework mappings (SOC 2, ISO 27001 as evidence substitutes). Red flag: Long, undifferentiated questionnaires as the primary mechanism.

6. "How do you handle fourth-party risk, your vendors' vendors, the dependencies underneath your direct suppliers?"
Why: SolarWinds introduced the concept at scale: you trusted the vendor, the vendor trusted their software build infrastructure, the build infrastructure was compromised. Your due diligence on the direct vendor told you nothing about the risk two layers down. Fourth-party visibility is genuinely hard and most platforms address it poorly.
Good answer: Automated discovery of vendor technology stacks, fourth-party dependency mapping, alerts when significant upstream dependencies have incidents. Red flag: "We focus on direct vendor risk" (honest, but be aware of the gap).

7. "What contractual controls does your platform help me establish and enforce, beyond questionnaires?"
Why: Questionnaires are a snapshot. Contracts are enforceable. The most mature TPRM programs embed specific security requirements into vendor contracts, incident notification timelines, right-to-audit clauses, minimum security control requirements, and subcontractor flow-down requirements. The platform should help you build and track these.
Good answer: Contract clause libraries, minimum security requirement templates by vendor tier, right-to-audit tracking, breach notification requirement monitoring. Red flag: "We handle the assessment side; contracts are your legal team's domain."

8. "How do you handle vendor incidents and breaches, notification, impact assessment, and response coordination?"
Why: When a vendor has a breach, the immediate questions are: are we affected? What data do they have of ours? What access do they have to our systems? What's the regulatory notification implication? Mature TPRM platforms support this response workflow; immature ones leave you manually tracking down vendor contacts in a spreadsheet during a crisis.
Good answer: Breach alerting integrated with your vendor inventory, impact assessment workflow, vendor contact directory, regulatory notification timeline support. Red flag: "We monitor for vendor breaches and notify you" (check: what do they monitor, and how fast?).

9. "How do you manage vendors with privileged access, those with credentials into your environment, remote access tools, or software agents installed on your systems?"
Why: Not all vendor risk is data risk. Some vendors have credentials, remote access tools, or installed software that represents a direct attack surface into your environment, MSPs, IT service providers, software vendors with auto-update capabilities, monitoring agents. This is a different and higher-risk category that most TPRM programs treat the same as a paper questionnaire vendor.
Good answer: Explicit privileged vendor tier with enhanced controls, session monitoring, just-in-time access, code signing verification, access review cadence. Red flag: Treating all vendors identically regardless of access depth.

10. "How do you handle open-source software dependencies, the XZ Utils problem, the Log4j problem, as a vendor risk category?"
Why: The software supply chain extends beyond your direct vendors into the open-source ecosystem that underpins most modern software. Log4j affected millions of applications because it was a dependency that nobody tracked. XZ Utils demonstrated that open-source projects can be compromised through social engineering of maintainers over years. Most TPRM platforms don't address this at all.
Good answer: SBOM (Software Bill of Materials) requirements in vendor contracts, open-source component monitoring, integration with SCA (Software Composition Analysis) tools. Honest acknowledgment if the platform doesn't cover this. Red flag: "Our vendor questionnaires include software security questions" (not the same thing).

11. "How do you handle vendor offboarding, revoking access, recovering data, confirming deletion?"
Why: Vendor offboarding is the most neglected phase of TPRM. Access credentials that weren't revoked, data that wasn't returned or destroyed, contractual data deletion obligations that weren't verified, these are where post-relationship risk lives. The number of organizations with active credentials for vendors they stopped using years ago is staggering.
Good answer: Offboarding workflow with access revocation checkpoints, data return/deletion verification, credential audit integration, documentation retention. Red flag: "We focus on onboarding and ongoing monitoring."

12. "What frameworks and regulations does your platform map to, and how do you handle divergent requirements across jurisdictions?"
Why: TPRM requirements vary significantly by regulation: DORA (EU financial services), HIPAA Business Associate requirements, GDPR Article 28, NIS2, NCUA, NY DFS, all have specific third-party obligations. A platform that only maps to one or two frameworks creates gaps for regulated companies operating across jurisdictions.
Good answer: Multi-framework mapping, jurisdiction-specific templates, regulatory update notifications. Red flag: "We cover all major compliance frameworks" (ask: which ones, how, and how recently updated?).

13. "What does the human effort look like to run this program, FTEs, process owners, stakeholder dependencies across procurement, legal, and IT?"
Why: TPRM is a cross-functional discipline. The platform is maybe 30% of the program; the rest is relationship management, stakeholder engagement, contract negotiation, and ongoing monitoring review. Vendors systematically underestimate the human cost. Ask for real FTE estimates from customers your size.
Good answer: Honest FTE estimates, stakeholder map including non-security owners (procurement, legal, business owners), scaling model. Red flag: "Our automation dramatically reduces the manual effort" (it does, from enormous to large).

14. "If I leave you, what happens to my vendor inventory, assessment history, risk records, and contract documentation?"
Why: TPRM data is longitudinal, assessment history, risk trends, audit evidence, contract records. Losing this in a vendor switch creates compliance gaps and destroys institutional knowledge of vendor risk history. Data portability in TPRM is genuinely important.
Good answer: Full export capability, open formats, assessment history preservation, contractual data access rights. Red flag: "Our platform is your system of record" (with no exit story).

The Meta-Test

• Q1 and Q4 are the honesty test. A vendor who conflates questionnaire completion with actual security assurance, or security ratings with complete visibility, is overselling their product's value.
• Q2 and Q9 are the risk-proportionality test. Not all vendors are equal. If your TPRM treats your MSP with admin credentials the same as your cleaning company, the program is providing false comfort.
• Q6 and Q10 are the modern supply chain test. If the platform has no answer to fourth-party risk and open-source dependency risk, it was designed for a threat landscape that no longer exists.

Honest Observations

1. Most TPRM programs are compliance theater. The few that aren't share three characteristics.

The average TPRM program sends questionnaires, receives questionnaire responses, files questionnaire responses, and reports a "vendor assessment completion rate" to the audit committee. This is, with respect, not risk management. It is risk documentation that exists to satisfy an auditor, not to actually understand or reduce risk.

The TPRM programs that actually work share these traits:

• Risk-based tiering that's genuinely enforced, high-risk vendors get substantively different treatment, not just a longer questionnaire.
• Integration with access management, vendor risk findings trigger actual changes in access controls, not just tracking in a spreadsheet.
• Business owner accountability, the business owner who relies on each vendor is accountable for that vendor's risk, not just the security team.

Without all three, you have a compliance artifact, not a risk program.

2. Your most dangerous vendors are almost certainly not your most assessed ones.

The most dangerous vendors in most environments are the ones with privileged access, installed software, or remote connectivity, MSPs, IT service providers, software vendors with update mechanisms, monitoring agents, development platforms. These are often the least scrutinized in TPRM programs because they're long-established relationships with trusted IT-managed vendors that predate the TPRM program.

A practical starting exercise: list the ten vendors with the deepest access to your environment (credentials, installed agents, remote access) and compare that to the ten most recently assessed vendors. The overlap is usually minimal. That gap is where your real supply chain risk lives.

3. The questionnaire business model has a fundamental problem, it measures trust, not security.

A vendor who completes your questionnaire accurately is demonstrating honesty and administrative process adherence. That's genuinely valuable. But it tells you almost nothing about whether their MFA is enforced, whether their development pipeline is compromised, or whether their admin credentials have been harvested.

The triangulation model, questionnaire + external ratings + attestations (SOC 2, ISO 27001) + contractual requirements + periodic sampling, is more accurate than any single signal. The honest framing: attestations are the most reliable signal (independent validation), external ratings give you continuous updates, questionnaires provide specifics that neither covers.

4. Vendor contract language is underused and undervalued.

Most TPRM programs treat the questionnaire as the primary mechanism and the contract as legal boilerplate. The most effective programs invert this: the contract is the mechanism, the questionnaire validates compliance.

Key contractual provisions that mature TPRM programs include: incident notification within 72 hours (mirroring GDPR timing), right to audit with reasonable notice, mandatory minimum controls by vendor tier, subcontractor flow-down requirements, and data deletion verification on contract termination. Get these in before you need them, not after.

5. For "regular" mid-market companies, the practical starting point:

Most mid-market organizations should resist the temptation to buy a platform before they understand their own vendor inventory. The right sequence:

1. Build the inventory, who are all your vendors? Which ones have credentials, installed software, data, or network access? This exercise alone often produces surprises.
2. Tier by actual risk, not by contract value or relationship length, but by access depth and data exposure.
3. Focus on the top 10-20 highest-risk vendors, do meaningful assessment work there before spreading thinly across hundreds.
4. Establish minimum contractual requirements, get security provisions into new and renewing contracts now.
5. Then evaluate platforms, once you understand your program needs, you'll buy the right tool for your maturity level.

Buying a TPRM platform to manage 50 questionnaire responses a year is expensive spreadsheet replacement. Buying one to manage a mature, tiered program with continuous monitoring is genuinely valuable.