Why a Clean Vendor Security Questionnaire Doesn't Mean Your Vendor Is Patched
A vendor security questionnaire is self-attested, so it records what a vendor says about its controls, not what an independent test found. Questionnaires and SOC 2 reports also describe a closed audit period, while a vendor's internet-facing attack surface changes daily. Confirming a vendor's current exposure requires observation of their live external footprint, not attestation.
A procurement team sends a 180-question vendor security questionnaire. Six weeks later it comes back complete, every answer favorable, a SOC 2 Type II report attached. The vendor is approved. The file closes. Nobody asks the obvious follow-up: who checked?
That is the structural weakness in most third-party risk programs, and it is not a paperwork complaint. It is a measurement problem. A vendor security questionnaire measures what a vendor is willing to assert. Your actual exposure depends on what is running on their internet-facing systems right now. Those two things drift apart quietly, and the drift is where breaches happen.
The 2026 Verizon Data Breach Investigations Report found that third-party components were involved in 48% of confirmed breaches, a 60% increase year over year, across more than 22,000 confirmed breaches [1]. The same report found that only 23% of third-party organizations fully remediated missing or improperly secured multi-factor authentication on cloud accounts after the gap was identified [1]. Read those two findings together and the picture is uncomfortable: third parties are now the dominant breach pathway, and when a real gap is found in a third party, most of the time it stays open.
In our assessments at Clone Systems, we consistently find that a vendor's questionnaire and a vendor's external attack surface tell different stories. The questionnaire says patch management is documented and enforced on a 30-day cycle. The scan finds a management interface on a non-standard port running a version with a known-exploited CVE from eighteen months ago. Neither party is lying. The questionnaire was answered accurately by someone in compliance describing the policy. Nobody in the loop was in a position to observe the exception.
What Does a Vendor Security Questionnaire Actually Measure?
A vendor security questionnaire measures attestation. Someone at the vendor, usually in compliance or sales engineering rather than in operations, reads a control statement and answers whether the organization does that thing. There is no adversarial step. There is no independent observation. There is no requirement that the person answering has ever seen the system in question.
That is a legitimate instrument for some purposes. It surfaces vendors who have no security program at all, it creates a contractual record you can point to later, and it forces a conversation. NIST's Cybersecurity Framework 2.0 added supply chain risk management as a dedicated category under the Govern function (GV.SC), which reflects how central this has become to how programs are structured [2]. But the framework asks you to manage supplier risk. It does not tell you that a questionnaire is sufficient evidence that you have.
The Audit Period Problem
A SOC 2 Type II report is stronger evidence than a questionnaire because an independent auditor tested controls over a defined window. The catch is in the words "defined window." A report delivered in August 2026 typically covers an audit period that ended months earlier. It is a statement about a stretch of past time.
Meanwhile the 2026 DBIR put the median time to patch a vulnerability at 43 days in 2025, up from 32 days the year before, and found that only 26% of vulnerabilities in CISA's Known Exploited Vulnerabilities catalog were remediated last year, down from 38% in 2024 [1]. A control that was operating effectively throughout an audit period that closed in March tells you very little about a host that was exposed in July.
The Scope Problem
Both instruments are also bounded by scope, and scope is chosen by the vendor. A SOC 2 report covers a defined system boundary. A questionnaire covers whatever the questions ask about. Neither is designed to catch a dependency, a subprocessor, or an integration path that sits outside the boundary the vendor drew.
We wrote previously about how PCI DSS segmentation testing validates the walls while leaving integration doors unexamined (the integration access gap that PCI segmentation testing often misses). Vendor questionnaires have the same shape of blind spot, one layer further out.
Why Do Vendors With Clean Questionnaires Still Get Breached?
Because attestation and exposure are measured differently, and the vendors most likely to hold a clean attestation are also the most attractive targets.
Black Kite's 2026 Third-Party Breach Report, its seventh annual edition, analyzed 136 verified third-party incidents from 2025 affecting 719 publicly named victim companies plus roughly 26,000 additional impacted organizations that were never disclosed [3]. The average number of downstream victims per breach reached 5.28, the highest the report has ever recorded and more than double the 2.56 average in 2024 [3].
The most useful finding in that report, for anyone running a vendor review process, concerns the top 50 most widely shared vendors across the Forbes Global 2000. These are the suppliers with the largest security teams, the most mature compliance functions, and the most polished questionnaire responses. Black Kite found that 84% of them had at least one critical vulnerability with a CVSS score of 8 or higher, 70% had exposure to a vulnerability in CISA's Known Exploited Vulnerabilities catalog, 62% had corporate credentials appearing in infostealer logs, and 52% had a documented breach history, with 18% breached within the past year [3].
Every one of those vendors can produce a clean questionnaire. Most can produce a SOC 2 Type II. The attestation is accurate about the program. It is silent about the exposure.
The Vendor Is Often Not the Target
There is a further problem that no questionnaire is structured to catch. In August 2026, CloudSEK published an analysis of a supply chain compromise affecting LiteLLM, a widely used AI infrastructure component, in which the reconstructed exposure dataset covered more than 2,500 companies and an estimated 434,000 CI/CD pipelines [4]. LiteLLM itself was never attacked directly. Its build pipeline installed a security scanner unpinned from the system package manager, that scanner had been compromised upstream through a leaked automation token, and the poisoned build flowed downstream automatically. The malicious payload executed on package install rather than on import, and the exposure window for the affected releases was roughly 40 minutes [4].
A questionnaire that asks your vendor about their patch cadence, their access controls, and their incident response plan would return clean answers on all three. None of those questions reach a dependency of a dependency in a build pipeline.
What Can You Verify About a Vendor Without Their Cooperation?
More than most organizations realize. A vendor's external attack surface is, by definition, externally visible. You do not need their permission to observe what they are publishing to the internet, and you do not need to wait for their next audit cycle.
The Clone Systems Four-Signal Vendor Verification Check
Before you accept a vendor attestation as evidence, check these four signals against their internet-facing footprint. Each one is observable, each one is dated to today rather than to a closed audit period, and each one corresponds directly to a control most questionnaires ask about.
1. Transport and certificate hygiene. Are their public endpoints still negotiating deprecated TLS versions or weak cipher suites? Are certificates current, correctly installed, and issued by a recognized authority across every exposed hostname, not just the marketing site? A questionnaire question about encryption in transit is answered "yes" almost universally. This is the observable version of that question.
2. Exposed administrative and management interfaces. Admin consoles, database management tools, remote access services, and non-standard management ports reachable from the public internet are among the most consistent findings in our external scanning work, and they are the single clearest contradiction of an attested least-privilege access policy.
3. Known-exploited vulnerability exposure. Cross-reference the software and versions their exposed services disclose against CISA's Known Exploited Vulnerabilities catalog. Black Kite found 70% of the most widely shared vendors carrying KEV exposure [3], and KEV membership means exploitation has been observed in the wild, not theorized.
4. Credential exposure in public breach and infostealer data. Corporate credentials for the vendor's domain appearing in stealer logs indicate compromised endpoints inside their environment, which no questionnaire will ever surface. Black Kite found this in 62% of top shared vendors [3].
A vendor who returns a clean questionnaire and clears all four signals has given you two independent forms of evidence that agree. A vendor who returns a clean questionnaire and fails two of the four has given you a conversation to have before renewal, not after an incident.
Not sure whether your critical vendors would clear those four signals today? Clone Systems runs external vulnerability scanning and security assessments that measure a vendor's live exposure rather than their attested posture. Contact us at clonesystems.com/contact to discuss a third-party exposure review.
How Often Should Vendor Security Be Re-Checked?
Annually is the default in most programs, and the data suggests annually is the wrong cadence for anything material.
Black Kite recorded a median intrusion detection time of 10 days across incidents with timeline data, but a median disclosure delay of 73 days and an average disclosure lag of 117 days [3]. That is the gap between a vendor knowing and you knowing. Layer an annual questionnaire on top of a roughly four-month average disclosure lag and a 43-day median patch time [1], and the honest description of most vendor review programs is that they sample a fast-moving signal about once a year and treat the sample as a state.
The practical answer is to separate the two activities rather than trying to make the questionnaire do more work. Keep the annual questionnaire and SOC 2 review for what they are good at: governance, contractual record, and program-level assurance. Add continuous or quarterly external observation of the vendors whose compromise would actually matter to you. This is the same coverage-versus-cadence problem we have written about in the context of your own environment (what your vulnerability scan misses between scans), applied one step outward.
Tiering helps here. Most organizations have somewhere between five and fifteen vendors whose compromise would be a genuine incident, and several hundred that would be an inconvenience. Continuous external monitoring of the first group is achievable. Applying it to all of them is not, and trying is how programs end up doing neither well.
Test Your Own Vendor List: Three Questions
Before your next vendor review cycle, ask your team these three questions.
- For your five most critical vendors, when did the audit period of their most recent SOC 2 report actually end? Not when the report was delivered. If the answer is more than six months ago for any of them, you are relying on evidence about a period that has closed.
- Has anyone independently observed any of those vendors' external footprints, ever? If the only evidence in the file is documents the vendor produced about themselves, you have attestation with no corroboration.
- If a critical vendor were compromised today, how would you find out, and how long would it take? If the honest answer is "they would tell us," the median disclosure delay in the 2025 data was 73 days [3].
A "no" or an uncertain answer to any of these is a finding, independent of what any questionnaire says.
How Clone Systems Can Help
Clone Systems is a PCI Approved Scanning Vendor and Managed Security Services Provider, which means the work of independently observing what an organization is actually exposing to the internet is the core of what we do every day. We apply the same discipline to third-party exposure.
Our external vulnerability scanning identifies the deprecated protocols, expired certificates, exposed management interfaces, and known-exploited vulnerabilities that sit on a vendor's internet-facing systems regardless of what their questionnaire says (vulnerability scanning services). Our penetration testing services validate whether the access paths those findings create are genuinely exploitable, including the integration and API pathways that connect a vendor into your environment (penetration testing services).
For organizations formalizing a third-party review process, we run cybersecurity gap analyses that evaluate supplier risk management against NIST CSF 2.0, ISO 27001, and CIS Controls v8, and produce a prioritized remediation roadmap with named owners rather than a document that sits in a folder (cybersecurity gap analysis).
If your vendor files contain attestation and nothing else, that is the gap worth closing before an incident closes it for you. Learn more at clonesystems.com or contact our team.
Frequently Asked Questions
Are vendor security questionnaires effective? Vendor security questionnaires are effective at establishing a contractual record and identifying vendors with no security program, but they are self-attested and therefore cannot confirm that a control is operating today. They should be paired with independent observation of the vendor's external attack surface rather than treated as standalone evidence.
Can a SOC 2 report replace a vendor security questionnaire? A SOC 2 Type II report is stronger evidence than a questionnaire because an independent auditor tested controls, and many organizations accept one in place of the other. It still describes a closed audit period and a vendor-defined system boundary, so it does not tell you what the vendor's current exposure looks like.
How do you verify a vendor's security questionnaire answers? The answers that can be verified without the vendor's cooperation are the ones about their internet-facing systems: TLS and certificate configuration, exposed administrative interfaces, known-exploited vulnerabilities in disclosed software versions, and corporate credentials appearing in public breach or infostealer data. Answers about internal controls generally require an audit report or a right-to-audit clause.
How often should you reassess third-party vendors? Annual questionnaire and audit-report review remains a reasonable governance cadence, but critical vendors should be observed externally on a continuous or quarterly basis. Black Kite's 2026 data put the median disclosure delay for third-party breaches at 73 days, which is far longer than an annual review cycle can absorb.
What percentage of data breaches involve a third party? The 2026 Verizon Data Breach Investigations Report found third-party components involved in 48% of confirmed breaches, a 60% increase over the prior year. That figure reflects breaches where a supplier, partner, or shared service was part of the incident chain, not only breaches that originated at the vendor.
Conclusion
The vendor security questionnaire is not the problem. Treating it as proof is. It is a governance artifact that records what a vendor is prepared to assert, and it does that job adequately. It was never designed to tell you whether a management console is exposed on a vendor's edge today, and the 2026 data on third-party breach frequency, downstream cascade, and disclosure delay says that is now the question that matters most.
The fix is not a longer questionnaire. It is a second, independent form of evidence that is dated to today and does not depend on the vendor to produce it. If your critical vendor files contain attestation and nothing else, Clone Systems can help you see what an attacker already can. Start the conversation at clonesystems.com.
References
[1] Verizon — 2026 Data Breach Investigations Report. Verizon, May 2026. https://www.verizon.com/business/resources/reports/dbir/
[2] NIST — Cybersecurity Framework 2.0, Govern function, Cybersecurity Supply Chain Risk Management category (GV.SC). National Institute of Standards and Technology, 2024. https://www.nist.gov/cyberframework
[3] Black Kite — 2026 Third-Party Breach Report (seventh annual edition), March 2026. https://blackkite.com/reports/third-party-breach-report-2026
[4] CloudSEK — LiteLLM Supply Chain Attack: 2,500+ Companies Exposed, August 2026. https://www.cloudsek.com/blog/ai-supply-chain-breach-2500-companies-434000-cicd-pipelines
[5] Clone Systems — In our external scanning and assessment work, a vendor's questionnaire response and their live external attack surface routinely disagree, most often on patch currency and on management interfaces exposed to the public internet, because the person answering the questionnaire is describing the policy rather than observing the exception.
[6] Clone Systems — What a Cybersecurity Gap Analysis Actually Reveals (That Your Annual Audit Misses). clonesystems.com/blog/cybersecurity-gap-analysis
[7] Clone Systems — Why Passing Your PCI Scan Won't Get You a Better Cyber Insurance Rate. clonesystems.com/blog/why-passing-your-pci-scan-wont-get-you-a-better-cyber-insurance-rate
[8] Clone Systems — Vulnerability Scanning Services. clonesystems.com/vulnerability-scanning