How to answer a vendor security questionnaire

What the reviewer is actually checking

It helps to know who reads your answers. On the other side is usually a security or third-party-risk reviewer whose job is not to admire your security programme — it is to decide whether onboarding you creates a risk they will be held responsible for.

That reviewer is scanning for three things: whether a control exists, whether you can show it exists, and whether your answers are internally consistent. A confident answer that contradicts your own SOC 2 report is far worse than an honest "not yet" — it moves the conversation from evaluating your controls to doubting your claims, and that is much harder to recover from.

Build the evidence base before the first questionnaire

Most of the pain in answering questionnaires is not writing — it is hunting. Someone asks how long you retain audit logs, and the answer is in a policy document that lives in one person's Google Drive, was last updated eight months ago, and contradicts what the runbook says.

Before you answer anything, assemble the documents your answers will draw on and put them somewhere with a single owner:

• Information security policy, and any sub-policies it references (access control, encryption, data retention)
• Your most recent SOC 2 or ISO 27001 report, if you have one
• The most recent penetration test summary or report
• Incident response plan, including notification timelines you have actually committed to
• Business continuity and disaster recovery plan, with your real RTO and RPO
• A current subprocessor or vendor list

The evidence checklist guide goes through what each document needs to contain to actually answer questions, rather than just existing.

Triage every question into one of four buckets

Do not start at row one and work down. A questionnaire is not uniform work, and treating it as uniform is why it takes days. Read the whole thing first and sort every question:

1. Directly answerable from a document. The answer exists in writing. This is usually the majority, and it is mechanical work.
2. Answerable, but needs a person. A named engineer or ops owner knows it; it is just not written down. Batch these into one request per person rather than interrupting them per question.
3. Not applicable. Physical datacentre security when you run entirely on AWS, for example. Say so, and say why in one clause — a bare "N/A" reads like avoidance.
4. A real gap. You do not have the control. Handle these deliberately (see below); do not let them get quietly filled with optimistic language.

Doing this first means you know within an hour whether this questionnaire is a half-day of transcription or a two-week conversation involving your CTO — which is the thing sales actually needs to know.

Answer from evidence, and say where it came from

For every answer in bucket one, record which document and which section it came from. Not a link to a 90-page PDF: the specific passage.

This feels like overhead the first time and pays for itself immediately. It gives you three things at once: a reviewer who asks "where is that documented?" gets an answer in seconds; anyone who reviews your draft can verify it without re-reading the source material; and when a policy changes later, you know exactly which answers depended on the old wording.

Handle controls you genuinely don't have

Every company answering these has gaps. Reviewers know this. What they are testing is whether you know it too.

A gap answered well has three parts: what the current state actually is, what compensates for it right now, and whether it is on a roadmap with a real date. "We do not currently enforce hardware-key MFA for all staff; it is required for all production and customer-data access, and we are extending it to all accounts this quarter" is a strong answer. "Yes" is a weak one that will not survive the follow-up question — and if it contradicts your SOC 2, it costs you credibility across every other answer on the sheet.

The temptation to soften a gap is strongest under deal pressure. It is also when it does the most damage, because an answer you cannot support is a commitment you have now made in writing to a customer's security team.

Make the next questionnaire cheaper than this one

Questionnaires overlap heavily. Different customers use different formats — see CAIQ vs SIG vs VSA — but they are asking about the same underlying controls in different words. "Is data encrypted at rest?" and "Describe your encryption-at-rest implementation, including algorithm and key management" want the same evidence.

So the single highest-leverage habit is to keep every approved answer, with its citation, in one place you actually search before writing anything new. The goal is that questionnaire number five is mostly a review exercise rather than a writing exercise.

Keep the reviewed version, not the draft. An answer someone signed off on is worth reusing; an unreviewed draft just propagates whatever was wrong with it.

The failure nobody plans for: answers going stale

This is the part that catches teams who have otherwise got their process right.

You answer forty questions citing your access control policy. Six months later someone updates that policy — the review cadence changes from quarterly to annually, say. Nothing in your process connects that edit back to the answers that depended on it. Those answers are now wrong, they are already sitting in four customers' vendor files, and nobody knows.

The usual mitigations are a calendar reminder to re-review everything, which is expensive and gets skipped, or nothing at all. The precise version is to record which passage each answer relied on, so that when a document changes you can identify exactly which past answers touched the changed text — and leave the rest alone.

Five mistakes that cost the most time

1. Answering in the customer's spreadsheet as the only copy. The work then lives in a file you sent away. Keep your own source of truth and export into their format.
2. Starting at row one. Without triage you discover the hard questions on day three, having already spent two days on transcription.
3. Not recording sources. Cheap now, expensive at every follow-up and every policy update.
4. Letting one person own it. Whoever answered the last one becomes a bottleneck, and the knowledge leaves when they do.
5. Generating answers with a general-purpose AI tool and shipping them unreviewed. A language model will produce a fluent answer whether or not your documents support it, and it cannot tell you which case you are in. Drafting is fine; drafting without a citation and a human reviewer is how an unsupported claim reaches a customer's security team.