The questions buyers now ask before they sign

The security questionnaire used to arrive after the commercial decision, as paperwork. It now arrives before it, and a weak response does not slow a deal down. It ends it.

Something has shifted in the last few years in how organisations buy software, and smaller suppliers have felt it first. The security review has moved forward in the process. It used to be a formality once terms were agreed. It is now a qualifying gate, often before a demonstration, and it is frequently run by somebody with the authority to say no on their own.

The reason is straightforward. Buyers have been burned by suppliers, and increasingly they are accountable to their own customers for their supply chain. A procurement lead who approves a vendor that later leaks data does not get to explain that the vendor seemed fine. So the questions have got sharper, more specific, and much harder to answer with reassurance.

What is actually being asked

The questions themselves are not exotic. What has changed is that they now expect evidence rather than assertion, and the evidence is expected to already exist. Assembling it under deadline is itself a signal, because a supplier who has to build an access log to answer a question about access logs has answered the question.

Data separation

Weak answer: our platform is multi-tenant and secure. Serious answer: tenant data is separated at the database layer, here is how the boundary is enforced, here is what happens if application code gets it wrong, and here is the test that proves the boundary holds.

Access control

Weak answer: only authorised staff have access. Serious answer: here is the role model, here is the list of who currently holds each role, here is the review we run quarterly, and here is the record of the last three revocations with timestamps.

Audit trail

Weak answer: all activity is logged. Serious answer: here is what is recorded against a change, how long it is retained, who can read it, who cannot alter it, and an example export for a record you nominate.

Incident response

Weak answer: we have a process and take security seriously. Serious answer: here is who is called, within what window you are notified, what you receive, and the date of the last time we rehearsed it.

Sub-processors

Weak answer: we use industry standard providers. Serious answer: here is the list, what each one processes, where it sits, and how you are told when it changes.

Why "we are fully secure" fails

The phrase is a category error. Security is not a state a system is in, it is a set of specific properties that either hold or do not, each of which can be demonstrated. A supplier who answers at the level of the whole system is telling the reviewer they have not decomposed the problem, which is precisely what the questionnaire is testing for.

It also fails for a practical reason. The reviewer usually has to pass the answer on to somebody else, often into a risk register or a board pack. An assertion cannot be forwarded. A specific, evidenced answer can, and it makes the reviewer look competent for having obtained it. Making your reviewer look good is an underrated commercial strategy.

The cost of assembling it late

When this evidence does not exist, the response is a scramble, and the scramble has three costs. The obvious one is time, usually two to four weeks of senior engineering attention taken from whatever it was doing. The second is that the answers produced under pressure are the accurate ones, and they are often worse than the team expected, which turns a sales process into an internal remediation programme.

The third cost is the one that hurts. Some of what is asked for cannot be produced retrospectively at all. If a system does not record who changed a record, no amount of urgency will produce a history for the last two years. The accurate answer becomes an admission, and it arrives at the least convenient moment, in writing, to a buyer who is deciding.

What having it in advance looks like

• A current architecture description that shows where data sits and how tenants are separated
• A written role and permission model, with a real list of who holds what
• Audit trails on the records a customer would ask about, with a stated retention period
• A short incident response plan naming actual people, and a date it was last tested
• A maintained sub-processor list, with a mechanism for telling customers when it changes
• A completed answer set for the common frameworks, kept current rather than rebuilt each time

That is not a certification programme, and for most businesses it should not be one yet. It is roughly a fortnight of work to produce properly, and then a modest maintenance overhead. The return is that the security review stops being an event and becomes a document you send, which changes the shape of the sales cycle far more than the effort suggests.

The organisations that handle this well are not usually the most secure ones. They are the ones that decided, at some point, to write down what was already true. That is a much smaller job than it sounds, and it is best done in a quarter when nobody is waiting for the answer.