You've been talking to a real company for a couple of months. They like the product. Then procurement sends over a spreadsheet with 150 security questions and a deadline.
This is normal. It's also where a lot of small companies panic and start writing "yes" to things that aren't quite true. Don't do that. Here's how to get through it.
What they're actually asking
Every questionnaire looks different, but most of them ask about the same handful of things:
- Independent testing. Have you had a pen test in the last 12 months? Can we see the results?
- Certifications. SOC 2? ISO 27001?
- Encryption. Is data encrypted in transit and at rest?
- Access. Do you support SSO? Is MFA required for employees? Who can get into production?
- Incident response. Do you have a written plan? How fast will you tell us about a breach?
- Data handling. Where is data stored, how long do you keep it, and can you delete it on request?
- Subprocessors. Which third parties touch our data?
- Vulnerability management. How do you find and patch security issues?
- Backups. How often, and have you ever actually tested restoring from them?
Behind all of it, the reviewer is trying to answer one question: if we give this company our data, how likely is it to end up somewhere it shouldn't?
Answer honestly
The reviewer on the other end has read hundreds of these. They can tell when a four-person startup claims a 24/7 security operations center.
"No, but here's what we do instead" is a completely fine answer. So is "Not yet, planned for Q1." Reviewers expect small companies to have gaps. What they're checking is whether you know where your gaps are and whether you have a plan.
A false "yes" can also come back later. If your contract says you'll follow what you wrote in the questionnaire and something goes wrong, what you wrote is going to matter.
Write it once
The second questionnaire will ask the same questions in a different order. So:
- Keep every answer in one doc as you go.
- Write a one or two page security overview: how you host, how you encrypt, how you handle access, how you test. Attach it to every questionnaire.
- Some questionnaires will accept that overview for half their questions. Some won't. Either way you're copying and pasting instead of writing from scratch.
Turn the easy "no"s into "yes"es
Some gaps take months to close. Some take a day. Knock out the fast ones before you send the questionnaire back:
- Turn on MFA for your cloud accounts, GitHub, email, and anything else that touches production. One afternoon.
- Write an incident response plan. One page: who gets paged, who decides what happens, who tells customers, and how fast. It doesn't need to be fancy. It needs to exist.
- Write down your subprocessors. Your hosting provider, email provider, analytics, payments. You already know what they are.
- Test a backup restore. Actually do it once, and write down the date.
- Get a pen test. "Have you had an independent pen test in the last 12 months?" is on nearly every questionnaire, and it's one of the fastest ones to flip. Ours comes back in 24 hours.
What to send, and what not to
When they ask for pen test results, send the attestation letter first. It says who tested, when, the scope, and the method, and that's usually all they need. If they want the full report, offer it under NDA. A list of your findings, even fixed ones, isn't something you want sitting in a random vendor folder at another company.
If the report had findings, say what you fixed and when. "We had three medium findings, all fixed within two weeks" reads a lot better than a report with no follow-up.
It gets easier
The first questionnaire takes forever. The fifth takes an afternoon. And somewhere along the way you realize the questions weren't just paperwork. It's a pretty good list of things you should have in place anyway.