How to answer a vendor security questionnaire (when a buyer just sent you one)

A practical playbook for small SaaS teams. Written for the first few questionnaires, when you have no dedicated security person.

A prospect's procurement team has emailed a spreadsheet with a deadline. Perhaps it is 80 questions, perhaps 400. The deal is real and the clock is running. This guide walks through what to do in the first hour, the first two days, and the last mile before you send it back.

1. Triage in the first hour

Do not start answering. Spend an hour deciding what you are dealing with.

• Identify the format. Is it a standard framework (SIG Lite, CAIQ, an ISO 27001 or SOC 2 mapped sheet) or the buyer's own custom list? Standard formats tend to have predictable wording; custom ones hide odd questions. See our guides on SIG Lite and CAIQ.
• Count and categorise. Roughly how many questions, and how many are really the same question reworded? Most questionnaires are dominated by a few topics (encryption, access control, backups, incident response, vendors). The free complexity analyser does this count in your browser, or you can do it by hand with a filter column.
• Ask the buyer two questions. Is the deadline firm, and will they accept a SOC 2 report, ISO certificate, or your security whitepaper instead of or alongside the spreadsheet? Many buyers will. Many will also accept "partial now, remainder in a week" if you ask early and sound organised.
• Find the contractual weight. Some questionnaires are attached to the contract or referenced in a security addendum. If so, your answers may become representations you are held to. Tell whoever signs contracts.

2. Assign owners before you assign answers

The usual failure is one person (often the CTO) answering everything from memory. Instead, split by domain and name one owner per block:

Pick one person as the single editor of the final file. Everyone else sends answers to them. That person also decides ties.

3. Gather evidence first, then answer

For each domain, collect what actually exists, in this order of strength:

1. Third-party attestations: SOC 2 report, ISO certificate, pen-test report or summary letter.
2. Written, approved policies with version and date.
3. System configuration you can screenshot or export (cloud console encryption setting, MFA enforcement, backup schedule).
4. Past answers someone senior approved.
5. Memory. Treat this as a lead, not evidence. Go and check.

Give each document a stable code and version (for example SEC-POL-007 v2.0) so every answer can say where it came from. If a reviewer asks "where does this come from?", you should be able to answer in ten seconds.

4. Answer rules that keep you out of trouble

• Answer only what you can support today. Not what is planned, not what the template policy says you should do, not what a competitor does.
• Match the question's scope. "Do you encrypt data at rest?" is not the same as "Is all customer data encrypted at rest including backups and logs?" Answer the question asked.
• Beware absolutes. "All", "never", "always", "any" are traps. If it is true for production but not for a developer laptop, say so.
• Do not claim certifications you do not hold. "Aligned with SOC 2" or "controls mapped to ISO 27001" is different from "certified". Say which one is true.
• Do not copy a competitor's or a template's wording. If you cannot trace a sentence to your own evidence, delete it.

5. How to say "no" or "in progress" honestly

Most buyers expect gaps from a small vendor. What they react badly to is a gap discovered later. A clear, specific "not yet" with a compensating control usually reads better than a vague "Yes". The pattern is:

1. State plainly what you do not have.
2. State what you do instead.
3. If a date is real and committed, give it. If not, leave it out.

Example only (replace with your own facts). Question: "Do you undergo an annual independent penetration test?"

We do not yet have an independent annual penetration test. We run automated dependency and container scanning on every build, and we review findings weekly. We are scoping a third-party test and can share the scope and, once complete, the summary letter under NDA.

Example only. Question: "Do you hold SOC 2 Type II?"

No. We have not completed a SOC 2 audit. Our controls are documented in our security policy set (available under NDA), and we can complete your questionnaire in full and walk through our controls on a call.

Notice what is missing: no "industry-standard", no "best-in-class", no promise we cannot keep. If you say "in progress", make sure something is in fact in progress: a signed engagement with an auditor, a tool being configured, a ticket with an owner.

6. Consistency checks before you send

Inconsistent answers are the most common self-inflicted wound. Before sending:

• Cross-read related answers. Retention periods, backup frequency, RTO/RPO, subprocessor lists and encryption algorithms tend to appear in several places. They must agree.
• Check against your last questionnaire. If your answer changed (say retention was 90 days and is now 30), confirm which is true now and make sure contracts and the DPA say the same. Old approved answers are a common source of stale claims.
• Check dates. A policy last reviewed three years ago is a flag, even if it is still true. Review and re-date it.
• Check against your public pages. Your website, privacy policy and trust page should not contradict the spreadsheet.

7. Deadline tactics

• Answer the high-weight sections first. Encryption, access control, incident response and subprocessors are usually what blocks sign-off.
• Do the repeats once. Write one approved answer per topic, then reuse it everywhere the buyer means the same thing.
• Send in two passes if needed. A complete first pass with a few explicit "to follow" items beats a late perfect one.
• Book the review call early. If the buyer's security team wants a call, offer a slot before they ask. It signals confidence and often resolves questions faster than writing.
• Return the original file. Buyers load answers into their own tooling. Do not reformat, rename sheets or paste answers into a different template unless asked.

8. After you send it

Save the final answers as your approved answer library, with the source document and version next to each. Next time, you start from 60 to 80 percent done rather than from zero. Put a review date on the library, since policies change. See what enterprise buyers ask SaaS companies for the 20 topics worth preparing evidence for in advance.

A short checklist

• Format, count and deadline known; contract weight checked.
• One owner per domain; one editor.
• Evidence gathered and coded by document and version.
• No claims without support; gaps stated plainly with what you do instead.
• Related answers cross-checked; stale answers fixed.
• Original file returned intact.

If you are weighing tools to speed this up, this comparison of options sets out the trade-offs without a sales pitch.