Most of a security questionnaire is not a security task. It is a documentation task about security, and the two need very different people. The way a small company answers one without a security team is to separate the questions that require technical judgment from the much larger number that require someone to write down what is already true — and then to protect your engineers' time for the first group only.
This article covers the split that makes this tractable, the four-bucket sort that sizes the work, how to run the engineering session so it takes hours rather than weeks, how to answer honestly when the answer is no, and what to do about the questions that assume a security function you do not have.
The split that makes this possible
Take a two-hundred-question assessment at a company of twelve people. Sorting the questions by who can actually answer them typically produces something like this.
Roughly half are documentation: what your retention period is, who your subprocessors are, whether you have a written policy, what your notification window is. These require finding out and writing it down. No security expertise required.
Roughly a third are simple technical facts that any engineer on your team knows without research: whether MFA is enforced, whether data is encrypted at rest, which cloud provider you use, whether production access is logged.
The remainder — often twenty to forty questions — require real judgment. These are the ones where the honest answer is nuanced, where a careless yes creates a commitment you cannot keep, or where you need to decide what a term means in your architecture.
Only that last group needs your most senior engineer. If they are handling all two hundred, you are spending your scarcest resource on transcription, and it will take three weeks because they will do it between other work.
The four-bucket sort
Before anyone answers anything, one person reads the whole questionnaire and sorts every question into four buckets. This takes an hour or two and saves days.
Bucket 1 — Already documented. The answer exists in a policy, a previous questionnaire, or a vendor's own documentation. Pure transcription.
Bucket 2 — Known but unwritten. Someone on the team knows it; it has never been written down. A short conversation, then transcription.
Bucket 3 — Needs judgment. The nuanced ones. Flag for the engineering session.
Bucket 4 — Not applicable. Questions about datacentres you do not operate, hardware you do not own, or business lines you are not in. Every questionnaire has these, and marking them clearly with a one-line reason is a real answer, not a dodge.
The sort also tells the buyer something useful. If bucket 3 is small, you can commit to a date with confidence. If bucket 4 is large, that is worth raising early — it usually means the questionnaire was scoped for a different kind of vendor, and buyers will often narrow it rather than have you write "N/A" two hundred times.
Running the engineering session
Bucket 3 gets one meeting, not an assignment.
Book ninety minutes. Bring the flagged questions, already extracted into a single list, with the buyer's exact wording. Have a non-engineer in the room whose job is to type the answers as they are spoken. Work down the list.
This structure matters more than it sounds. An engineer given a spreadsheet will open it, answer four questions, get pulled into an incident, and return to it three days later having lost context. An engineer in a room with a list and someone typing will clear thirty questions in ninety minutes, because the task is talking rather than writing, and talking is the part they are fast at.
Two rules for the session. Anything that cannot be answered in two minutes gets parked with a named owner and a date, rather than being debated. And nobody writes final prose in the room — capture the substance, polish afterwards, because wordsmithing is what turns a ninety-minute session into a four-hour one.
Answering honestly when the answer is no
Without a security team you will have gaps: no penetration test, no SOC 2, no formal security training programme, no on-call security rota. Reviewers know what a twelve-person company looks like. They are not expecting a CISO. What they are assessing is whether you know your own posture.
The structure that works is: state the gap, describe what compensates, give a timeline only if it is real, offer evidence.
"We do not have a formal security awareness training programme. All staff complete onboarding covering credential handling, phishing, and data classification, and access to production requires MFA and is reviewed quarterly. We are evaluating a formal programme for the second half of the year."
That answer is a no. It will not fail an assessment at most buyers, because it demonstrates that you know what the control is for and have thought about the risk. The version that does fail is "No" alone, and the version that fails worse is a yes you cannot evidence.
Resist the pull toward the generous interpretation. Every long questionnaire contains a question where you could plausibly answer yes if you squint. A reviewer who asks a follow-up and finds the yes was aspirational will re-read every other answer with suspicion, and that is a far more expensive outcome than the gap would have been. Our guide to running a GDPR compliance audit covers the same principle applied to the privacy half of the same review.
The questions that assume a function you do not have
Some questions presume an org chart you do not have: "Who is your Chief Information Security Officer?" "Describe your security operations centre." "How many staff are in your information security function?"
Do not leave these blank and do not invent a title. Name the person who actually holds the responsibility and describe the arrangement plainly. "Security is owned by our CTO, [name], alongside engineering leadership. We do not maintain a separate information security function at our current size."
This reads as accurate rather than deficient. What reads as deficient is a blank field, because a blank field is indistinguishable from an oversight and generates a follow-up. What reads worse is a fictional CISO title assigned to whoever seemed closest, which becomes awkward the moment the reviewer asks that person a question.
The same applies to policies. If your access control policy is four paragraphs in a shared document rather than a formal signed document, say that. A short real policy is defensible. A claimed policy that does not exist is not.
Common mistakes when answering without a security team
Assigning the whole questionnaire to an engineer. They will context-switch on it for weeks. Sort first, then use their time only on the questions that need judgment.
Skipping the sort. An hour of triage turns an unbounded task into four defined ones and lets you commit to a real date.
Letting the engineering session become a writing session. Capture substance verbally with someone else typing; polish afterwards.
Leaving org-chart questions blank. A blank field looks like an oversight and generates follow-ups. Name who actually owns it and describe the arrangement.
Answering yes where the honest answer is "not yet." One unevidenced yes causes a reviewer to re-read everything else sceptically. The gap was cheaper.
FAQ
Can a company without a security team pass a security questionnaire?
Yes, routinely. Questionnaires are not pass-or-fail exams; they are inputs to a buyer's risk decision. Small vendors are assessed on whether they understand and document their posture, not on whether they have a dedicated security function.
How long should answering a security questionnaire take?
With existing documentation and a sorted question list, a mid-sized assessment is typically a few days of part-time work with one focused engineering session. A first assessment with no prior answers is realistically two to three weeks, most of which is discovering and writing down what you already do.
What if I don't have SOC 2 or ISO 27001?
Say so directly and describe what you do have — encryption, access control, logging, dependency scanning, vendor due diligence. The absence of an attestation is a known and common situation. Attempting to imply one you do not hold is not.
Should I hire a consultant to answer security questionnaires?
Rarely worth it for a first questionnaire, because the bottleneck is knowledge of your own systems, which a consultant does not have. It becomes worthwhile when questionnaire volume is consistently consuming engineering time and you want an answer bank built and maintained.
Closing thought
The reason these feel disproportionate at a small company is a mismatch of units. The questionnaire was designed to assess a vendor with a security department, and it asks its questions in that vocabulary. You are answering in a different one. The work is largely translation — taking what your team genuinely does and expressing it in the terms the document expects — and translation is a documentation skill, not a security skill.
Once translated, most of it stops being per-deal work. The recurring questions about subprocessors, data retention, residency, deletion, and data subject requests have stable answers that belong at a URL rather than in a spreadsheet. ComplyDog hosts those on your own domain and keeps them current, so the next questionnaire starts with a section already answered. The judgment questions still need your engineer. There should just be far fewer of them by then.
