The Security Questionnaire
Playbook

Security questionnaires stall more deals than pricing does. Not because the answers are hard, but because the same 300 questions arrive in a different spreadsheet every time, land on the same overloaded engineer, and sit for three weeks while the deal cools.

The problem is structural. A SIG Lite has around 300 questions. A CAIQ has 261. A bespoke enterprise DDQ can run to 500. Perhaps 80% of them ask the same things in different words, and almost every team answers them from scratch, every time, by interrupting the person who can least afford the interruption.

This is a solved problem, and the solution is not a bigger spreadsheet. It is a control-anchored answer bank with evidence attached and an owner for currency.

Start with the artefacts, not the answers

Most questionnaire questions are asking, indirectly, for one of a small set of documents. Get these current and organised, and a large share of any questionnaire becomes a reference plus two sentences of context.

Keep these in one place with an owner and a review date on each. The most common security review delay is not a missing control — it is a current control documented in an artefact that expired four months ago and nobody noticed.

Anchor answers to controls, not to questions

Here is the mistake that makes answer banks decay. Teams store answers keyed to the question text they last saw: "How do you manage encryption at rest?" Then a different buyer asks "Describe the cryptographic protections applied to stored customer data" and the search finds nothing, so someone writes it again — slightly differently. Two years later you have eleven variants of the encryption answer, three of them out of date, and no way to know which is authoritative.

Key answers to the control instead. One canonical answer for encryption at rest, tagged with the frameworks it satisfies (SOC 2 CC6.1, ISO 27001 A.8.24, CAIQ EKM-03), and every phrasing of the question maps to it. When the control changes, you update one answer and every future questionnaire is correct.

Control ID:        ENC-002
Control name:      Encryption of customer data at rest
Frameworks:        SOC 2 CC6.1 | ISO 27001 A.8.24 | CAIQ EKM-03 | NIST 800-53 SC-28

Canonical answer:
  All customer data is encrypted at rest using AES-256. Encryption keys are
  managed in AWS KMS with automatic annual rotation and are never accessible
  to application code. Database volumes, object storage, and backups are all
  covered. Key access is restricted to two named platform engineers and every
  access event is logged to an immutable audit trail.

Evidence:
  - SOC 2 Type II report, section CC6.1 (period ending 2026-03-31)
  - Architecture diagram, page 7
  - KMS key policy export (available under NDA)

Owner:             Platform Security Lead
Last verified:     2026-06-14
Review due:        2026-12-14
Confidence:        High — auditor-tested

Known phrasings:
  - "How is data encrypted at rest?"
  - "Describe cryptographic protections for stored customer data"
  - "Is customer data encrypted in the database and in backups?"
  - "What key management practices are in place?"

The two fields teams skip are the ones that matter most over time. Last verified turns a stale answer into a visible problem rather than a silent one. Confidence tells whoever assembles the next questionnaire which answers can go straight through and which need a human look before they are sent to a customer under contract.

Answering a control you do not have

This is the part every guide skips, and it is where deals are actually lost. You will be asked about a control you have not implemented. There are three ways to handle it, and only one of them works.

Do not claim it. Security answers become contractual. A false "yes" surfaces during the audit, the incident, or the renewal, and at that point you are not managing a gap — you are managing a misrepresentation. This is also the failure mode most likely to end a customer relationship permanently.

Do not just say no. A bare "No" reads as an unmanaged risk, and the reviewer has to score it as one. It also invites the assumption that the gap is worse than it is.

Answer with the compensating control and the roadmap. Reviewers are risk assessors, not auditors looking for perfection. They can accept a gap that is acknowledged, mitigated, and scheduled. What they cannot accept is a gap they discover themselves.

Answer once, at the right altitude

A frequent trap is answering at the wrong level of detail. Too little and the reviewer comes back with follow-ups, adding a week per round trip. Too much and you have disclosed architecture detail that becomes a liability, or invited questions nobody asked.

The workable altitude has four parts, in order:

• The direct answer — yes, no, or the specific mechanism. First sentence, no preamble.
• The mechanism — what specifically implements it, named concretely enough to be credible.
• The evidence — which artefact proves it, and where.
• The boundary — what is in scope and what is not, so nobody assumes more coverage than exists.

That last part is counterintuitive and worth the discomfort. Stating a limit explicitly prevents the reviewer from assuming a broader claim, and a misunderstood scope discovered later is far more damaging than a boundary stated up front.

Keeping it current

An answer bank that is not maintained becomes a liability faster than an empty one, because people trust it. Three habits keep it honest.

Attach a review date to every record, not to the bank. Encryption answers can sit for a year. Sub-processor lists and personnel counts go stale in a quarter. A single annual review date across everything is a policy that guarantees some answers are always wrong.

Trigger reviews on events, not only on dates. A new sub-processor, a re-architecture, an audit, a change of security lead, a new region — each should mark the affected records for re-verification. Wire this into the change process, not into someone's memory.

Feed completed questionnaires back in. Every questionnaire you complete contains questions your bank did not cover and phrasings it did not recognise. Capturing those after submission — while it is fresh — is what makes the next one faster. Teams that skip this step plateau at roughly 60% coverage forever.

The reuse dividend

Once a control-anchored bank is in place with evidence attached, the economics change sharply. A 300-question SIG that took an engineer three days becomes a few hours of review: most answers map directly, a handful need context for this specific buyer, and a small number are genuinely new.

The security engineer stops being a bottleneck and becomes a reviewer. The deal stops waiting. And the answers get more accurate rather than less, because one canonical answer maintained by an owner beats eleven variants written under deadline pressure by whoever was available.

That is the whole argument for treating questionnaire response as a knowledge-management problem rather than a writing problem — and it is the same argument that applies to RFP answers generally, which is why the two workflows belong in the same system rather than in two different spreadsheets.