The Security Questionnaire Has Quietly Become the Deal Gate, and Most Answers Fail It

The security questionnaire is no longer an administrative step after the commercial decision. In a growing number of enterprise purchases it is the decision, and it happens before the buyer has a champion strong enough to argue for an exception. Sales teams still treat it as paperwork owned by someone else, and that is where deals go quiet.

The counter-intuitive part is that saying no to a control is rarely what kills the review. Reviewers reject vendors over answers that were technically true, on time, and completely unusable. A confident "yes" with no supporting detail is worse than a well-argued "no", because the reviewer cannot file it, cannot defend it to their own risk committee, and has to come back. Every round trip costs weeks and reduces the buyer's confidence in the whole assessment.

What the reviewer is actually doing

They are assembling a defensible file. Their objective is not to determine whether you are secure in some absolute sense. It is to be able to demonstrate, later, that a reasonable assessment was performed and that the residual risk was recorded and accepted by a named person.

That reframes what a good answer looks like. A good answer is one the reviewer can paste into their own record without editing and without needing to ask you anything else. It contains the control, the scope of the control, the evidence, and the boundary of what it does not cover.

Compare these two answers to "do you encrypt data at rest":

Weak: Yes, all data is encrypted at rest using industry standard encryption.

Usable: Yes. Customer data in our primary Postgres instances and object storage is encrypted at rest with AES-256, using keys managed by the cloud provider's KMS with annual rotation. Application logs held in our observability platform for 30 days are encrypted at rest by that provider under their own key management, which we do not control. Backups use the same KMS keys as the source systems.

The second answer contains a limitation the first one hides, and it will pass more often. It shows the respondent knows the estate, which is the actual signal the reviewer is reading for. Vagueness reads as either ignorance or concealment, and both trigger follow-up.

The five failure modes

1. Answering a control question with a policy answer. "We have an access control policy" does not answer "is MFA enforced on administrative access". Name the mechanism and where it is enforced, not the document that says it should be.
2. Overclaiming scope. Saying all traffic is encrypted in transit when one legacy internal service is not. This survives the questionnaire and detonates during the audit, contract review, or first incident, at which point it is a misrepresentation rather than a gap.
3. Attaching a certificate instead of answering. A compliance report is evidence for the controls inside its scope statement. Reviewers who read the scope statement will notice that half their questions fall outside it, and the ones who do not read it will ask again anyway.
4. Inconsistency across the pack. The questionnaire says data stays in the EU, the sub-processor list includes a US analytics provider, and the architecture diagram shows a third region. Reviewers cross-check exactly these three artefacts, because inconsistency is the cheapest signal of an unreliable respondent.
5. Treating the AI questions as generic technology questions. This is now the most common route to a stalled review.

The AI section is where reviews stall

Questionnaires have grown a set of AI questions in the last two years, and most vendors answer them with hedged product language. Reviewers are not asking whether you use AI responsibly. They are asking a small number of specific, checkable things:

The question	What they are testing	What a usable answer contains
Which models and providers process customer data?	Whether an unmanaged sub-processor exists	Named providers, named models, and the data categories each receives
Is customer data used for training?	Contractual position, not intent	The contractual term and the account tier it depends on
What is the retention at the provider?	Whether deletion obligations can be met	The retention period, and whether abuse-monitoring logs are excluded from it
Who approves a new model or provider?	Whether governance exists or is ad hoc	The named role, the review step, and where the decision is recorded
How do you classify the risk of each AI use case?	Whether you can meet regulatory duties	Your tiering method and which tier this product sits in
What happens when the model behaves unexpectedly?	Whether incident handling covers AI failures	The detection route, the escalation path, and who can disable the feature

Answering these requires a real internal position on data flowing to model providers, including the difference between the consumer tier defaults and the enterprise terms most vendors assume they are covered by. The contractual and retention detail worth checking before you answer is set out in our guide on what happens when you send company data to AI providers.

The governance questions are harder to fake because they ask about process rather than configuration. If the honest answer is that a developer chose the model and nobody reviewed it, the fix is a lightweight approval step and a register, not better wording. The minimum structure that satisfies a reviewer without becoming a bureaucracy is covered in our guide to what an AI governance framework actually needs to contain.

Risk classification is now a regulatory question rather than a stylistic one for anyone selling into the EU, and reviewers increasingly want your tier and your reasoning rather than a reassurance. Our breakdown of how the EU AI Act risk tiers work is the reference to check your product against before a customer does it for you.

Build the answer bank before the deal

The teams that clear reviews fastest are not the most secure. They are the ones who wrote the answers once, with the engineers in the room, and keep them current. The work is front-loaded and it converts a two-month gate into a two-day one.

A minimum viable answer bank holds: your data flow map including every sub-processor, your control statements with their scope boundaries and named evidence, your sub-processor and model register, your most recent test report with its scope clearly stated, and a short list of known gaps with owners and target dates.

That last item is the one teams resist and reviewers value most. A vendor who volunteers three gaps with remediation dates is easier to approve than one who claims none, because the file the reviewer is building needs something to record as residual risk. Independent evidence carries the technical claims further than self-attestation does, which is the practical reason independent VAPT and penetration testing shortens these reviews: it converts assertions into findings with dates against them.

Do this next

Take the last three questionnaires you completed and find every answer that would need a follow-up question to be usable in the reviewer's own file. Rewrite those, with the engineer who owns the system, into control plus scope plus evidence plus boundary.

Then answer the six AI questions above properly, in writing, before the next one arrives. Those are the answers you will not be able to improvise, and the deal will be waiting while you try.