You send a vendor a security questionnaire with a few hundred rows. Weeks later it comes back with half the answers reading "Yes", a quarter reading "See SOC 2 report", and the rest blank. Nothing in it helps you decide whether the vendor is safe to use for the thing you are buying.
That outcome is rarely the vendor's fault alone. Most outbound questionnaires are too long, too generic, and written so that "Yes" is the easiest answer. The vendor's security team receives dozens of them and answers each with the least effort that will close the ticket.
This article covers how to design a questionnaire, and run the request, so that what comes back is something you can act on. What to collect overall is covered in a vendor due diligence checklist. This piece is about the questionnaire itself.
Why questionnaires come back empty
Look at the questionnaire from the vendor's side. The common reasons it goes unanswered, or answered badly, are predictable:
It is the same for every vendor. A payroll provider and a font library receive identical questions, most of them irrelevant to one or the other.
It asks what their report already answers. The vendor has a SOC 2 report covering access control, change management and incident response, and you ask about all three again.
The questions invite "Yes". "Do you encrypt data?" has one answer every vendor gives, and it tells you nothing.
Nobody owns it on your side. There is no deadline, no named contact, and no follow-up, so it sits in a queue.
It goes to the wrong person. The account manager receives it and has no idea who should answer.
Each of these has a fix, and none of the fixes require a better template.
Start from what the vendor already has
Before sending any questions, ask for the vendor's existing assurance. For most SaaS vendors that means a SOC 2 Type II report, an ISO 27001 certificate with its scope and Statement of Applicability, or both. Some vendors also publish a completed Cloud Security Alliance CAIQ, or answer a standard SIG questionnaire from Shared Assessments. The trade-offs between those formats are covered in SIG, CAIQ and custom questionnaires compared.
Then read what you receive, and write questions only for the gaps. Typical gaps are:
Scope. The report covers the vendor's core platform, but not the product or region you are buying.
Timing. The report period ended some months ago. Ask for a bridge letter rather than a fresh questionnaire.
Exceptions. The auditor noted exceptions. Ask what was done about them.
Topics outside the report. Data residency, AI use of your data, or your specific contractual requirements.
A gap questionnaire of a few dozen focused questions gets answered. A full questionnaire sent alongside a SOC 2 report signals that nobody will read either. The guide to reading a SOC 2 report as a buyer covers how to find those gaps quickly.
Size the questionnaire to the tier
Your vendor tiers should decide how much you ask. If you have not tiered your vendors yet, start with vendor tiering by data access. A workable pattern looks like this:
| Tier | Typical vendor | What to request |
|---|---|---|
| Critical | Hosts or processes customer data, or production depends on it | Assurance report plus a gap questionnaire, with evidence for key answers |
| High | Has access to internal confidential data | Assurance report, or a short standard questionnaire if none exists |
| Moderate | Limited data, easy to replace | A brief questionnaire on the few controls that matter |
| Low | No data access | No questionnaire; record the tier decision |
The low tier matters as much as the critical one. Every questionnaire you do not send to a low-risk vendor is attention you can spend on a critical one.
Write questions that can be answered
A good question has one subject, applies to the service you buy, and cannot be answered usefully with a single word. Some rules that help:
Ask one thing per question. "Do you enforce MFA and review access quarterly?" gets one answer for two controls.
Ask how, not whether. Replace "Do you encrypt data at rest?" with "How is customer data encrypted at rest, and who can access the keys?"
Scope to your data. "Where is our data stored and processed, including backups?" is better than "Where are your data centers?"
Define the terms that matter. If you ask about "production access", say what you mean by production.
Ask for evidence only where you will read it. A request for an incident response plan is reasonable for a critical vendor. A request for every policy is not.
Allow "not applicable", with a reason. A forced "Yes" or "No" on a question that does not apply produces a false answer.
Keep a fixed core for each tier so answers are comparable across vendors, and add service-specific questions at the end.
Run the request like a process
The questionnaire is only half the work. The other half is getting it answered.
Name the business owner. The person who wants the vendor is the one the vendor's account team listens to. Copy them on every request.
Find the right recipient. Ask the vendor for a security contact before sending, rather than routing through sales.
Explain the purpose in two sentences. Tell the vendor what you are buying, what data is involved, and why you are asking. Context produces better answers.
Set a deadline that fits your procurement date. Make it clear that the purchase or renewal waits on the review.
Follow up on a fixed schedule. A reminder at a set interval, then an escalation through the business owner, is enough for most vendors.
Record the request and response dates. They are part of the evidence that your vendor process ran.
Reading what comes back
A completed questionnaire is evidence only if someone reviews it. Look for:
Answers that contradict the assurance report. If the report describes annual access reviews and the questionnaire says quarterly, ask which is true.
Copied boilerplate. Paragraphs that answer a different question, or mention a product you did not buy.
"Not applicable" without a reason. Ask why.
Vague commitments. "We follow industry standards" is not an answer.
Turn each unresolved point into a follow-up question or a recorded finding, with an owner and a decision: accept, require a contract term, or do not proceed. Then set the reassessment date for the vendor's tier, so the next questionnaire is a short update rather than a fresh start.
When a vendor will not answer
Some vendors decline. Large providers often refuse custom questionnaires outright and point you to their published reports and documentation. Small vendors sometimes have nobody who can answer.
Neither case has to stall the review. For a large provider, accept the published material, map it against your core questions yourself, and record which questions it answers and which it leaves open. For a small vendor, a short call with whoever built the product often produces better information than a form. Write up what you learned and have the vendor confirm it in writing.
If a critical vendor will not provide either a report or answers, that is a finding in its own right. Record it, and let the risk owner decide whether to proceed, add contract terms, or look elsewhere.
How TrustLynce helps
TrustLynce keeps your vendor inventory with risk tiers, sends and tracks reviews, and records each vendor's documents, findings and reassessment dates. Reviews and their outcomes stay attached to the vendor, so the next cycle starts from what you already know.