A big customer sent you a security questionnaire. Here's what they're actually asking.
I was a young IT staffer doing server maintenance late at night, out of hours, the way you do when you can’t take anything down during the day. There was a new box being prepared for an upcoming contract, and an old one that had to stay exactly where it was. I made a mistake about which terminal I was logged into, and I reformatted the wrong server.
Cue panic.
What saved me was luck, not process. One of the development team happened to be running a clone of that server in another lab. We had the data back. I have set up and checked routine backups ever since, and I have never again assumed that “we have backups” and “we can restore” are the same sentence.
That is the whole reason a security questionnaire asks about backup and recovery. Not to collect a policy document. To find out whether the night I just described would end your company or merely ruin your evening.
Why a security questionnaire is suddenly landing on a small business
Nobody sends you an 80-line spreadsheet to be difficult. When you supply a bigger, regulated, or security-conscious customer, their obligations flow downhill to you as contract clauses, questionnaires, and insurance requirements. Their risk assessment now includes you, because you are a door into their environment.
Three things are pushing this at once. Large customers are hardening their supply chains after watching peers get breached through a small vendor. Cyber-insurers have tightened what they’ll underwrite and now ask real questions before renewing. Regulation like NIS2 has widened the set of firms that must manage supplier risk, which means their suppliers get asked too. Plenty of these forms arrive from customers who aren’t in scope of anything.
NIS2 is one driver, not the whole story.
The form itself is rarely custom. Most are built from the same few templates: the SIG, the Cloud Security Alliance’s CAIQ, or something derived from NIST SP 800-171. I’ve answered against those control sets, and against ISO and NIST 800-53, including accreditation for government classified facilities running on isolated networks. I mention it for one reason: after enough of them you stop seeing a hundred unrelated questions and start seeing six concerns asked a hundred ways. This is a translation problem, and the questions are far more predictable than they look.
What the scary sections are really asking
Asset inventory, including software and tools. This is the section everyone underestimates. It’s tedious, it drags in vendor reviews, and it gets out of hand fast if you don’t scope it tightly. It is also the one that matters most, because you cannot reason about your security without knowing what your suppliers and tool providers are doing with your data. The question underneath is: do you know which of your vendors is your weakest link?
Multi-factor authentication. It sounds trivial. An extra step that didn’t need to be there. It is the single biggest differentiator between the firms that get breached and the firms that get probed and passed over. When a customer asks about MFA, they are asking the highest-signal question on the form.
Backups. See above. Most IT staff are stretched thin, and checking backups quietly becomes a box you tick, then a thing that never happens. The question is not whether backups exist. It’s when you last restored from one.
Incident response. Usually talked about, rarely exercised. No matter how much preparation you’ve done, when it happens the adrenaline still kicks in. What saves you is not the calm you imagine having; it’s the rehearsals you did as a team and the systems you put in place beforehand.
Data labeling and handling. This one goes wrong in the other direction: teams get so wrapped around the minutiae of classification that the scheme collapses under its own weight. Keep two to four high-level classifiers with very simple instructions on their use and meaning, something like: “public,” “private, never release,” and “requires permission to share.” Departmental sub-classifiers below that are fine. But write the top level assuming the reader has never opened the Information Security Policy. They probably haven’t. If they did, it was years ago, it has changed since, and they’ve forgotten most of it.
Sometimes the control doesn’t fit you
One of the hardest requirements we ever faced was the strictness of the MFA control on a government programme: it demanded a physical token, issued by the government, at a cost that was crippling for a small firm.
We didn’t fake it and we didn’t eat the cost. We read the controls closely enough to understand what they were protecting, then rescoped the system to run isolated (which it could do without losing effectiveness) and the requirement changed shape with it.
That is the skill, and it’s worth saying plainly: sometimes a control is written for an organisation ten times your size, or for a technology stack the framework’s authors never anticipated. The job is finding the compliant path, not faking it.
Answering truthfully is the actual job
The questionnaire isn’t the work. Being able to answer it truthfully is the work. The gap between those two things is where firms get hurt.
Take password security and training. Every firm says it does both. Many hand-wave it, with weak technical controls and no way to hold anyone to using the password manager they bought. The answer on the form says yes. The reality says maybe.
Or software installation. I’ve seen a user install a Chrome extension for non-business reasons and infect their device with it. We contained it before any data left the building, but it was close. Somewhere on that firm’s questionnaire was a line about restricting software installation, and the honest answer had been drifting away from the written one for a while.
Fudge an answer and you’re not just risking the audit. You’re risking the breach the question was designed to prevent, and the contract, when it later surfaces that you said otherwise in writing.
The handful of controls that answer most of the form
The good news in all of this: the six concerns above collapse into a short list of things to fix. Do these, and most of the form answers itself.
- MFA everywhere. No system is ever “too low risk” for a second factor. It isn’t only about protecting that system. It’s about the habits and rituals your team builds around security.
- Password managers. The fastest way to help employees is to remove passwords where you can, with security keys, and to give them a strong generator and vault everywhere else, so they only have to remember one master password. The trick is making sure that master password is a very strong one: NIST’s guidance favours long passphrases over forced complexity and rotation.
- Least privilege, with account segregation. This is not only about locking down who can do what. Admin actions should only be performed from admin accounts. Do not let the CEO, the president, or the IT admin’s personal account be the one carrying all the access, when that person is also the most-targeted individual in the company. Security through obscurity is not a tactic; operational security is. Spread the permissions out and the blast radius of any one compromised account shrinks with them.
- An incident response plan people can follow under stress. Every emergency room in the world uses checklists. My military background taught me the value of short, ordered instructions and clear decision trees. A written policy for executives is not enough. In a crisis nobody has time to read, interpret, and argue about policy. You need a simple technical instruction and a workflow diagram everyone agreed on in advance, and you need to rehearse it. Yes, rehearsals take time and cost money. An hour or a half-day, with something team-building attached (hint: everyone loves a free lunch), and the whole company gets better at it.
Someone somewhere once told me -
A plan you’ve never tested isn’t a plan, it’s a theory.
Most firms can do the basics on this list themselves, and should. What outside help buys you is speed, and knowing which gaps will cost you the contract. If a questionnaire is sitting on your desk and you’re not sure whether your honest answers are good enough, that’s a conversation worth having; it’s what our Security Configuration & Consultancy work exists for.
References & further reading
Sources cited in this post:
- NCSC Ireland — NIS2 hub — https://www.ncsc.gov.ie/nis2/
- Shared Assessments — SIG questionnaire — https://sharedassessments.org/sig/
- Cloud Security Alliance — CAIQ — https://cloudsecurityalliance.org/research/caiq
- NIST SP 800-171 — https://csrc.nist.gov/pubs/sp/800/171/r3/final
- NIST SP 800-63B (digital identity guidelines) — https://pages.nist.gov/800-63-3/sp800-63b.html
Related reading on this site: