Your vendor completed the risk questionnaire. They answered yes to “do you have an information security policy,” yes to “do you encrypt data at rest,” and yes to “have you had a security incident in the past twelve months.” You reviewed the responses, noted no red flags, and approved the vendor.
Six months later, the vendor’s support portal — which has access to your customer records — gets compromised. The attacker used credentials stolen from an employee who reused their password across personal accounts. The vendor’s SOC 2 Type II report did not cover the support portal.
The questionnaire was accurate. It told you almost nothing useful.
What Questionnaires Actually Measure
A vendor security questionnaire measures the vendor’s ability to complete questionnaires. That sounds cynical, but it is operationally true.
Questionnaire responses are typically produced by vendor compliance teams, legal teams, or sales engineers. These people are skilled at producing responses that are technically accurate and appropriately reassuring. “We encrypt data at rest using AES-256” is a defensible answer that tells you nothing about key management, access controls, or which data stores that encryption actually covers.
Organizations that send questionnaires and review responses have created a process that generates artifacts. Those artifacts satisfy audit requirements for vendor due diligence. They do not necessarily produce understanding of vendor security posture.
The Scope Problem Nobody Names
The most persistent problem with vendor risk assessments is scope definition. The questionnaire covers the vendor’s primary product and the systems directly involved in your contract. It does not cover:
The integrations the vendor uses to build their product. The third-party components embedded in their platform. The customer support tools their team uses to handle your tickets. The development environment where your data flows during troubleshooting. The employee laptops that have access to your tenant.
None of these are unusual scope gaps. They are consistent gaps that exist in nearly every vendor relationship assessed via questionnaire. The vendor answers questions about their production environment, which is often their most controlled environment. The blast radius of a vendor compromise frequently runs through adjacent systems that nobody asked about.
SOC 2 reports have the same limitation. The audit scope is whatever the vendor and auditor agreed to include. The report tells you what was reviewed. It does not tell you what was excluded.
The Response Verification Gap
Questionnaire responses are self-reported. Most organizations do not have the resources or access to verify them. You ask a vendor if they perform penetration testing annually. They say yes. You note the response. You move on.
Some programs request supporting documentation — penetration test reports, vulnerability scan outputs, policy documents. This is better. The vendor’s penetration test report shows you what was tested and what was found, which is more informative than a yes/no response. But a penetration test report from eighteen months ago, covering a scope that excluded the customer-facing portal, does not tell you whether that portal has been patched recently.
The gap between “vendor provided documentation” and “documentation accurately represents current security posture” is where most vendor compromises live.
Risk Tiering That Doesn’t Match Blast Radius
Most vendor risk programs tier vendors by data sensitivity and criticality. Critical vendors with access to sensitive data get enhanced due diligence. Low-risk vendors with no data access get a lighter process.
The problem is that blast radius does not reliably map to data sensitivity. A low-risk productivity tool that employees use across devices can be a lateral movement vector. A vendor that doesn’t handle customer data but does have VPN access to your network is not low risk. A supplier with no data access but whose software runs on production systems is not low risk.
Tiering by data classification is a reasonable starting point and a poor finishing point. The vendors that have caused the largest organizational incidents are frequently ones where the risk assessment concluded “limited data exposure” without fully characterizing what access the vendor relationship actually entailed.
What Better Looks Like
Effective vendor risk programs share a few characteristics that questionnaire-only programs lack:
They define scope before sending questionnaires. What systems does this vendor touch? What access do their employees have? What integrations does their platform use? Scope definition surfaces the questions worth asking.
They validate controls at the highest-risk integration points. Not everything needs validation, but the vendor’s production API access to your customer data does. Periodic review of access logs, connection inventory, and authentication methods costs effort. It costs less than an undiscovered breach.
They establish contractual security requirements with teeth. The right to audit, breach notification timelines, and scope of security controls required under the contract are more useful than asking vendors to self-certify.
Bottom Line
Vendor risk questionnaires are a compliance artifact that happens to generate some useful information if you already know which questions matter. Treating the completed questionnaire as risk management is how organizations end up surprised by compromises at vendors they assessed and approved.
The question is not whether your vendor completed the questionnaire. The question is whether you understand what they have access to and whether you would know if something went wrong.