Answering enterprise security questionnaires without lying

A three hundred question security questionnaire arrives, your deal is waiting on it, and roughly forty of the questions describe a company considerably larger than yours. The temptation to answer generously is enormous, and it is worth understanding exactly why giving in to it is a bad trade.

Your answers become a contractual representation. They are usually referenced in the agreement, and they are the first document produced if something goes wrong later. An overstated answer that nobody checks today becomes the basis of a claim on the worst day of your company's life.

What the reviewer is really doing

It helps to know that the person on the other side is not scoring you out of three hundred. They are looking for a small number of specific risks, and they are forming a judgement about whether you are a supplier who understands their own environment.

• Can this vendor reach our data, and what stops one of their employees from doing so casually?
• If they are breached, will we hear about it quickly enough to act?
• Do they know what they do not have, or are they claiming everything?
• Is there a named person here who owns security, or is it nobody's job?

That third one is doing more work than most vendors realise. A questionnaire answered entirely in the affirmative is a signal, and it is not the signal you want to send.

How to answer a control you do not have

The honest answer has three parts, and it is almost always accepted when all three are present. State plainly that you do not have the control. Describe what you do instead and why it addresses the same risk. Then give a date, or say clearly that it is not on your roadmap and explain the reasoning.

Written out, that is the difference between an answer that stalls a deal and one that closes it. Reviewers approve compensating controls constantly. What they escalate is vagueness.

The three answers that most often stall a deal

1. 1Breach notification timelines. If you cannot commit to a number of hours, say what you can commit to and what the dependency is. An unanswered notification clause goes straight to legal, and legal is slower than security.
2. 2Subprocessor lists. Reviewers need to know who else touches their data. An incomplete list found later damages trust more than a long list disclosed upfront, and the list is rarely the problem.
3. 3Data deletion on termination. Vague answers here reliably trigger follow-up, because the reviewer is imagining the end of the relationship at the moment they are being asked to start it. Describe the mechanism, the timeframe and the backup expiry.

Make the next one cheaper

The questionnaire is not the last one you will see, so treat the first as an investment. Keep a single answer library with the wording you have already had approved, and record who approved each answer and when. Attach evidence once and reuse it.

• Maintain a current architecture diagram and a data flow diagram. They pre-empt a surprising number of questions.
• Keep your subprocessor list accurate and publish it, so it never becomes a negotiation.
• Write a short security overview document and offer it before the questionnaire arrives. It regularly shortens the questionnaire you are sent.
• Track which answers triggered follow-up questions, and fix the wording rather than re-explaining it every quarter.

The companies that find this process painless are not the ones with the most controls. They are the ones who know precisely which controls they have, can produce the evidence quickly, and are comfortable saying no to the rest. That posture is available to a twenty-person company, and it reads as competence rather than as a gap.