It usually arrives from procurement, attached to a renewal or a new programme award. Two hundred questions, a two-week deadline, and a covering note explaining that completion is a condition of continuing to supply.
The instinctive reaction is that this is an IT problem. It is not, quite. It is a documentation problem with an IT component, and understanding that difference is what turns a fire drill into an afternoon.
Most of the questions are not about technology
Read the questionnaire properly and you will find that a large share of it asks whether you have a policy, whether somebody owns a process, whether an assessment has been performed, and whether you review something on a schedule.
Those are answerable regardless of what your infrastructure looks like. What they require is that somebody has written things down and can produce them.
The genuinely technical questions are usually a minority, and they cluster: multi-factor authentication, patching, backups and their testing, logging, endpoint protection, and access control for departing employees. Those six carry most of the weight in most questionnaires, and they are also the six that cyber insurers ask about, which means work you do here has two payoffs.
Answer honestly, particularly when the answer is no
The temptation under deadline is to answer the way you think the customer wants. Resist it.
A questionnaire is a representation. If you say you have tested backups quarterly and you have not, you have created a contractual exposure that survives long after whoever completed the form has left. The same answer given honestly, with a remediation date attached, is almost always accepted. Procurement teams are used to gaps. They are much less tolerant of discovering a gap they were told did not exist.
"No, and here is when it will be yes" is a good answer. "Yes" that cannot be evidenced is the worst one available.
Build the evidence set once
The reason questionnaires feel endless is that each one is answered from scratch, by a different person, in a different format, under a different deadline.
The alternative is to maintain one evidence set: a current risk register, a set of policies that reflect what you actually do, a network diagram, an access control procedure, backup and recovery test records, and an incident response plan somebody has read. Assembled once, it answers most of what any customer, insurer, or auditor asks, with translation rather than reinvention.
That set also does something quieter and more valuable. It makes the next questionnaire a two-hour job for one person instead of a two-week scramble across four.
Use it as leverage, not just compliance
There is an argument to be made internally here that is worth making.
A customer asking these questions has told you something useful: security posture is now a condition of the commercial relationship. That reframes the security budget from a cost centre to a requirement of revenue, and it is far easier to fund controls described as "what keeps the programme award" than as "IT wants firewalls."
The same evidence set also shortens sales cycles with the next large customer who asks, and it lowers friction at cyber renewal. Three returns from one piece of work.