The Vendor Security Questionnaire Is Not a Risk Assessment
Most companies that care about third-party risk send security questionnaires to their vendors. Most vendors that want the deal fill them out. Nobody is particularly well-served by the exchange.
The questionnaire lands in a shared inbox. Someone with a business development title and a general understanding of what "SOC 2" means fills in the answers. The answers go back through legal review, come out scrubbed of anything that could be interpreted as an admission, and land in a folder that qualifies as due diligence. The vendor keeps access to your data. You keep the folder. Neither of you is safer.
What a Questionnaire Actually Measures
A questionnaire measures whether a vendor knows the right words. "Do you have a vulnerability management program?" is a yes/no question. The vendor answers yes because they have something that could plausibly be described that way - maybe a scanner someone runs quarterly, maybe a Jira ticket from 2022 that technically constitutes a process. The answer is yes either way.
This is not the vendor lying. This is the questionnaire being poorly designed for the thing it claims to measure. A question that produces identical answers from a company with mature continuous vulnerability management and one with a stale spreadsheet is not gathering useful information. It is generating paperwork.
The questionnaire is a compliance artifact. It exists so the organization can show auditors that it performed vendor due diligence. The evidence of due diligence is the completed form. What the form reveals about actual vendor risk is largely incidental.
Why Vendors Answer the Way They Do
The people answering your questionnaire have correctly understood that their job is to close the deal, not to inform your risk management program. Every answer that raises a question extends the sales cycle. Every admission of a limitation is a word the legal team will review and the account executive will worry about.
Questionnaire automation tools make this structural problem worse. Vendors load answers once into a platform and fire those same responses at every customer who asks. The answers have been reviewed for liability, calibrated for minimum alarm, and standardized across all engagements. They have not been written to tell you anything specific about the vendor's current security posture.
Even without automation, the incentive to disclose as little as possible while appearing comprehensive is clear. You designed the questionnaire to gather information. The vendor is treating it as a negotiation.
What Risk You Are Actually Trying to Assess
Before redesigning a vendor risk program, it helps to be precise about what kind of risk you are worried about, because the forms are usually conflating several distinct things.
Data exposure: the vendor has access to your data, and a breach at their end becomes your incident. Most questionnaires aim at this one, badly.
Supply chain compromise: the vendor produces software or infrastructure you run, and a compromise of their build pipeline or distribution system becomes your compromise. SolarWinds was this. The XZ Utils backdoor discovered in 2024 was this. No questionnaire was going to surface either of those risks in advance.
Operational dependency: you rely on the vendor for business continuity, and their outage becomes yours. Often treated as a security risk by organizations that care about it, even though the security controls being assessed are not what drives this exposure.
The questions that matter for each of these risks are different. Treating them as one category and covering them with the same generic questionnaire guarantees partial coverage of all three.
What Actually Works
For data exposure risk, the only thing that tells you something real is documented evidence of controls reviewed by someone other than the vendor. SOC 2 Type II reports are imperfect, but they are produced by an auditor examining actual systems rather than by the vendor describing those systems from memory. If a vendor does not have a SOC 2 Type II or ISO 27001 certification, no questionnaire response they give you substitutes for one. Asking them to attest to controls a third party has not verified is asking them to grade their own work.
For supply chain risk, the right questions are operational, not attitudinal. How does the vendor build and distribute software? Do they sign releases? Do they have a published vulnerability disclosure process? Have they produced a software bill of materials? These questions have concrete answers that differ between vendors with mature practices and vendors without.
For your highest-stakes vendors - the ones with access to production data or with code running inside your environment - ask for penetration test executive summaries, not just confirmation that tests were performed. Have someone on your side read the SOC 2 report rather than file it.
What Questionnaires Will Never Tell You
A questionnaire cannot tell you about the vendor's security culture, which is the thing that actually predicts how they behave when something goes wrong. Do they have a responsible disclosure program? Have they had breaches, and if so, how did they handle notification and remediation? Does their security team have real authority, or are they the people who write questionnaire responses?
These answers exist, but not in the form. They live in public breach disclosures, in conversations with other customers, in what the vendor published when they had a bad week. Security culture is observable. It just requires looking somewhere other than the questionnaire.
The other gap: questionnaires are point-in-time. A vendor's posture when they filled out your form and their posture six months later may be different, and the form will not tell you about the change. Contract clauses requiring breach notification, monitoring for public disclosures, and annual review cycles are how you track drift. The completed form told you about last year's posture. Keeping track of this year's requires something the form was never designed to do.