A vendor risk questionnaire is a structured request for a supplier to describe its security, privacy, and resilience controls, usually answered by the vendor's own staff and reviewed by the customer's. It remains the most common due-diligence artifact in third-party risk management because it is cheap to send and easy to file. The trouble is that "easy to send" and "useful to read" are different properties, and most programs optimize for the first. This guide is about getting the second.
Due diligence before signing, and monitoring after, are both explicit expectations in current guidance: NIST CSF 2.0 lists due diligence before entering a supplier relationship (GV.SC-06) and ongoing monitoring (GV.SC-07) as separate outcomes. A questionnaire can serve the first. It cannot, by itself, serve the second.
Start with the decision, not the question list
Before choosing questions, write down what the answers will decide. Typically it is one of four things: approve the vendor, approve with conditions (contract clauses, compensating controls, a remediation date), escalate to a deeper review, or decline. If a question cannot move you between those outcomes, it is padding. Ask it of nobody.
This is also how you resist the pull toward "just add it" every time someone in legal, privacy, or procurement wants one more question. Each added question needs a named reader who will act on the answer.
Standard instrument or custom questionnaire?
For most programs the answer is a standard instrument as the backbone, plus a short custom supplement for what is specific to you.
- The Shared Assessments SIG is a licensed, modular question set built so that a vendor answers once and many customers reuse the result. It comes in a full form (SIG Core) and a much shorter form (SIG Lite). See the SIG explained; the publisher's own description is at Shared Assessments.
- The CSA CAIQ is the Cloud Security Alliance's yes/no question set mapped to its Cloud Controls Matrix, and is the natural fit when the vendor is a cloud service provider that publishes a CSA STAR entry. See the CAIQ explained.
- A custom questionnaire makes sense only for what the standards do not cover for you: a particular regulator's wording, your own data classification, a product-specific integration, or a contractual commitment you require.
The practical reason to prefer a standard is on the vendor side. A supplier with a completed SIG or a published CAIQ can often hand it over the same day. A bespoke 300-question spreadsheet takes weeks, gets delegated to whoever is least busy, and returns the least careful answers. Customization should be the exception you justify, not the default you start from.
Scope by tier, or you will drown both sides
The most common mistake is sending the same form to every vendor. A marketing-analytics plugin with no access to customer data and a payroll processor holding every employee's bank details do not warrant the same questionnaire. Tie the instrument to your vendor tier, which in turn comes from inherent risk:
- Low tier: a short screen (a SIG Lite-sized form or a dozen custom questions), or no questionnaire at all if a current SOC 2 report or ISO/IEC 27001 certificate and a quick data-flow check are enough.
- Mid tier: a standard instrument at moderate scope, with the domains that match what the vendor actually touches. A vendor with no payment data does not need the cardholder-data section.
- High tier: the full standard instrument, the audit report with its complementary user entity controls reviewed (see SOC 2 in vendor assessment), and follow-up on any answer you cannot verify.
Say the scoping rule out loud when you send the form, e.g. "you are a Tier 2 vendor because you process customer contact data; this is the Tier 2 scope." Vendors answer more carefully when they can see the length is proportionate.
Writing questions that produce evidence
A question that can be answered "yes" in one word will be. Compare:
- Weak: "Do you encrypt customer data?" Everyone says yes.
- Better: "Describe how customer data is encrypted at rest and in transit, including the algorithms, who holds the keys, and how key rotation is handled. Attach or reference the policy."
- Weak: "Do you have an incident response plan?"
- Better: "When did you last test your incident response plan, what was the scenario, and what changed as a result? Within how many hours will you notify us of an incident affecting our data?"
Three habits help consistently. First, ask for the artifact behind the claim: a policy name and version, a report period, a certificate number, a screenshot of a setting. Second, ask about dates and frequency rather than existence ("last tested," "reviewed every"), because a control that exists but has not run in two years is a finding. Third, put a few questions where the honest answer is "no" or "partially" and make clear that is acceptable. If a form can only be answered one way, you have built a compliance ritual, not an assessment.
Scoring and review: where the work actually is
Collecting answers is the easy half. A reviewer needs a consistent way to turn a completed form into a decision:
- Define critical questions up front. Pick the handful where a wrong answer is disqualifying for that tier (for example, no MFA on administrative access, no breach-notification commitment) and review those first. A numerical score that averages a failed critical control with fifty passed routine ones hides exactly what matters.
- Treat unanswered, "N/A," and copy-pasted answers as signals. A blanket "see our SOC 2" in reply to forty questions is a request for the report, not an answer.
- Cross-check against something independent. Compare answers with the vendor's audit report scope, its public security documentation, and externally observable facts. A vendor that answers that TLS is enforced everywhere and runs an expired certificate on a customer-facing host has told you something useful about its review process.
- Record the decision and the reasoning. Auditors and regulators ask why a risk was accepted, not just that it was.
- Turn gaps into tracked actions. Each accepted gap gets an owner, a date, and a re-check, or it is a note in a file nobody opens.
Cadence: annual is the maximum, not the plan
A questionnaire is a snapshot of what the vendor said on one day. Re-send for high-tier vendors on a schedule (annually is a common floor), and also on events: a material change in the service, a new subprocessor, a reported incident, a change in the data you send. Between those moments, a questionnaire tells you nothing about drift. That is the argument for continuous vendor monitoring as a complement rather than a replacement, covered in more detail in the limits of manual vendor assessment.
Where tools fit
Questionnaire workflow - sending, tracking, chasing, storing, and mapping answers to your control framework - is a mature category. OneTrust and ProcessUnity are widely used to run it, and Panorays builds a questionnaire workflow around its own external assessment. Security-rating vendors such as BitSight, SecurityScorecard, and UpGuard add an outside-in view that you can set beside the answers. Rescana is one option among several: it pairs the questionnaire with continuous, evidence-based checks and automated evidence collection, so a claimed control can be set beside what is observable. Your approvals. Our agents. What gets acted on stays under your rules. The fit depends on how much of the program is already in a GRC platform. None of these fixes a badly scoped questionnaire. That part is design work.
Frequently asked questions
What should a vendor risk questionnaire include?
A useful vendor risk questionnaire covers the control areas that match what the vendor actually does with your data and systems: governance and policy, access control and authentication, data protection and encryption, vulnerability and patch management, incident response and breach notification, business continuity, privacy, and the vendor's own management of its subcontractors. Scope it by vendor tier so lower-risk vendors get a short screen and critical vendors get the full form, ask for the artifact behind each claim (policy, report, certificate), and keep only questions a named reviewer will act on.
Should we use a standard questionnaire like the SIG or CAIQ or write our own?
Use a standard instrument as the backbone and add a short custom supplement only for what is specific to you. The Shared Assessments SIG and the CSA CAIQ are widely recognized, so many vendors already have completed answers they can reuse, which means faster and more careful responses than a bespoke spreadsheet. Write custom questions for regulator-specific wording, your own data classification, or contractual commitments the standards do not address.
How long should a vendor security questionnaire be?
As short as the vendor's risk tier allows. A low-risk vendor with no access to sensitive data may need only a dozen questions or just a current audit report or certificate, while a critical vendor handling regulated data warrants a full standard instrument such as SIG Core. Sending one long form to every vendor is the most common design mistake: it burdens low-risk vendors, produces low-quality answers, and buries the answers that matter.
How do you verify a vendor's questionnaire answers?
Cross-check answers against independent evidence: the scope and period of the vendor's SOC 2 or ISO/IEC 27001 audit, its published security documentation, and externally observable facts such as certificate status and exposed services. Ask for the artifact behind high-impact claims, treat a blanket "see our SOC 2" as a request for the report rather than an answer, and re-check on events such as a new subprocessor or an incident. A questionnaire is self-reported, so verification is a separate step, not part of the form.
How often should vendor risk questionnaires be repeated?
Annually is a common minimum for high-tier vendors, with lower tiers reviewed less often, and a re-assessment should also be triggered by events: a material change to the service, a new subprocessor, a reported security incident, or a change in the data shared. Because a questionnaire only captures what the vendor said on one day, programs increasingly add continuous monitoring between reviews to catch drift.