# how to handle a customer security questionnaire

## TL;DR
Triage it fast, answer from a maintained answer bank, and never invent an answer you cannot prove. Questionnaires are pass or fail on honesty and evidence, not on prose quality. The team that reuses approved answers beats the team that rewrites them every time.

```text
how to handle a customer security questionnaire
```

## Use this when
- A prospect sends a SIG, CAIQ, or homegrown security questionnaire
- A deal is stalled waiting on security review
- You keep answering the same questions from scratch
- You need to decide which questionnaires are worth the effort

## Not for this skill when
- The customer wants a live security review call (prepare differently: demo, don't just recite)
- You are filling out a compliance certification (that is an audit, not a questionnaire)
- The questions are about pricing or features (route those to sales)

## Steps

**1. Triage on arrival: what, who, when, and how big.**

Identify the questionnaire type, the deal size, and the deadline. A 300-question SIG for a pilot gets a different effort level than a 20-question form for your biggest deal. Reply to the requester within a day with a delivery date.

Expected: every incoming questionnaire logged with owner, deadline, and deal context.

**2. Answer from the answer bank first.**

Maintain one set of approved answers to the common questions: encryption, access control, incident response, backups, subprocessors, pen testing. Reuse them verbatim. Consistency across questionnaires is itself a trust signal.

```
grep -ri "encryption at rest" ~/workspace/security/answer-bank/
```

Expected: the approved answer plus its evidence link, ready to paste.

**3. Answer honestly, and say "not yet" when it is true.**

"We do not have that control; here is what we do instead and our timeline" beats a fabricated yes every time. Fabricated answers become contract terms, and contract terms become liabilities when the customer audits you.

Expected: every answer is either true today or clearly marked as planned with a date.

**4. Attach evidence to the big claims.**

SOC 2 report under NDA, pen test executive summary, your security page, subprocessor list. Claims without evidence invite follow-up questions; evidence preempts them.

Expected: the submitted questionnaire references evidence for encryption, access control, incident response, and testing.

**5. Track what you promised.**

Questionnaire answers become commitments. Log every "we will have X by Q3" in one place with an owner, or sales will promise your roadmap on your behalf again.

Expected: a commitments list reviewed monthly until each item is done or renegotiated.

**6. Follow up after submission.**

Confirm receipt, offer the security call, and ask what else the reviewer needs. Most questionnaires die in someone's inbox; a nudge moves the deal.

Expected: the reviewer confirms the package is complete or tells you exactly what is missing.

### Variant: SIG questionnaire how to answer
Work through it section by section from the answer bank, mark anything that needs a custom answer, and get those custom answers reviewed before sending. SIGs are long; consistency matters more than speed.

### Variant: CAIQ lite vs full
Send CAIQ Lite proactively on your security page; it answers half the questions before they are asked. Save the full CAIQ for deals that specifically require it.

### Variant: security review slowing our deal
Ask the champion what the reviewer actually cares about, then front-load evidence on those three topics. Most slowdowns are one worried reviewer, not the whole questionnaire.

### Variant: how to answer "do you encrypt backups"
From the bank, with specifics: algorithm, key management, and how you tested restores. "Yes" is not an answer; "AES-256 with keys in a managed KMS, restores tested quarterly" is.

## Why this happens
Buyers cannot audit every vendor, so the questionnaire is their scalable filter. It is not really a test of your security; it is a test of whether you have your security story straight. Teams with an answer bank and evidence look mature because the artifacts exist, which usually means the controls do too.

## Edge cases and pitfalls
- **The questionnaire asks for your full pen test report:** share the executive summary, offer the full report under NDA for big deals. Never email full reports casually.
- **Questions that do not apply to your architecture:** say so plainly ("we are serverless; there are no servers to patch") rather than forcing an answer into the wrong box.
- **Two questionnaires, contradictory answers:** this is why the bank exists. One approved answer per question, used everywhere, updated in one place.
- **The customer edits your answers into their MSA:** review what got pasted. Questionnaire prose written hastily can become a warranty you never meant to give.
- **Answer bank goes stale:** review it quarterly or after any control change. An approved answer describing last year's architecture is a lie with extra steps.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_8XE0CVvjw-kn28EzXws2Zg
