A larger customer wants to buy, and then a spreadsheet arrives with 200 security questions. Someone on your team stops what they are doing, searches old emails for the last answers, guesses at the rest and sends it back two weeks later. This is how many enterprise deals lose their momentum. This guide explains what the questionnaires ask, how to build answers once and reuse them, and how to respond quickly without promising things you cannot prove.
The short answer
Write your answers once, give one person ownership of them, and back each answer with something you can show. Teams that do this stop treating each questionnaire as a new project. The first one is slow. The tenth takes an afternoon.
Why questionnaires stall deals
The questionnaire is rarely the real obstacle. The delay comes from three habits:
- Nobody owns the response. The sales rep forwards it to engineering, engineering forwards it to the CTO, and it waits in someone's inbox. See who owns security at a startup.
- Every answer is written from scratch. The same question about encryption or access reviews gets a new answer each time, and the answers drift apart.
- The honest answer is slow to find. Nobody is sure whether a control is actually in place, so they ask around, or they say yes and hope.
A buyer reads a slow or inconsistent answer as a signal about how you run the company. A fast, plain, consistent one signals the opposite.
What they usually ask
Questionnaires differ in length and wording, but most cover the same ground:
| Topic | Typical question | What a good answer shows |
|---|---|---|
| Access control | Who can reach production, and how is access reviewed? | A named process and the date of the last review |
| Data protection | Is customer data encrypted in transit and at rest? | The mechanism, not just "yes" |
| Secure development | How do you find and fix vulnerabilities in your code? | Scanning in the pipeline and a record of fixes |
| Vulnerability management | How quickly do you fix critical issues? | A target time and your actual time |
| Incident response | What happens if there is a breach, and when would we hear? | A written plan and a notification commitment |
| Vendors | How do you assess the suppliers you depend on? | A short list and how they are reviewed |
| Compliance | Do you hold SOC 2, ISO 27001 or similar? | The report, or an honest statement of where you are |
Learn the list once. The same ten themes cover most of what you will be sent.
Build an answer library
An answer library is a single document, or a spreadsheet, that holds your approved answer to each common question.
- Collect. Gather the last few questionnaires you completed and group every question by topic.
- Answer once, properly. For each topic, write a short, accurate answer, then link the evidence behind it: a policy, a screenshot, a report or a configuration.
- Name an owner. One person keeps the library current and approves changes. Others suggest edits to them.
- Review it on a schedule. Quarterly is enough for most startups. Answers go stale when tools and processes change.
- Record the date. Each answer carries the date it was last confirmed, so anyone can see how fresh it is.
Do not paste the library into a questionnaire unchanged. Read the question, then use the library answer that fits it.
Answer plainly and avoid promises you cannot back
The temptation is to say yes to everything. Resist it. A questionnaire answer can become part of a contract, and a wrong one can cost more than a lost deal.
- "In place" and "planned" are different answers. Say which one is true, and give a date for anything planned.
- Say what you do, not what you intend. "We scan every pull request for known vulnerabilities" is better than "we take security seriously."
- If you do not know, find out. An accurate "we are still working on this" is safer than a guess.
- Have security or legal review sensitive answers. Anything about data location, breach notification, liability or compliance status should be checked before it goes out.
Use evidence to shorten the conversation
Buyers ask follow-up questions when an answer is vague. Evidence ends the follow-up.
For the secure development and vulnerability management sections, the strongest evidence is a record of what you find and what you fix. A scan history, a list of findings and the time it took to resolve each one answer several questions at once. This is where automated scanning and fix pull requests help: the record is created as part of normal work, not assembled at the last minute. The same metrics appear in the remediation gap, which is worth reading alongside this guide.
Standard formats and reports
You do not have to fill in every customer's custom spreadsheet from scratch.
- Standard questionnaires. Some customers will accept a widely used format, such as the Shared Assessments SIG or the Cloud Security Alliance CAIQ, if you have it prepared. Ask early.
- A trust page. A public page describing your security practices answers the first round of questions before they are asked.
- A SOC 2 report. Many buyers accept a report in place of most of the questionnaire. If you are asked for one more than a few times, it is probably worth the effort. See SOC 2 for startups: Type I or Type II.
A five-day response process
- Day 0. Sales logs the request and assigns it to the questionnaire owner.
- Day 1. The owner fills in everything the library already covers and lists the gaps.
- Days 2 to 3. The right people answer the gaps. Each new answer goes into the library afterward.
- Day 4. Security or legal reviews the sensitive answers.
- Day 5. The owner sends the response and notes any follow-up call the buyer requested.
Fast does not mean careless. The speed comes from the library, not from skipping review.
What to measure
- Time to respond. From the day the questionnaire arrives to the day you send it.
- Questions answered from the library. A rising share shows the library is working.
- Deals held up by security review. Count them in your own pipeline, over a stated period.
- Answers corrected after sending. Each one is a quality problem to fix at the source.
Use your own numbers. Industry averages will not tell you how your sales cycle behaves.
A 30-day starting plan
- Week 1. Name the owner. Gather your last three questionnaires.
- Week 2. Draft answers for the seven topics in the table above, with evidence links.
- Week 3. Get security, engineering and legal to review. Fix any answer you cannot support.
- Week 4. Use the library on the next live questionnaire, then measure how long it took.
Frequently asked questions
Do we need SOC 2 before we can answer questionnaires? No. Many early customers accept honest answers and some evidence. A report becomes useful once you answer the same questions repeatedly.
Can we use AI to fill in questionnaires? It can draft from your library, but a person must check each answer against what is true. A confident wrong answer is worse than a slow right one.
What if a control is only partly in place? Say so. Describe what exists, what is missing and when you plan to close the gap.
Should sales or engineering own the response? One named person, usually close to security or engineering, with sales tracking the deadline. Splitting ownership is how questionnaires go missing.
How long should answers be? Long enough to be specific, short enough to read. Two or three sentences plus an evidence link works for most questions.
This guide is general guidance, not legal advice. Have your own counsel review contractual commitments.