How to answer a customer security questionnaire without a security team
A vendor security questionnaire is not a test of how secure you are. It is a test of whether you can retrieve evidence about yourself, in writing, without contradicting a colleague. That is why a company with genuinely decent security can spend two weeks on a spreadsheet and still come out looking shaky: the controls exist, the evidence has never been written down.
What the reviewer on the other end is doing
The person reading your answers is usually not trying to catch you out. They have their own obligation — to record that they assessed you before their company sent you data — and they are looking for three things: whether an answer is specific, whether it is consistent with your other answers, and whether you would be able to produce the artifact if asked.
That last one is the whole game. A confident yes with nothing behind it creates a follow-up round, and follow-up rounds are what turn a three-day questionnaire into a three-week one sitting in front of a signature.
Answer in one of four states — never blank, never a dodge
Every question can be answered honestly in one of four ways. Picking one deliberately is faster than writing prose, and it removes the two answers that cause damage: the blank cell, and the “N/A” used to mean no.
- Yes, and here is the evidence — the artifact, its date, and how it is shared (link, on request, under NDA).
- Yes, with a boundary — the control exists for production but not for the internal analytics stack; say which, precisely.
- No, and here is the compensating control — no SIEM, but centralized logs with 90-day retention and alerting on authentication anomalies.
- No, and here is the plan — with a quarter attached and an owner named. A dated commitment is a defensible answer; a vague intention is not.
A reviewer who finds one honest “no, and here is when” will trust the rest of the sheet more, not less. Uniform yeses are the pattern that invites a second round of questions.
The eleven artifacts that cover most of every questionnaire
Questionnaires differ in wording and length far more than in substance. Assemble these once, keep them in one place with dates on them, and most future questionnaires become a retrieval exercise rather than an investigation.
- An asset and data inventory: what systems exist, what data each holds, who owns it.
- A subprocessor register: vendor, purpose, data categories, region, DPA on file.
- A named security owner, and a named deputy for when they are on leave.
- The policy set, each with an owner and a last-reviewed date.
- Access control evidence: SSO and MFA coverage, joiner/mover/leaver process, last access review.
- Encryption posture: in transit, at rest, and where keys are managed.
- Logging and retention: what is logged, where it goes, how long it is kept.
- The most recent third-party test or assessment, with what was fixed and what was accepted.
- A vulnerability management statement: sources of findings, how they are prioritized, remediation targets.
- An incident response plan with a contact path, plus your customer notification commitment.
- Backup and restore evidence — including the date of the last restore you actually tested.
Two notes on that list. Put a date on every item — an undated policy reads as abandoned. And keep it in one folder with one owner, because the cost of a questionnaire is almost entirely the cost of finding things.
Four questions, answered weakly and answered defensibly
The difference is rarely the underlying control. It is specificity, dates, and saying what is not covered.
Four columns — scroll the table sideways →
| Question | Weak answer | Defensible answer | Why it lands |
|---|---|---|---|
| Do you perform annual third-party penetration testing? | Yes. | External application test completed by a third party in March 2026; report and remediation summary available under NDA. Two medium findings closed, one accepted with a documented compensating control. Next test scheduled Q1 2027. | The reviewer is checking for a date, a scope and what happened to the findings — not the word yes. |
| List all subprocessors with access to customer data and the data each receives. | AWS, and some standard SaaS tools. | Named list with purpose, data categories and region for each: hosting, transactional email, error monitoring (PII scrubbed at the client), payments (card data never touches our systems), support desk. Published at /subprocessors, updated on change. | This one is answered from a register or it is answered from memory, and memory is where the contradictions come from. |
| What is your remediation SLA for critical vulnerabilities? | We patch critical issues immediately. | Critical: triaged within 1 business day, remediated or mitigated within 7. High: 30 days. We prioritize on reachability and exploitability rather than CVSS alone, so a reachable high can be treated ahead of an unreachable critical; the reasoning is recorded per finding. | “Immediately” is unauditable. A number you actually meet beats a number that sounds good. |
| Do you have a formal information security policy set? | Yes, internally. | Nine policies, owner and last review date on each, approved by the CTO, reviewed annually. Index available on request; individual policies shared under NDA. | Existence is the low bar. Ownership and a review date are what distinguish a policy from a document. |
When the honest answer is no
Most questionnaires are scored by a human with discretion, and that discretion is exercised on the shape of the answer. A no that names a compensating control and a date is a manageable exception someone can write up. A no with nothing attached is an unresolved risk they have to escalate, and escalation costs them time they would rather not spend on your deal.
So the sentence to practise is: what we do not have, what we do instead, what we are doing about it, and by when. Four clauses. It is the same structure as a good finding write-up, and for the same reason — it separates the observation from the judgement, so a later reader can disagree with the judgement without re-doing the work.
Do not answer from memory
The most common self-inflicted wound is two people answering different questionnaires from recollection, six weeks apart, and giving incompatible descriptions of the same system. Reviewers do compare, and an inconsistency is more damaging than a gap, because a gap is a control problem and an inconsistency is a credibility problem.
One canonical answer set, one owner, versioned, with the date each answer was last confirmed. Then a questionnaire is copy-editing, and the only real work is the handful of questions the answer set does not cover yet — which is also the useful signal: those are your actual gaps, surfaced for free by someone else’s procurement process.
What this does not fix
A questionnaire describes what you intend to be true. It does not check it. Nothing in a spreadsheet tells you that a staging host is publicly reachable, that a subdomain still points at a service you decommissioned, or that your domain authorizes a very large number of addresses to send mail as you. Increasingly, reviewers look at the external surface themselves before they read your answers — and a contradiction between the two is the worst outcome of the whole exercise.
So pair the two habits. Keep the answer set current, and separately, look at your public surface the way an outsider does, ranked by what is actually reachable rather than by severity score — which is the subject of the companion guide, prioritizing security findings when everything is labelled critical.