The Questionnaire Problem
Every organization with a procurement process has some version of third-party risk management. For most, it looks like this: before onboarding a new software vendor, send them a security questionnaire. The vendor spends a week (or a month) filling it out. Someone on the security team reviews the responses, checks a few boxes, assigns a risk rating, and files it away. Repeat annually.
This process is almost entirely performative.
Questionnaires capture a vendor's security posture at a single point in time, as described by the vendor themselves. They don't verify claims. They don't monitor for changes. They don't catch the vendor whose environment was secure during assessment but got compromised three months later. The SolarWinds breach — where a trusted vendor's software update mechanism was weaponized — demonstrated exactly how badly this model fails.
The question isn't whether you need third-party risk management. You do. The question is whether your TPRM program actually reduces risk, or just generates paperwork.
What Questionnaires Miss
Self-Reported Data Is Unreliable
Vendors filling out questionnaires have every incentive to present their security posture favorably. That doesn't mean they're lying. It means they're answering based on their own interpretation of questions, their awareness of their own environment, and their understanding of what the questions are really asking. A vendor can truthfully say "we encrypt data at rest" while running an unpatched database server with default credentials exposed to the internet.
Point-in-Time Assessment
A questionnaire completed in January tells you nothing about the vendor's security posture in July. Between assessments, the vendor might change cloud providers, suffer a breach they haven't disclosed, fire their security team, or introduce a new product built on a completely different stack. Annual reassessments create 364 days of uncertainty.
No Supply Chain Depth
When you assess Vendor A, you're typically evaluating their security practices in isolation. But Vendor A depends on Vendor B's infrastructure, Vendor C's authentication service, and Vendor D's CDN. Your actual risk surface extends through your vendor's entire supply chain. The SolarWinds breach wasn't a direct attack on SolarWinds' customers — it was an attack on SolarWinds that propagated through their software updates to 18,000 downstream organizations.
Questionnaire Fatigue
Vendors — especially popular SaaS companies — receive hundreds of security questionnaires annually. The result is predictable: standardized responses that get copy-pasted across questionnaires regardless of context. The security team at a 50-person SaaS startup doesn't have time to write thoughtful, custom responses to 200 different questionnaires. They create a master document and paste from it.
Building a TPRM Program That Works
Effective third-party risk management requires moving beyond questionnaires as the primary control. Here's what a functional program looks like:
Tier Your Vendors by Actual Risk
Not all vendors carry the same risk. A SaaS tool that processes your customer data deserves more scrutiny than the vendor that provides your office plants. But most TPRM programs apply the same assessment process to every vendor, regardless of data access, integration depth, or business criticality.
Build a tiering model based on:
- Data sensitivity — Does the vendor access, process, or store sensitive data (PII, PHI, financial records, source code)?
- Integration depth — Is the vendor's software embedded in your product? Does it have access to your production environment? Does it run in your CI/CD pipeline?
- Business criticality — If this vendor goes down or is compromised, what's the blast radius? Can you switch to an alternative quickly?
- Regulatory exposure — Does using this vendor implicate specific compliance obligations (HIPAA, PCI DSS, SOX)?
Tier 1 vendors (high data access, deep integration, business critical) get intensive assessment and continuous monitoring. Tier 3 vendors (low data access, peripheral, easily replaceable) get a lightweight review and periodic check-in.
Demand Technical Evidence, Not Narratives
Replace open-ended questionnaire responses with verifiable evidence:
- SOC 2 Type II reports — Not just the opinion letter. Read the detailed descriptions of controls and any exceptions noted.
- Penetration test results — Not the executive summary. The actual findings, remediation status, and retest results.
- SBOM for vendor products — If a vendor is shipping software that runs in your environment, request a Software Bill of Materials. This is increasingly feasible post-EO 14028, and vendors who can't produce one are telling you something about their software development practices.
- Vulnerability management metrics — Mean time to remediation. Vulnerability density trends. Patch cadence. These are concrete and harder to fake than narrative responses.
- Incident history — Not "have you had a breach?" but "what incidents have you experienced in the past 24 months, and how did you respond?"
Implement Continuous Monitoring
Point-in-time assessments need to be supplemented with continuous signals:
External attack surface monitoring — Services like SecurityScorecard, BitSight, and RiskRecon provide continuous scoring of your vendors' external security posture. These tools have real limitations (they can't see internal controls), but they catch obvious failures like exposed databases, expired certificates, and unpatched public-facing services.
Breach notification monitoring — Track public breach disclosures, regulatory filings, and dark web mentions related to your vendors. If your Tier 1 vendor shows up in a data breach notification, you shouldn't find out from the news.
SBOM monitoring — If you have SBOMs from your vendors, monitor them for newly disclosed vulnerabilities. When Log4Shell dropped, organizations with vendor SBOMs could immediately determine which vendors were running vulnerable versions of Log4j. Organizations without SBOMs had to send emergency questionnaires and wait for responses.
Contractual obligations — Build security requirements into vendor contracts: breach notification timelines, right-to-audit clauses, minimum security standards, SBOM delivery requirements. Contracts are enforceable. Questionnaire responses are not.
Assess the Supply Chain, Not Just the Vendor
Your vendor's security depends on their vendors' security. While you can't infinitely recurse through supply chain relationships, you can:
- Ask Tier 1 vendors about their own TPRM program
- Request information about critical subprocessors and fourth parties
- Require notification when a vendor changes key infrastructure providers
- Include supply chain security requirements in contracts
The goal isn't perfect visibility into every vendor's vendor. It's understanding the critical paths where compromise could propagate to your environment.
The Software Vendor Dimension
Software vendors present unique risks compared to service providers. When you buy software — whether it's a SaaS product, an on-premise application, or a library you integrate into your own code — you're accepting that vendor's development practices, dependency choices, and security culture into your environment.
Evaluating Software Development Practices
For software vendors specifically, assess:
- Secure development lifecycle — Do they follow documented secure coding practices? NIST SSDF compliance is a reasonable baseline.
- Dependency management — How do they manage open-source dependencies? Do they monitor for vulnerabilities in their supply chain?
- Build integrity — Can they demonstrate that their build pipeline hasn't been tampered with? SLSA framework compliance is emerging as a standard here.
- Vulnerability response — How quickly do they patch vulnerabilities in their products? What's their disclosure policy?
- SBOM availability — Can they provide an SBOM for their product? Will they commit to updating it with each release?
The Update Mechanism Risk
SolarWinds proved that software update mechanisms are a high-value target. When you install a vendor's software and enable auto-updates, you're granting that vendor's build pipeline implicit trust to execute code in your environment. Evaluate:
- Is the update signed? With what key management practices?
- Can you verify update integrity independently?
- Is the update channel encrypted?
- Can you control update timing (to test before deploying)?
Measuring TPRM Effectiveness
A TPRM program that generates reports but doesn't change outcomes is overhead, not risk management. Measure:
- Coverage — What percentage of your vendors (by tier) have been assessed in the current period?
- Finding remediation — When you identify a risk with a vendor, how often is it actually remediated? How long does it take?
- Incident correlation — When vendor incidents occur, did your TPRM program identify the risk beforehand?
- Decision influence — How often has TPRM assessment actually changed a procurement decision?
If your TPRM program has a 100% vendor approval rate, it's not managing risk. It's rubber-stamping.
Regulatory Drivers
The regulatory landscape is pushing TPRM from "best practice" to "requirement":
- EO 14028 mandates SBOM requirements for federal software vendors
- NIST SP 800-161 provides supply chain risk management guidance for federal agencies
- NYDFS Cybersecurity Regulation requires covered entities to assess third-party service provider security
- DORA (EU) introduces ICT third-party risk management requirements for financial entities
- PCI DSS 4.0 strengthens requirements for third-party service provider monitoring
The trend is clear: regulators expect organizations to know what risks their vendors introduce and to actively manage those risks. Questionnaires alone won't satisfy the next generation of regulatory scrutiny.
How Safeguard.sh Helps
Safeguard's TPRM capabilities give you continuous visibility into your software vendors' security posture. Request and monitor vendor SBOMs, track vulnerabilities in vendor-supplied software, and get alerted when a vendor's components are affected by newly disclosed CVEs. Instead of annual questionnaires that tell you what a vendor's security looked like last quarter, Safeguard shows you what it looks like right now.