How to Answer an Enterprise Security Questionnaire Without a Security Team
7 min readCustomer Trust & Compliance
The deal was going well. Then procurement forwarded a spreadsheet with 214 questions, several of which appear to be asking whether you have a Chief Information Security Officer, and the account executive wants to know when you can turn it around.
This is a moment that catches every growing company, and it is worth understanding correctly, because the instinctive responses — panic, bluff, or ignore it — are all expensive.
What the questionnaire is really asking
Behind the 214 questions there are only three, and every one of them is about the buyer, not about you:
- If we give you our data, how likely are you to lose it?
- If you do lose it, how bad will that be for us — and will we find out from you or from the news?
- Is there a competent adult on the other side of this contract?
The person reviewing your answers is not a hostile auditor. They are usually one overworked analyst in a vendor-risk team with a queue of these, and their actual job is to produce a defensible risk decision — a paper trail showing that a reasonable assessment was performed. They are not looking for perfection. They are looking for evidence that you have thought about this and that nothing they read will make them look negligent later.
That reframing changes everything about how you should answer. You are not trying to score 214 out of 214. You are trying to be the kind of vendor a reasonable analyst can approve.
Answer honestly — "no, and here's our plan" beats a bluff
The strongest position available to a small company is calibrated honesty, and it beats an inflated answer for three reasons.
You will be caught, and being caught is fatal. Questionnaires contain overlapping questions on purpose. Claiming a formal incident response programme in one answer and admitting elsewhere that you have never run a tabletop exercise is a contradiction the analyst is specifically trained to notice. The moment one answer is exposed as inflated, every other answer is re-read with suspicion, and a review that was heading for approval becomes an escalation.
It is a contractual representation. These answers typically end up attached to or referenced by the contract. A false statement about your security controls is not an awkward conversation, it is a breach — and after an incident, it is the first document anyone's lawyers read.
"No, and here is our plan" reads as maturity. An analyst who sees a vendor that knows exactly what it does not do, and has a dated plan to fix it, is looking at a company that understands its own risk. That is genuinely rarer, and more reassuring, than a wall of yeses.
So the formula for every gap:
"Not currently. [One sentence on what we do instead, or why the risk is limited in our context.] This is on our roadmap for [specific quarter]."
Concretely: "We do not currently hold SOC 2. We follow the CIS Controls as our framework, enforce phishing-resistant MFA on all systems, and encrypt customer data at rest and in transit. We plan to begin a SOC 2 Type I readiness assessment in Q3."
That answer will pass reviews that a bare "no" fails and a fabricated "yes" fails catastrophically. The compensating control and the date are what make it work — never give a bare no, and never give a date you do not intend to hit.
The twelve answers that appear in every questionnaire
Different formats — SIG, CAIQ, a bank's bespoke spreadsheet, a two-page startup version — ask the same underlying things in different words. Prepare these twelve and you have most of any questionnaire:
- Access control. How access is granted, reviewed and revoked; whether MFA is enforced; whether administrator rights are limited. (offboarding, MFA)
- Encryption. At rest and in transit, and what key management looks like. For most SaaS companies this is largely a description of what your cloud provider does, which is a perfectly good answer.
- Data handling. What customer data you hold, where it physically lives, how long you keep it, how it is deleted on request and at contract end.
- Subprocessors. Which third parties touch customer data, and how you assess them. Have the list ready; you will be asked for it.
- Backups and recovery. Frequency, retention, whether restores are tested and when you last tested one. (backups)
- Incident response. Whether you have a documented plan, who owns it, and — the question with contractual teeth — how quickly you will notify the customer. Know what you are willing to commit to before you write a number.
- Business continuity. What happens if your office, your cloud region, or your key person is unavailable.
- Secure development. Code review, dependency scanning, separation of production and test, whether production data is used in testing. (The correct answer to the last one is no.)
- Vulnerability management. How you learn about vulnerabilities, how fast you patch, whether you have had a penetration test.
- Personnel. Background checks, security training at onboarding, confidentiality agreements.
- Physical security. For a remote or cloud company, mostly your provider's data centre certifications plus your device policy.
- Compliance and privacy. GDPR roles and lawful basis, willingness to sign a data processing agreement, sector rules where relevant, and any certifications you hold.
Notice how many of these are things you either already do or can do in a fortnight. The questionnaire is intimidating in volume, not in substance.
Get the 31-point security checklist
The checklist, then one email a week on what changed and what a company your size should do about it.
Weekly. Unsubscribe in one click. See the checklist first.
Build the reusable answer bank
The real cost of questionnaires is not the first one. It is answering the same twelve topics from scratch, differently, for every deal — with inconsistencies that show up when two customers compare notes, or when the same analyst sees your answer twice.
Build this once:
A single answer document. One row per topic: the question in its common phrasings, your canonical answer, the evidence that backs it, the owner, and the date last reviewed. When a new questionnaire arrives, you are copying and adapting rather than composing under deadline.
A security page on your website. Public, plain, honest. Your architecture in a paragraph, where data is hosted, encryption, access control, subprocessor list, how to report a vulnerability, and a contact address. A surprising number of reviews are satisfied by a good public page plus a short call, and it means buyers self-serve before your team is involved.
A trust packet ready to send. Your security page, your answer document, your DPA template, your subprocessor list, your architecture diagram, and any certifications. One folder, one link.
A named owner. Not "sales when it comes up". One person who keeps the answers current and reviews them quarterly. At your size this is usually a founder or the senior engineer, and it should be an explicit part of the job, because the failure mode is answers that quietly go stale and become inaccurate — which returns you to the contractual-representation problem above.
Two practical habits: read the questionnaire before promising a turnaround, because a full SIG is days of work, not an afternoon; and ask which questions are blocking. Buyers will often tell you that only a dozen are mandatory for their risk tier, and that conversation alone can turn a week into a morning.
Do we actually need SOC 2?
The honest answer is: probably not yet, and you will know precisely when you do.
You need a formal certification when deals you want are being lost because you do not have one — not when a competitor mentions it, not when an investor asks, not as a general aspiration. It is a revenue decision with a cost and a payback period, and it should be made with a specific number of blocked deals attached.
What to know before committing: SOC 2 is an audit of controls you define, not a fixed standard, so a Type I says your controls existed on a date and a Type II says they operated over a period, typically three to twelve months. That period is why timelines are long — you cannot compress observation. Budget for auditor fees, compliance tooling, and a meaningful amount of internal time; and expect the whole thing to take a couple of quarters minimum from a standing start. ISO 27001 is the more common expectation outside North America and is a management-system certification rather than a control audit.
In the meantime, the interim positions that work: implement a recognised framework and say which one — the CIS Controls or NIST CSF are both defensible and free to adopt; offer a security review call with a technical founder, which frequently satisfies buyers more than a document would; get a penetration test once you have something worth testing and share the summary letter; and give buyers a written commitment with a date if certification is genuinely coming.
And when you do start, the questionnaire work above is not wasted — the answer bank is the first draft of your control documentation.
Turning a blocker into a differentiator
The final reframe, and the one worth acting on.
Your enterprise competitors are large, and their security reviews are slow: weeks of routing between teams, generic answers from a compliance portal, no access to anyone who actually built the system. Yours can be same-week, specific, and answered by the person who wrote the code.
Companies that treat security review as a sales capability rather than a tax do three things: they publish the trust packet before anyone asks; they respond within days; and they let the buyer speak to a technical founder. That combination closes the credibility gap that certification is supposed to close — often faster, and while the deal still has momentum.
The questionnaire is not an obstacle in the deal. At a certain size of customer, it is the deal.