The evidence you need before answering security questionnaires

The bar: specific, current, owned

A document is only evidence if it can settle a question. Three tests:

• Specific. "We follow industry best practices for encryption" answers nothing. "Data at rest is encrypted with AES-256; keys are managed in AWS KMS and rotated annually" answers several questions at once.
• Current. A policy with a review date two years past is worse than useless — a reviewer who notices will start doubting everything else you sent.
• Owned. A named person is accountable for keeping it accurate. Documents without an owner drift out of true silently, which is how you end up citing something that contradicts your SOC 2.

Aim for documents that state what you actually do. Aspirational policies are a liability: you have committed in writing to a control you do not operate, and the gap will surface in an audit or an incident.

The core six documents

1. Information security policy

The parent document. Needs a scope statement, a named owner, a review date, and either the substance of your controls or explicit references to sub-policies that hold it. Reviewers commonly ask for this one by name before anything else.

2. Access control policy

Among the highest-yield documents you can write, because questionnaires ask about access from many angles. Should cover: how access is granted and on whose approval, whether least-privilege is enforced, MFA requirements and which factors are permitted, how often access is reviewed and by whom, and how quickly access is revoked on termination. That last one gets asked in almost every questionnaire, usually with a specific number of hours expected.

3. Data handling and retention

Where customer data physically lives, how it is classified, how long each class is retained, what happens on deletion request and on contract termination, and encryption in transit and at rest with named algorithms. Data residency is asked constantly, and vaguely worded answers here cause the most follow-up rounds.

4. Incident response plan

Needs severity definitions, who is on call and how they are reached, escalation path, and — critically — the customer notification timeline you are prepared to commit to. Check this against your actual contracts and any regulatory obligations before citing it; a questionnaire answer promising a shorter notification window than your DPA is a problem you have created for yourself.

5. Business continuity and disaster recovery

Your real RTO (how quickly you restore service) and RPO (how much data you could lose), backup frequency and retention, where backups are stored, and when recovery was last actually tested. The test date is what separates a real plan from a document — and reviewers increasingly ask for it directly.

6. Subprocessor and vendor list

Every third party that touches customer data, what data each receives, and why. Needed both for security questionnaires and for GDPR-style obligations, and it is the document most often out of date, because engineers add SaaS tools faster than anyone updates the list.

Details reviewers ask for most

Independent of format, a consistent set of specifics comes up. If your documents contain these, most questionnaires become transcription:

• Encryption algorithms and key management, in transit and at rest
• MFA: which factors are accepted, and whether SMS is among them
• Access review cadence, and revocation time on termination
• Log retention period, and whether logs are tamper-resistant
• Patching and vulnerability remediation timelines by severity
• Penetration test frequency, scope, and who performs it
• Employee security training frequency, and background check policy
• RTO, RPO, and the date of the last recovery test
• Data residency by region, and any onward transfer mechanism
• Breach notification timeline committed to customers

Third-party attestations

If you have a SOC 2 Type II report or an ISO 27001 certificate, these are the single most efficient pieces of evidence you hold — they let you answer many questions by reference, and some reviewers will shorten their questionnaire on the strength of one. Keep the current report, the audit period dates, and the scope statement to hand.

Be precise about scope and period, though. A reviewer who finds that a control you claimed sits outside the audited scope, or that the audit period ended fourteen months ago, will treat the rest of your answers more sceptically. Where a question falls outside the report, answer it directly rather than pointing at the report and hoping.

How to organise it

The organising principle that matters: you must be able to get from an answer back to the sentence it came from. Everything else is preference.

1. One location, one owner per document. Not scattered across personal drives.
2. Version deliberately. Keep old versions. When a customer asks what you told them last year, you need the wording as it was then, not as it is now.
3. Record the source of every answer. Document and passage, not just a filename — see the answering process.
4. Connect updates back to answers. When a policy changes, you need to know which previously sent answers relied on the part that changed. Without this, answers go stale invisibly, which is the most common way a good process degrades.

What to do about documents you don't have

Do not write a policy purely to have something to cite. A policy describing controls you do not operate is worse than no policy: you have put a false claim in writing, and questionnaire answers citing it inherit the problem.

The better sequence is to write down what you genuinely do today, even if it is thin, then improve the control and update the document. A reviewer reading "access reviews are performed annually; we are moving to quarterly in Q4" sees a company that knows its own posture. A reviewer who discovers your quarterly-review policy has never actually been executed sees something considerably worse.