The Third-Party Risk Questionnaire: What to Ask and Why
TL;DR · the short version
A third-party security questionnaire collects a vendor's self-reported security posture as the first step of due diligence. Done well it is a fast filter for where evidence and deeper review are needed; done badly — a 300-question spreadsheet sent to every supplier — it produces fatigue, rushed answers and false assurance. The fix is scoping to the vendor's risk tier, asking questions that map to real controls (data handling, access, compliance, incident response, sub-processors), and turning answers into decisions. Frameworks like SIG or CAIQ help.
The security questionnaire is the workhorse of third-party risk management, and also its most abused tool. Sent thoughtfully, it is a fast filter that tells you which vendors need a closer look. Sent as a 300-question spreadsheet to every supplier, it produces fatigue, rushed answers, and assurance theatre. The difference is scoping and decision rules.
What to ask
Map questions to the controls that actually predict risk:
- Data handling: what data is accessed, where it is stored/processed, encryption, retention, deletion.
- Access & authentication: MFA, least privilege, tenant segregation.
- Compliance: SOC 2 Type II, ISO 27001, relevant regulatory attestations.
- Incident response: breach-notification timelines and process.
- Sub-processors: who they rely on and how they govern them.
- Business continuity: backup and disaster recovery.
Avoiding questionnaire fatigue
Scope depth to the vendor's risk tier — a low-risk supplier should not get the same list as one handling regulated data. Reuse standardised frameworks (SIG, CAIQ) so vendors can answer once, accept recent attestations (SOC 2, ISO 27001) in place of re-answering, and spend your review time on the high-risk vendors where answers change decisions.
For real cases to test your questions against, see how a vendor-hosted learning platform led to the 2026 PwC data breach, and how stolen OAuth tokens from two integrations exposed customer instances in the Salesforce data breach wave.
Answers are claims, not facts
Treat questionnaire responses as self-reported. For higher-risk vendors, require evidence — a current SOC 2 Type II report, ISO 27001 certificate, pen-test summary — to corroborate. The questionnaire tells you where to look; evidence tells you whether to trust.
Turn answers into decisions
Decide in advance what answers trigger: blockers, remediation-before-onboarding, contractual commitments, or accept-with-monitoring. Pre-agreed thresholds turn a pile of answers into approve, approve-with-conditions, or reject — otherwise you have generated paperwork, not risk management.
Structure the review with the Vendor Risk tool → and track findings in the Risk Register.
Frequently asked questions
What goes in it? Questions mapped to data handling, access, compliance, incident response, sub-processors and continuity — scoped to risk tier.
How to avoid fatigue? Tier and scope, reuse SIG/CAIQ, accept attestations, focus effort on high-risk vendors.
Trust the answers? They are self-reported claims — require evidence for higher-risk vendors.
Turn into decisions? Pre-agree what each answer triggers: block, remediate, contract, or accept-with-monitoring.
Frequently asked questions
What goes in a third-party security questionnaire?
Questions mapped to the controls that predict risk: how the vendor handles and stores your data, their access and authentication controls, their compliance certifications (SOC 2, ISO 27001), incident-response and breach-notification processes, sub-processor management, and business continuity. Scope depth to the vendor's risk tier rather than sending everyone the same exhaustive list.
How do I avoid questionnaire fatigue?
Tier your vendors and scope the questionnaire to each tier — a low-risk supplier does not need the same 300 questions as one handling regulated data. Reuse standardised frameworks (SIG, CAIQ) so vendors can answer once and reuse, accept recent third-party attestations (SOC 2, ISO 27001) in place of re-answering, and focus your own review time on the high-risk vendors where the answers actually change decisions.
Should I trust questionnaire answers?
Treat them as self-reported claims, not verified facts. For low-risk vendors they may be enough; for higher-risk vendors, require evidence — a current SOC 2 Type II report, ISO 27001 certificate, pen-test summary — to corroborate the answers. The questionnaire tells you where to look; evidence tells you whether to trust.
How do I turn answers into a decision?
Decide in advance what specific answers trigger: which gaps are blockers, which require remediation before onboarding, which need contractual commitments, and which are acceptable with monitoring. A questionnaire with no decision rules just generates paperwork; the value is in the pre-agreed thresholds that turn a set of answers into approve, approve-with-conditions, or reject.