Death by Security Questionnaire: How to Answer 200 Questions in an Afternoon

A security questionnaire is a buyer asking, in three hundred small pieces, whether you are a safe company to depend on. Most vendors treat each one as a fresh writing project, which is why a single questionnaire eats a week of senior engineering time and the deal slips a month.

The fix is an answer library and a policy on what you will and will not answer. Build both once and the same questionnaire takes an afternoon.

Why do they take so long the first time?

Because the answers are distributed across people's heads, and each question has three parts: what is true, what evidence proves it, and how to phrase it so it does not create an obligation you cannot meet.

That third part is where teams get hurt. A question asks whether you encrypt data at rest. The engineer answers yes. What they meant was that the database is encrypted; what the buyer read was that every backup, log, and file store is encrypted, and that answer is now in a contract annex. Careless yeses are how vendors end up in breach of representations they never consciously made.

What goes in the answer library?

Every answer you have ever given, with four attachments.

The last-verified date is what separates a library from a copy-paste graveyard. An answer written eighteen months ago that says you review access quarterly is a liability if you stopped doing that in March. Verify before reuse, and mark the ones that are cheap to verify so the review is fast.

Group answers by theme rather than by questionnaire, because the questions repeat endlessly in different wording. Access control, encryption, data residency, incident response, business continuity, sub-processors, personnel screening, secure development, and privacy obligations cover the substantial majority of what you will ever be asked.

What do you do about questions you fail?

Answer honestly, then say what compensates or when it changes. Never leave a blank, and never lie.

Buyers do not expect a twenty-person company to have a security operations centre. They expect you to know that you do not, and to have thought about it. "No, and here is why that risk is low for the service we provide, and here is what we do instead" is a strong answer. A blank cell reads as either dishonesty or disorganisation, and both kill deals faster than a missing control.

Three specific patterns that work:

• Compensating control. No dedicated security team, but a named accountable owner, an external annual test, and monitored alerting.
• Scoped inapplicability. The question assumes you host customer data in your own data centre. You do not. Say so plainly rather than answering as if you did.
• Dated commitment. Not implemented, planned for a specific quarter, with the owner named. Only write this if it is true, because buyers do follow up at renewal.

When should you push back?

More often than most founders feel able to. A questionnaire written for a company that will hold ten million health records is not the right instrument for a tool that sends calendar reminders, and saying so professionally is usually welcomed.

Reasonable pushes: asking to scope the questionnaire to the service being bought, offering your trust page and audit report in place of the overlapping eighty percent, or proposing a call to work through the exceptions rather than a fourth round of written clarifications. Buyers on the other side are usually as tired of this process as you are.

Unreasonable pushes: refusing to answer questions about sub-processors, data location, or breach notification. Those are the questions that actually matter, and resisting them signals exactly the wrong thing.

How do you make the next one faster?

Two structural moves, in this order.

First, publish the answers that are not confidential. A public trust page carrying your certifications, sub-processor list, data locations, and standard security posture removes a large block of questions before anyone asks. It also gets read during evaluation, which is earlier than the questionnaire arrives.

Second, connect the library to live control status rather than to documents. The reason answers go stale is that they describe a state, and states change. If the answer about access reviews is backed by an actual control record rather than a policy PDF, verification is a glance rather than an investigation.

For why the underlying evidence matters more than the answer, what auditors actually ask for covers the artefacts themselves.

This is general information, not legal advice.

Valdra holds the control evidence and the customer-facing trust page against the same records, so the answer you give a buyer matches the state of the control on the day you send it.