Ownership should sit with whoever is accountable for the deal closing, not with whoever knows the most about security. At a ten-person company that usually means a founder or the person running revenue operations, with your most senior engineer acting as a named contributor on a bounded set of questions rather than as the owner. The instinct to hand the whole thing to the most technical person is the single most common reason questionnaires run late.
This article covers why the technical-owner instinct fails, the three ownership models and where each breaks, the accountability split that works at small scale, how the arrangement should change as you grow, and the specific trigger for hiring or outsourcing the function.
Why the technical owner fails
The reasoning is intuitive: it is a security questionnaire, so give it to the person who understands security. It fails for a structural reason rather than a personal one.
The work is roughly eighty percent coordination and twenty percent technical judgment. Coordination means chasing answers from three people, tracking what is outstanding, requesting documents from vendors who reply slowly, keeping the buyer updated, assembling the evidence pack, and getting the thing returned by a date. Technical judgment means deciding what a control actually does in your architecture and which answers carry risk if overstated.
Your senior engineer is uniquely valuable for the twenty percent and no better than anyone else at the eighty. Worse, they are the person most likely to be pulled into an incident mid-task, and questionnaires punish interruption badly — every return costs context reload on a document with two hundred rows.
The observable symptom is a questionnaire that sits at seventy percent for two weeks. Not blocked, not abandoned, just never the most urgent thing on an engineer's list. For questionnaire purposes, seventy percent complete on the due date is zero percent complete.
The three models, and where each breaks
Founder-owned. The founder runs the document, pulls answers from whoever has them, and writes the commercial framing themselves. This works well below roughly fifteen people and is often the fastest option, because the founder has both the full picture and the authority to interrupt people. It breaks on volume. When questionnaires become monthly rather than occasional, the founder is spending several days a month on document assembly, which is close to the worst possible use of that time.
Operations or customer-success owned. Someone in ops, CS, or sales ops owns the coordination and escalates technical questions. This is the right answer for most companies between roughly ten and fifty people. It breaks when the owner has no authority to get engineering time — if the flagged questions sit in a queue behind product work with nobody able to prioritise them, the model produces a well-coordinated document that is missing its hardest answers.
Engineering-owned. An engineer or engineering manager owns the whole thing. This is the most common arrangement and the one that fails most often, for the reasons above. It works in exactly one situation: when the engineer genuinely wants it, treats it as a defined responsibility with allocated time, and is not also on call for production.
There is a fourth non-model worth naming because it is so common: shared ownership, where the questionnaire belongs to a channel and everyone helps. This is not a model. It is the absence of one, and it reliably produces documents that are eighty percent finished at the deadline.
The split that works
Name two roles explicitly, in writing, in the first day.
The owner is accountable for the questionnaire being returned by an agreed date. They triage on arrival, sort the questions, run the document, gather supporting documents in parallel, chase, review for consistency before submission, and handle all buyer communication. They do not need deep security knowledge. They need to be organised and to have the standing to ask for people's time.
The technical contributor answers only the flagged questions requiring judgment — typically twenty to forty out of two hundred — in one or two bounded sessions. They are not accountable for the document, do not chase anyone, and do not attend buyer calls unless the buyer asks a technical question.
Two supporting roles usually matter. Someone with authority — a founder or department head — needs to be able to unblock engineering time when the contributor's session slips. And someone should review the completed document for internal consistency before it goes out, because contradictions between sections are what reviewers catch and escalate. The reviewer should not be the person who wrote the answers.
Write these names down. An arrangement everybody understands in principle and nobody has written down is shared ownership wearing a disguise. Our guide to answering a security questionnaire without a security team covers how to run the technical contributor's session so it takes ninety minutes rather than three weeks.
How this changes as you grow
Under ten people. Founder owns it. Nothing else is worth the coordination cost, and there is no volume to justify a process.
Ten to thirty. Move ownership to operations or customer success, keep engineering as a named contributor, and start the answer library. This is the transition most companies delay too long, usually until a founder misses a deadline on a large deal.
Thirty to eighty. Ownership consolidates into a defined role, often within a broader compliance or revenue operations remit. This is typically when a formal answer library, a document repository, and a published portal stop being nice ideas and start being load-bearing.
Beyond eighty. Dedicated security or compliance headcount, and the questionnaire function becomes part of a wider trust programme rather than a per-deal task.
The transitions are triggered by volume, not headcount. A twenty-person company selling into financial services can hit enterprise-level questionnaire load years before a sixty-person company selling to startups.
When to hire or outsource
The trigger is measurable rather than a feeling. Track two numbers for a quarter: how many questionnaires you received, and how many engineering hours went into them.
If engineering time is consistently over roughly one day per month on questionnaires, the answer is usually not to hire but to build the answer library, because most of that time is re-answering questions somebody already answered. Fix that first; it is cheap and it typically removes most of the load.
If the volume is still high after the library exists, the question becomes whether the remaining work is coordination or judgment. Coordination scales with a hire or a contractor and does not require security expertise. Judgment does not outsource well, because the bottleneck is knowledge of your own systems, which an external party does not have — which is why a consultant hired to answer your first questionnaire mostly interviews your engineers and charges you for it.
The other honest trigger is deal size. If a single enterprise deal is worth more than a quarter of a person's salary and the security review is the gating item, the arithmetic answers itself.
Common mistakes in questionnaire ownership
Handing the whole document to an engineer. Eighty percent of the work is coordination, which is not their skill and not their best use.
Leaving ownership implicit. If nobody's name is written against it, it belongs to everyone, which means it stalls at seventy percent.
Making the owner someone with no authority to get engineering time. The flagged questions will sit behind product work indefinitely.
Having the same person write and review. Contradictions between sections are what reviewers catch. The reviewer needs fresh eyes.
Hiring before building the library. Most questionnaire load at small companies is repeated work. Fix the repetition before adding a person to absorb it.
FAQ
Who should fill out security questionnaires at a startup?
Coordination should sit with whoever is accountable for the deal — usually a founder below fifteen people, and someone in operations or customer success above that. Your most senior engineer should answer only the flagged questions requiring technical judgment, in bounded sessions.
Should engineers answer security questionnaires?
They should answer the subset that requires judgment about how your systems actually work, which is typically ten to twenty percent of the questions. They should not own the document, chase contributors, or manage the deadline.
Do I need a dedicated compliance person for security questionnaires?
Rarely below fifty people. Build a reusable answer library first, since most questionnaire load at small companies is re-answering the same questions. Hire when volume remains high after the library exists and the residual work is coordination rather than judgment.
How do I stop security questionnaires from blocking engineering?
Name a non-engineering owner, sort the questions before anyone starts answering, and give engineering a bounded list in a scheduled session rather than the whole document. Then capture the answers so the next questionnaire draws on them.
Closing thought
The reason ownership matters more here than in most internal processes is that a questionnaire has an external deadline, an audience that reads carefully, and a deal attached. Almost every other partially-finished internal document can wait a week. This one cannot, and the failure is invisible until it is not — the document looks nearly done right up until the day it is late.
Ownership gets considerably lighter when the recurring answers live somewhere permanent rather than in whoever last did one. ComplyDog puts your DPA, subprocessor list, data subject request process, and security overview on a hosted portal at your own domain, so the owner is assembling rather than researching, and so the arrangement survives that person leaving. The judgment questions still need your engineer. Everything else should not depend on a single memory.
