The questions buyers now ask before they sign

Security questionnaires used to arrive as paperwork after the buying decision had been made. They now arrive before it, and a weak response does not just slow a deal down. It ends it.

Over the last few years, the way organisations buy software has changed, and smaller suppliers have felt it first. The security review now happens much earlier. It used to be a formality once terms had been agreed. Now it is a condition that must be met, often before a demonstration, and it is frequently run by someone who can reject a supplier on their own authority.

The reason is simple. Buyers have had bad experiences with suppliers, and they are increasingly answerable to their own customers for the suppliers they use. A procurement manager who approves a supplier that later leaks data cannot defend the decision by saying the supplier seemed fine. As a result, the questions have become sharper and more specific, and much harder to answer with reassurance alone.

What buyers are actually asking

The questions themselves are not unusual. What has changed is that buyers now expect evidence rather than claims, and they expect that evidence to exist already. Having to put it together against a deadline is itself a warning sign. A supplier that has to create an access log in order to answer a question about access logs has, in effect, already answered it.

Data separation

A weak answer: “Our platform is multi-tenant and secure.” A strong answer explains that each customer’s data is separated in the database, how that separation is enforced, what happens if the application code gets it wrong, and which test proves that the separation holds.

Access control

A weak answer: “Only authorised staff have access.” A strong answer shows the roles, who currently holds each one, the review carried out every quarter, and the record of the last three times access was removed, with dates and times.

Audit trail

A weak answer: “All activity is logged.” A strong answer explains what is recorded when something changes, how long records are kept, who can read them and who cannot alter them, with an example export for a record the buyer chooses.

Incident response

A weak answer: “We have a process and take security seriously.” A strong answer states who is called, how quickly the customer will be told, what information they will receive, and when the process was last rehearsed.

Sub-processors

A weak answer: “We use industry-standard providers.” A strong answer lists each provider, what data it handles, where it is based, and how customers are told when the list changes.

Why “we are fully secure” does not work

The phrase misunderstands what security is. Security is not a single state that a system is either in or not. It is a set of specific properties, each of which either holds or does not, and each of which can be demonstrated. A supplier who answers about the system as a whole shows the reviewer that they have not broken the problem down, which is exactly what the questionnaire is designed to test.

It also fails for a practical reason. The reviewer usually has to pass the answer on to someone else, often for a risk register or a board report. A general claim is of no use to them. A specific answer backed by evidence can be passed on, and it makes the reviewer look good for obtaining it. Helping the reviewer look good is an underrated sales strategy.

The cost of putting evidence together late

When the evidence does not already exist, the response becomes a rush, and that rush has three costs. The obvious one is time, usually two to four weeks of senior engineers’ attention taken away from their normal work. The second is that the honest answers produced under pressure are often worse than the team expected, which turns a sales process into an internal project to fix things.

The third cost is the most damaging. Some evidence cannot be created after the event 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 honest answer becomes an admission, and it arrives at the worst possible moment, in writing, to a buyer who is making a decision.

What it looks like to be prepared

• An up-to-date description of your architecture, showing where data is stored and how customers are kept separate
• A written description of roles and permissions, with an accurate list of who holds each one
• Audit trails on the records a customer would ask about, with a stated retention period
• A short incident response plan that names real people, and the date it was last tested
• An up-to-date list of sub-processors, and a way of telling customers when it changes
• Completed answers for the common security frameworks, kept up to date rather than rewritten each time

This is not a certification programme, and for most businesses it should not be one yet. It takes about two weeks of work to do properly, followed by a small amount of ongoing maintenance. In return, a security review stops being a major event and becomes a document you send, which shortens the sales process far more than the effort suggests.

The organisations that handle this well are not usually the most secure. 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 at a time when nobody is waiting for the answer.