Skip to content
Digital Security Consulting

How to Answer a Client's Security Questionnaire Honestly

Security questionnaires usually arrive just as a deal is about to close. The instinct is to answer generously. That's the one genuinely risky option. Here's how to answer accurately and still win the contract.

Published 3 min read

It arrives at the worst possible moment. The deal is nearly done, and procurement sends a spreadsheet: forty questions about encryption at rest, incident response, access reviews, subprocessors and backup testing.

The instinct is to answer generously and move on. That’s the one genuinely risky choice.

Why overclaiming is the real danger

A security questionnaire isn’t a formality. It’s a document you sign asserting that certain controls exist. If an incident later shows those answers were false, you’ve misrepresented your security to a client — which is a much bigger problem than an honest “not yet” would ever have been.

An honest “not currently in place; planned for next quarter” is usually accepted, especially from a smaller supplier. A false “yes” is not.

You’re probably closer than you think

Working through these, the same pattern shows up almost every time: a good share of the answers are already true, but nothing is written down. You do have backups. You do restrict who can reach client data. Nobody has ever documented it.

So the work splits into two kinds:

  • Paperwork gaps — things you already do that need a short written policy and some evidence
  • Real gaps — things you genuinely don’t do, which need fixing or an honest roadmap answer

Keeping those separate is what keeps the cost proportionate.

A practical order of work

  1. Go through it line by line and mark each answer: true and documented, true but undocumented, not true.
  2. Write short policies for the undocumented ones. A twelve-person company needs a few pages that describe what actually happens, not a hundred-page manual nobody follows.
  3. Fix the real gaps that matter most — usually multi-factor authentication, tested backups, and access control, because those are also the ones clients check.
  4. Answer with evidence behind every yes. If they ask for proof, you should be able to produce it.

Build it once

The best outcome isn’t one completed questionnaire. It’s a reusable evidence pack — policies, restore-test records, access reviews — so the next client’s spreadsheet takes an afternoon instead of a fortnight.

The same material also supports your cyber insurance renewal, since insurers increasingly ask nearly identical questions and may require multi-factor authentication and tested backups as a condition of cover.

We walk through this in a big client sent a security questionnaire. The broader work sits in our cybersecurity practice.

Frequently asked questions

Is it acceptable to say 'no' on a security questionnaire?

Yes — an honest 'not currently, planned for next quarter' is usually accepted, especially from a smaller supplier. What causes real trouble is a 'yes' that turns out to be false after an incident, because you have signed a document asserting protections you did not have.

What documents do clients usually ask for?

Common requests include an information security policy, an incident response plan, evidence of backups and restore testing, access control practices, multi-factor authentication, encryption, and how you manage your own suppliers. Larger clients may ask about formal frameworks such as SOC 2.

Do we need a separate answer for every client?

No. If you build a reusable evidence pack — short policies plus proof they are followed — each new questionnaire becomes a mapping exercise rather than a project.

Tell us what is breaking — or what you are trying to build.

You get a senior engineer on the first call, not a salesperson. If we are not the right fit, we will say so and point you somewhere better.

Active incident? Write “URGENT” in your message and we prioritise it.