Your first enterprise security questionnaire: how to answer it honestly

It arrives late in a sales cycle, usually as a spreadsheet, usually from someone you have not spoken to before, and usually with a date on it. Two hundred rows of yes-or-no. The account executive treats it as paperwork; it is not paperwork, and answering it badly is one of the more common ways a technically sound product loses a deal it had already won.

The good news is that the exercise is far more tractable than its length suggests. Most of the rows are asking the same dozen things in different words, the assessor already expects a young company to have gaps, and the answers that fail are almost never the honest negative ones.

What the questionnaire is actually for

A vendor security questionnaire is not a test you pass. It is a file the buyer’s security function has to be able to produce later, when their own auditor, insurer or regulator asks how they assured themselves about a third party holding their data. Understanding that changes how you write.

The person reading your answers is trying to close their own obligation. They need a defensible record, not perfection. An answer that is specific, verifiable and slightly disappointing is worth more to them than an enthusiastic one they will have to justify if it turns out to be untrue.

You are not being asked to be secure enough. You are being asked to be describable, so that somebody else can write down why they accepted you.

The shapes these arrive in

• A standard framework questionnaire. The Cloud Security Alliance publishes one widely used set of consensus questions, and several industry bodies publish others. These are long, structured, and much easier to answer a second time.
• A bespoke spreadsheet assembled by the buyer, often inherited from a previous procurement and never fully edited. Expect questions about physical data-centre access from a company that knows you run on a cloud provider, and answer them plainly rather than argue.
• A certification shortcut. Buyers who accept ISO/IEC 27001 certification or a SOC 2 report will often replace most of the questionnaire with a request for the document. If you hold neither, you answer the long version, which is the normal position for a company selling its first enterprise contract.
• A short pre-qualification form, which is a filter rather than an assessment. The full version follows if you clear it, so answer the short one as though the long one is coming, because it is.

The only three answers worth giving

1. 01Yes, and here is the evidence. A one-line description of the control and where it is documented. Never a bare yes on a question that matters; a bare yes invites a follow-up call and loses a week.
2. 02No, and here is what we do instead. This is the compensating-control answer, and it is the one that most often converts a red row into an accepted one. State the risk the question is aimed at and how your arrangement addresses it.
3. 03Not yet, and here is the date. A commitment with a quarter attached is a legitimate answer in most assessments, provided the quarter is real and you write it down somewhere you will be held to.

There is no fourth answer. A vague yes, an answer that describes an intention as though it were a practice, or a claim about a control that exists in a document but not in the product will eventually be checked, and being caught on one row causes the assessor to re-read every other row with suspicion.

The questions that actually decide it

Strip out the duplication and most questionnaires turn on a small number of subjects. These are the ones worth preparing properly before the spreadsheet arrives.

• Tenant isolation and access control. Multi-tenant products get asked how one customer is prevented from reaching another’s data, and the credible answer describes testing rather than architecture. Having actually pointed one tenant at another is the difference, which is why SaaS teams hit this row first.
• Encryption in transit and at rest, stated as configuration rather than as adjectives. Which protocol versions, which key management, and who can decrypt.
• Logging, retention and monitoring. What is recorded when someone accesses customer data, how long it is kept, and whether anyone would notice an anomaly.
• Incident response, including the notification window you commit to. This is frequently the row that becomes a contract clause, so answer it with a number you can meet at 3am on a Sunday.
• Sub-processors and data location. Who else touches the data, in which jurisdiction, and under what agreement. Buyers want the list, not the assurance that a list exists.
• Joiners, movers and leavers. How access is granted and, more importantly, how quickly it is removed. Small teams frequently have no answer here and the fix costs a morning.
• Secure development and vulnerability management. How dependencies are tracked and patched, how code reaches production, and who reviews it.
• Backup and restore, tested rather than configured. The question is when you last restored, not whether backups run.

The row about security testing

Almost every questionnaire asks when your application was last tested by a third party and asks for the report or a summary. Read the wording of that row carefully, because it is the one place where a plausible answer can be the wrong answer.

If the question asks for independent security testing with findings and remediation evidence, an OWASP-based assessment answers it: reproduced findings, severity reasoning, a fix pass and a retest, in a report you can attach or summarise. If the question specifically names a certified penetration test by an accredited provider, or requires an attestation letter, that is a different product and we are not the supplier for it. We are not accredited and we issue no conformance statements, and the distinction between the two documents is worth settling before you commit to a date.

Your own suppliers become part of the answer

The section that surprises first-time respondents is the one about your supply chain. If an external team writes your code, tests it, or holds credentials to your systems, they are in scope of the buyer’s assessment whether or not they appear on your sub-processor list.

Expect to be asked where those people are, what they can access, whether their access is separately provisioned and revoked, and what contract governs it. Where a supplier sits matters commercially as well as legally, because a transfer of personal data outside the General Data Protection Regulation area is a question the assessor has to escalate, while an arrangement inside it is one they can close on the spot. That is the practical argument for keeping delivery partners close, and it is worth stating in the answer rather than leaving to be discovered.

Build the library on the first one

The first questionnaire costs a fortnight of somebody’s attention. The second should cost an afternoon, and the difference is entirely in whether you kept the answers.

1. 01Keep every answer in one document, organised by subject rather than by the buyer who asked. Questions are worded differently and ask the same thing.
2. 02Store the evidence next to the answer: the policy, the configuration, the report, the ticket. Assessors ask for it roughly a third of the time.
3. 03Date each answer and re-check anything older than a year. A library that goes stale is how an honest company ends up making a false statement.
4. 04Record the commitments you made with dates attached, and treat them as a backlog rather than as sales language.
5. 05Give one person ownership. Questionnaires answered by whoever is free produce contradictions between rows, and a contradiction reads worse than a gap. This is one of the places where a defined engagement process saves more time than it costs.

The uncomfortable truth is that most of the work is not security work. It is writing down, once, what you already do, and being disciplined about the places where the honest answer is that you do not do it yet.