NexusSec.A customer has sent a security questionnaire. It runs to a dozen pages, the contract renewal is waiting on it, and nobody in the office is certain what half the questions mean. This is now one of the most common reasons a mid-sized Indian business contacts us, and the panic is almost always worse than the problem.
What the questionnaire is actually for
Your customer is not trying to fail you. They are managing their own risk. If they are a large enterprise, an exporter, or in a regulated sector, someone in their organisation has been told to check that suppliers with access to their data or systems are not an obvious hole. You are one of many suppliers being asked the same set of questions.
That matters for how you answer. The person reading your response is comparing it against other suppliers and against a checklist. They are looking for signs that security is somebody's job at your company, that you know what you have, and that you fix things when they are found. They are not expecting a bank's security programme from a 90-person manufacturer.
The six areas nearly every questionnaire covers
The format varies. The substance rarely does.
- Access control. Who can reach what, how accounts are created and removed, whether multi-factor authentication is used for remote access and administrative accounts.
- Network security. Whether you have a firewall, whether it is supported and updated, whether your internal network is separated or flat.
- Patching and updates. How operating systems, servers and network devices get updated, and how quickly.
- Testing. Whether you have had a penetration test or vulnerability assessment, when, and whether the findings were fixed.
- Backups and recovery. Whether backups exist, whether they have been tested by actually restoring something, and how long recovery takes.
- Incident response. What happens when something goes wrong, and who your customer would hear from.
Two of those, network security and testing, are where most questionnaires get stuck for businesses running their own infrastructure. If the honest answer to "when was your last penetration test" is "never", that is the gap worth closing first, because it is the one question where the evidence is a document you can attach. Our VAPT engagements exist largely because of this question.
Never guess an answer
This is the part worth taking seriously. A wrong yes is materially worse than an honest no.
If you answer yes to "is remote access protected by multi-factor authentication" because you assume it is, and a year later there is an incident traced to a password-only VPN account, you have a contractual problem on top of a security problem. You told your customer something untrue in writing, during procurement. Whether that was carelessness or not stops mattering at that point.
So check before answering. Every time. If nobody can confirm how remote access is configured, that itself is the finding, and it is better to discover it now than during an investigation.
When the honest answer is no
Write it as a plan with a date. "We do not currently enforce multi-factor authentication on remote access. This is scheduled for implementation by the end of Q3" is a legitimate answer that procurement teams accept routinely. A blank, or a vague "we follow industry best practice", is what gets escalated.
Frameworks like the NIST Cybersecurity Framework and the CIS Critical Security Controls are where most questionnaires ultimately come from. You do not need to adopt either formally. But if you want to know which gaps your customer is most likely to care about, the first handful of CIS controls covers the same ground as the first half of nearly every questionnaire.
An argument against spending money too quickly
We sell security testing, so treat this with appropriate scepticism, but it is true: not every questionnaire needs a penetration test to answer.
Some questionnaires ask only for policies. Some want a self-assessment. Some are asking whether you handle their data at all, and if the answer is that you never touch it, several sections become not applicable. Read the whole document before deciding what to buy. We have told businesses that what they actually needed was two hours of documentation work and a firewall rule change, not a test, and that remains the right advice when it is true.
Where a test genuinely is required, the thing to check is whether the report will be in a form your customer accepts. A tool-generated scan exported to PDF is not the same as a tested report with findings ranked and a retest after remediation, and procurement teams increasingly know the difference.
What to do this week
Read the questionnaire end to end before answering anything. Mark every question into one of three piles: we can answer this now, we need to check, and we do not do this yet. The middle pile is the real work, and it is usually smaller than it looks. Then find one person who owns the response, because questionnaires answered by committee take three times as long and contradict themselves.
If the checking pile includes anything about your network, firewall or remote access, a security assessment answers several sections at once and gives you the evidence rather than an opinion.