
Answering a supplier security questionnaire without a compliance team
A questionnaire lands in your inbox from a customer you have worked with for years. Sixty questions, a spreadsheet, a deadline, and no obvious owner inside your organisation. Nothing about your service has changed. What changed is that your customer now has obligations that reach down their supply chain, and you are in it.
A clear no with the compensating control named is more useful to the reviewer than a vague yes.
An answer you cannot evidence is worse than no answer, because it sets an expectation you will be measured against later.
Build one reusable answer set with pointers to evidence, and every questionnaire after the first becomes a mapping exercise.
What the questionnaire is actually for
This is the practical face of regulation for most organisations. You may never read NIS2 or answer to a regulator directly. You will answer to a customer who does.
It helps to understand what the person on the other end needs. They are not trying to catch you out. They need evidence they can put in a file, so that when someone asks them how they assessed their suppliers, they have an answer with a date on it.
That has two consequences. First, a clear "no, and here is what we do instead" is usually more useful to them than a vague yes. Second, an answer that cannot be evidenced is worse than no answer, because it creates an expectation you will be measured against later.
The questions that carry weight
Most questionnaires are long, and most of the length is not where the risk sits. A handful of areas come up in almost every one, and these are the ones worth preparing properly.
Access control. Who at your organisation can reach the customer's data or systems, how is that access granted and reviewed, and is multi-factor authentication enforced. If you support a customer's environment, this is the question they care about most, because your access is their exposure.
Incident handling. What happens when something goes wrong, who decides, how quickly do you notify them, and through which channel. Notification timelines are increasingly written into contracts, not just questionnaires.
Backup and recovery. Not whether you have backups. Whether you have restored from them, when, and what the result was. "Backups run nightly" answers a different question than the one being asked.
Subprocessors. Who else touches the data. Cloud platforms, monitoring tools, any partner you use for out-of-hours cover. Customers increasingly need this list, and assembling it for the first time under deadline pressure is unpleasant.
Logging and retention. What you record, where it is kept, and for how long. Short retention is a common finding, because defaults are short and nobody changed them.
Personnel. Screening, confidentiality agreements, security awareness, and what happens when someone leaves. This is where offboarding and questionnaires meet.
Build the answer set once
The single biggest improvement is to stop treating each questionnaire as a new project. Almost all of them ask the same things in different words.
Create one internal document that answers each of the areas above in plain language, with a pointer to the evidence. Not the evidence itself: a pointer, so the document stays readable and does not go stale as fast. For each answer, record who owns it and when it was last checked.
The first time you build this, it takes a day or two of real work. Every questionnaire after that becomes a mapping exercise rather than a research exercise, and the quality of your answers goes up because they were written calmly rather than the night before a deadline.
How to answer honestly when the answer is no
You will not tick every box. The way you handle that is more revealing to your customer than the gap itself.
Three formulations work well:
- No, and here is the compensating control. "We do not have a formal SOC. We do have centralised logging with alerting on a defined set of conditions, monitored during business hours, with out-of-hours escalation."
- No, and it is on the plan with a date. A gap with an owner and a target date reads as management. A gap with neither reads as absence.
- Not applicable, and here is why. If a question assumes an architecture you do not have, say so rather than answering the question you wish had been asked.
What does not work is a yes you cannot evidence. If the customer follows up and asks for the policy, the log sample, or the restore report, an unsupported yes turns a routine review into a problem.
The evidence that is worth having ready
Regardless of the questionnaire, a small set of artefacts covers most requests:
- A written access policy, however short, with a review date
- An incident procedure with named roles and notification steps
- The most recent restore test, with the date and the outcome
- A current list of subprocessors and what each one does
- A short summary of your logging: what, where, how long
- Confirmation that security awareness training happened, and when
None of this requires a compliance team. It requires deciding once that these six things exist, keeping them current, and knowing where they are.
The reframe worth making
It is easy to treat these questionnaires as an administrative tax. They are more useful than that. They are the only regular external prompt most organisations get to check whether the things they believe are true about their own IT actually are.
The first questionnaire is painful. If it produces a maintained answer set and six pieces of current evidence, the second one is an afternoon, and you have a clearer picture of your own operation than you had before it arrived.
Questions we get about this
The ones that come up most often once this is on the table.
Can we simply refuse to fill one in?
You can, and occasionally that is right for a small contract with a disproportionate questionnaire. But increasingly it is a contractual condition rather than a request, and refusing means the contract does not renew. Negotiating the scope is usually more productive than refusing outright.
What if it asks about a certification we do not have?
Answer what you do have. ISO 27001 or SOC 2 makes the conversation shorter, but their absence is not disqualifying if you can evidence the underlying controls. Name the controls you operate and say how you demonstrate each one.
Should we get certified just to make these easier?
Certification earns its cost when customers keep asking, when it unlocks a segment you want, or when you need the internal discipline. As a shortcut to avoid paperwork it is expensive. Count how many questionnaires you actually receive in a year first.
Who should sign it off internally?
Whoever can be held to the answers, which means someone with authority over both the technical reality and the commercial relationship. An engineer filling it in alone tends to over-promise on process. A salesperson filling it in alone tends to over-promise on everything.
Where this sits with us
The services this subject falls under.
Questionnaire on your desk and nowhere obvious to start?
We go through it with you once, and what comes out is a reusable answer set with the evidence pointed to. Half a day for the first one. The next one is an afternoon.
Practical IT knowledge in your inbox
New guides on management, security and the workplace, written by the people doing the work. No sales talk, and you can unsubscribe in one click.