Security questionnaires from enterprise clients: how to answer them
How a small business answers a large client's security questionnaire honestly and well, and how to prepare so it stops being a scramble.
The short answer
When a large client sends a security questionnaire, they are checking that a supplier will not become their next incident. The questions are drawn from standard frameworks and written for organisations with security teams, which is why they feel overwhelming to a small business. Underneath, most of them map to a small set of facts about how you work: where and how the site or application is hosted, who has access and how it is controlled, where secrets live, how updates and vulnerabilities are handled, how backups work and are tested, what is monitored and who is alerted, what the incident response plan says, how personal data is collected, stored and deleted, and what security testing is done and when. Prepare a security summary that states those facts with evidence, and most questionnaires become an afternoon of mapping. Answer every question honestly, including not applicable and not yet with what you do instead, because the answers often become part of the contract and a false yes is both a legal and a relationship risk.
What the questions are really asking
| Questionnaire language | What it is checking | Your honest answer draws on |
|---|---|---|
| Information security policy | Are practices written down and owned? | One-page policies: access, passwords, secrets, incidents, data |
| Asset inventory | Do you know what you run? | The register of sites, systems and accounts |
| Access control and identity | Who can reach what, and how is it granted and removed? | Per-person accounts, second factors, the access register, offboarding checklist |
| Encryption in transit and at rest | Is data protected on the wire and on disk? | HTTPS and HSTS; managed services with encryption at rest; key handling |
| Vulnerability management | How fast do you fix known issues? | Pipeline scanning, advisory monitoring, update times by severity |
| Secure development | Is security built in? | Pipeline checks, code review, previews, testing sequence before launch |
| Logging and monitoring | Would you notice an incident? | What is logged, what alerts, who receives them |
| Incident response | What happens when something goes wrong? | The one-page plan, roles, notification commitments |
| Business continuity and backups | Can you recover? | Backup schedule, storage, tested restores, recovery times |
| Data protection and privacy | How is personal data handled? | Data map, retention, processing agreements, sub-processors |
| Third parties and sub-processors | Who else touches the data? | The list of services with roles and locations |
| Penetration testing and audits | Has anyone independent looked? | Test reports and summaries, retests, dates |
| Physical security and HR | Devices, premises, staff vetting | Device encryption, screen locks, what applies at your size |
| Certifications | Do you hold formal ones? | Honest status, and what you do in their place |
Preparing once
- Write the security summary covering each row of the table, in plain language, with links or attachments as evidence.
- Collect the evidence: platform settings, scan reports, test summaries, the incident plan, the access register, the data map, processing agreements.
- Name the gaps honestly, with what you do instead and any plan to close them.
- Keep it current quarterly and after any material change.
- For each questionnaire, map questions to the summary; answer not applicable where true, with a reason.
- Offer the summary up front to new enterprise clients; it often shortens or replaces the questionnaire.
- Keep copies of what you submitted, because it will be referenced later.
Where a small business is genuinely strong
A static site with no server code, no database and no public admin has a smaller attack surface than most enterprise applications, and saying so plainly, with the architecture described, answers many questions at once. A pipeline with scanning on every change is better practice than many large organisations achieve. Ownership in your own accounts, secrets in platform storage and per-person access with second factors are exactly what the questionnaire hopes to find. A small business that works this way should describe it with confidence, because it is the substance the questions are looking for.
What this means for you
Treat a security questionnaire as a check that you will not become the client’s incident, and answer it from a prepared security summary that states how you host, control access, handle secrets, update, back up, monitor, respond, handle data and test, with evidence. Answer honestly, including not applicable and not yet, and describe your proportionate practice with confidence where it is strong. Prepared once and kept current, questionnaires stop being a scramble and start being a sales asset.
Frequently asked questions
The questionnaire assumes we are a large company with a security team. How do we answer?
By translating each question to what it is checking and answering with what you actually do. A question about your security operations centre is asking whether anyone would notice an incident; the answer is your monitoring and alerting and who receives it. A question about your policy framework is asking whether practices are written down; the answer is your one-page policies. Not applicable, with a sentence on why, is a valid and respected answer where it is true.
Can we just answer yes to everything to get through it?
No. The answers become part of the contract in many cases, they are checked in audits and after incidents, and a false answer discovered later ends the relationship and can create liability. A questionnaire answered honestly with a few gaps and a plan for them is far stronger than one answered with yeses that do not survive a follow-up question.
How do we stop this being a week of work every time?
Write the security summary once: how the site or application is hosted, who has access and how, where secrets live, how updates happen, how backups work and are tested, what is monitored, what the incident plan is, how personal data is handled, what testing is done and when, with evidence for each. Update it quarterly. Then each questionnaire is mapped to it in an afternoon, and the summary itself often satisfies the client before the questionnaire is needed.