Your Vendor Questionnaire Is Not Protecting You. Here Is the Proof
جدول المحتويات
Here is an uncomfortable truth that most TPRM vendors will not say out loud: the annual vendor questionnaire is the most expensive security theatre in enterprise cybersecurity today. Organisations sent questionnaires. Vendors filled them in. Breaches happened anyway. In 2025, 97% of organisations experienced at least one supply chain breach according to BlueVoyant’s survey of 1,800 executives, up from 81% the year before. In that same year, 95% of those same organisations increased their TPRM budgets. The math does not work. More investment, more breaches. Something structural is broken.
That something is the questionnaire model itself, and the data is not subtle about it.
The questionnaire captures what vendors choose to tell you
Only 4% of security teams have high confidence that their vendor questionnaires accurately reflect vendor security reality, according to research published in late 2025. The other 96% are making risk decisions on self-reported information they do not trust. A questionnaire asks a vendor whether they have a patch management process. The vendor says yes. What the questionnaire cannot ask, because it has no mechanism to verify the answer, is whether the vendor’s subcontractor in the third tier of the supply chain patched the MOVEit instance that was already being actively exploited.
Third-party breaches now account for 35.5% of all data breaches according to SecurityScorecard’s 2025 research, a figure that accelerated through the year. The dominant entry point is not the vendor you assessed. It is the vendor they rely on that you never knew existed.
The breach that came from a vendor you never hired
In December 2025, 700Credit disclosed a breach caused by unauthorised access to a third-party API, exposing the personal information of approximately 5.8 million individuals, including names, addresses and Social Security numbers. The entry point was not 700Credit’s own infrastructure. It was a connected vendor’s system accessed through a route nobody had mapped or monitored, sitting undetected for months before disclosure. No questionnaire sent to 700Credit’s direct vendors would have surfaced this, because the compromised system sat two tiers removed from any relationship that anyone had thought to assess.
61% of businesses admit they underestimate the importance of TPRM and acknowledge it was luck rather than their programmes that kept them from a major vendor-related breach last year, according to a KPMG study. That is not a gap in the questionnaire design. That is a fundamental mismatch between the tool and the threat environment it is meant to address.
The numbers nobody talks about
A half-day AWS outage in 2025 generated $581 million in insurance losses. The organisations caught in that disruption were not all AWS customers directly. Many were customers of vendors who were. Their dependency had never been mapped because the mapping had never been done. Most TPRM programmes assess vendors individually. They do not ask what those vendors have in common, which infrastructure they share, or what happens if three of them go offline at the same time because they all run on the same provider.
94% of companies are not assessing all the vendors they would like to because they lack the resources. 97% say they would do more in-depth assessments if they could. The average TPRM professional is responsible for assessing 33.6 vendors individually while managing relationships across an ecosystem that averages 286 vendors total. The arithmetic of quarterly assessments against a threat that moves on a four-day exploit timeline was never going to work.
The diagram above shows what changes
[See the comparison between compliance-driven and risk-driven TPRM in the diagram above.] The difference between a programme that catches vendor compromises early and one that discovers them through breach notification letters comes down to six things: continuous monitoring instead of periodic snapshots, tiering by actual risk instead of treating all 286 vendors identically, external threat intelligence that validates what vendors self-report, integration into security operations rather than procurement, outcome metrics instead of activity metrics, and explicit planning for nth-party exposure. None of these require exceptional resources. They require deliberate choices about what the programme is actually trying to accomplish.
The organisations running risk-driven TPRM report 60 to 80% reduction in alert volume through better signal-to-noise ratio and 30 to 50% faster incident response when vendor compromises occur. That is not a small marginal improvement. It is the difference between catching a vendor credential exposure on a dark web market on Tuesday night and discovering it in a breach disclosure letter three months later.
The regulatory picture is making this personal
Under NIS2, management bodies are explicitly responsible for compliance failures and can face temporary bans or disqualification from leadership roles. DORA requires senior leadership to maintain segregated ICT risk management frameworks. The SEC requires board-level cybersecurity governance disclosure in the United States. Forrester predicts that breach-related class-action costs will surpass regulatory fines by 50% in the coming year.
This matters for TPRM programme design because the question a regulator will ask after a supply chain breach is not whether the attack was sophisticated. It is whether the organisation had adequate, documented controls in place at the time, and whether those controls were genuinely designed to reduce exposure or to satisfy a compliance checkbox. The MORSECORP case from 2025 is instructive: a self-reported compliance score of 104, an independent review finding of negative 142, with only 22% of controls actually in place. Settlement: $4.6 million. The lesson is that self-reported posture means nothing without external verification.
What an effective programme actually looks like
The starting point is continuous external monitoring running alongside periodic deep assessments, not instead of them. A vendor whose credentials appear on a dark web forum on a Tuesday night should not stay undetected until next quarter’s review cycle. CybelAngel’s credential intelligence monitors dark web markets and closed channels continuously, surfacing vendor credential exposures before attackers can use them, and giving security teams the window between exposure and exploitation that annual assessments cannot provide.
The second step is extending programme scope to the nth-party layer. Primary vendors should be contractually required to disclose material subcontractor dependencies, and external scanning should be used to identify concentration risks across the extended supply chain. The most damaging supply chain breaches of 2025 originated two, three and four tiers deep in vendor ecosystems, well beyond the reach of any direct assessment process. CybelAngel’s third-party risk management capabilities extend visibility across the vendor ecosystem, combining automated detection with human validation to cover the exposure that questionnaires cannot reach.
The one question your programme needs to answer
Not “did we send questionnaires to all our direct vendors?” That question has a comfortable answer and a useless one. The right question is: “If a vendor two tiers into our supply chain was compromised last Tuesday night, would we know by Wednesday morning?”
For most programmes, the honest answer is no. That is the gap worth closing.
For the complete data picture across the threat environment, regulatory landscape and what effective TPRM programmes look like in practice, download the CybelAngel TPRM report: Every Vendor Is a Vector.
عن المؤلف
