TL;DR
- A delayed questionnaire rarely kills a deal outright. It mostly just pushes the contract, and the risk, later.
- The real cost is competitors answering first and champions losing momentum, not the "lost revenue" math.
- 80–90% of a typical questionnaire is retrieval, not new writing, based on Amomitto's experience with our own client work.
- A good answer bank needs named owners, review triggers, and source tags, or it goes stale fast.
- AI can draft answers quickly, but someone still has to read most answers before it goes out.
- Losing a single enterprise deal due to a poorly answered questionnaire is enough risk to justify building a process for them.
A deal that was moving is suddenly quiet. The customer sent over a security questionnaire two weeks ago, and nobody's answered it yet.
Not because anyone's ignoring it. Sales doesn't have the answer around encryption or vulnerability management so they kick it to engineering. Engineering is slammed and does not know what is being sold to the customer so they push it to sales. And it ends up being founder work. Or poorly answered. Or the deal dies as a competitor swoops in and provides the answers first.
How much does a security questionnaire delay actually cost?
Sprinto has run a version of this calculation: take a $50,000 deal, delay it three weeks, and multiply the deal value by the delay (roughly 5.8% of a year) to get about $2,885 in "lost revenue." It's a clean number that isn't quite what it claims to be.
A three-week delay is real. What it costs isn't automatically $2,885. If a customer was going to sign a 12-month, $50,000 contract on June 1 and instead signs June 22, the company hasn't necessarily lost $2,885. It may have simply moved the entire contract three weeks later.
Calling that "deferred revenue" borrows an accounting term that doesn't apply here either. Deferred revenue describes money already billed before it's been earned, and this is a prospect who hasn't signed anything yet.
The delay is genuinely expensive. The honest reasons are just less tidy than a single formula:
- The financing and opportunity cost of collecting that revenue later instead of sooner
- Revenue shifting to the next quarter
- A renewal date that now falls three weeks later than it should have, compounding every year the contract renews
- Sales capacity tied up longer on one deal instead of moving to the next one
- A rising chance the deal doesn't close at all the longer it sits, as the buyer loses momentum, gets reassigned, or a competitor answers faster
That last one is the real cost driver, not the deferred-cash-flow math. A three-week delay that still closes is an inconvenience. A three-week delay that gives a competitor time to answer first, or gives a champion time to leave the company, is a lost deal.
The better way to track this is watching whether questionnaire turnaround time correlates with win rate and sales-cycle length in your own pipeline, not ACV multiplied by weeks divided by 52.
If slower responses show up as lower win rates, that's the number worth taking to whoever controls the budget for fixing this, not a spreadsheet formula borrowed from a vendor's blog post.
The time cost nobody's tracking
Separate from the revenue question, there's a straightforward labor cost. Vendor estimates on how long a single questionnaire takes to complete manually commonly land somewhere between 10 and 40 hours, depending on length and how organized the existing answers already are.
A company fielding a handful of these a year absorbs that as an occasional distraction. A company fielding dozens, which is normal for anyone actively selling into mid-market or enterprise accounts, is looking at a real, recurring labor line that usually isn't budgeted anywhere.
And it's rarely the sales team doing the work. It's an engineer, a founder, or whoever's closest to "knows how our systems work," pulled off whatever they were actually supposed to be doing that week.
That's a resourcing problem with several possible fixes: a dedicated internal owner, better tooling, an answer bank, or in some cases outside security leadership. Which one makes sense depends on volume and how much of the underlying security program still needs building in the first place.
How much of a questionnaire is actually new work?
Less than it feels like when you're staring at 200 rows in a spreadsheet. Across the more than a dozen clients Amomitto works with, 80 to 90 percent of a typical questionnaire gets answered directly from an existing library of prior answers, policies, and evidence.
That lines up with the broader range vendors and industry sources tend to cite, generally somewhere between 60 and 90 percent, though that figure varies a lot by source and questionnaire type and shouldn't be treated as a precise number.
One assumption worth correcting: having a current SOC 2 report doesn't mean the questionnaire goes away, even for a company that is SOC 2 compliant. Larger buyers, the ones with a dedicated third-party risk team and a fixed intake process, generally still require the full questionnaire regardless of what documentation you hand them first.
The SOC 2 report makes answering faster, but it's rarely a substitute for the process itself once an enterprise buyer's procurement team is involved. A common response looks something like: thanks for the report, now please fill out our questionnaire too, because that's our process and we don't deviate from it.
The volume itself is real and recurring, too: a typical questionnaire runs around 80 questions, though the range is wide. Sometimes as few as 20 to 30, sometimes 200 to 300, and around 1200 if someone is trying to have you fill out a full SIG.
Either way, the honest takeaway is the pattern underneath the percentage: most of a questionnaire is a retrieval problem, not a writing problem. Speed here has less to do with having the best security program than with finding a past answer in under a minute instead of re-deriving it from scratch.
Building an answer bank that actually holds up
The idea itself isn't complicated: a single, current, owned source of pre-approved answers, organized so anyone can find the right one fast. In practice, that starts with writing the underlying policies once and keeping them matched to what's actually running in the environment, so answering a question later is a lookup instead of an investigation.
Where it usually breaks down is maintenance. A few things separate an answer bank that's still useful a year later from one that goes stale and causes more problems than it solves:
- A true owner responsible for a domain. Without a named owner, nobody notices when a control changes and the stored answer doesn't.
- A review schedule, plus event-based triggers on top of it. Scheduled reviews catch mundane drift. Event triggers, like a control change or a new compliance framework being met, catch meaningful changes immediately. Relying on only one leaves a gap either way.
- Answers tagged to their source. Every stored answer should point back to the policy, control, or report line that backs it up, so a reviewer isn't taking it on faith and a buyer's follow-up question has somewhere concrete to go.
- A visible flag for "novel" questions. The system should make it obvious when a question doesn't match anything in the library, so it gets routed to a human instead of getting a best-guess answer stretched to fit.
Done well, this turns most incoming questionnaires into an afternoon of matching and light editing, with the remaining genuinely new questions getting the actual attention they need.
A word of caution on AI-assisted answering
AI-assisted answering has become the obvious shortcut, and a lot of teams already lean on it. In Amomitto's own testing against real questionnaires, general-purpose AI tools land a reasonable answer around 70-80 percent of the time.
The remaining 20 to 30 percent is where it gets ugly. Obviously not all AI is created equal, and it takes a bit of work to get it to pull the correct context, documentation, flag for novel questions, and overall follow a workflow that will end up saving time. Otherwise it can turn into a time sink at best, and missed expectations with a customer that leads to a lost deal at worst.
As you can imagine, a buyer's security reviewer who catches one answer that is clearly hallucinated stops trusting every other answer on the page, which defeats the entire point of answering fast. AI-assisted drafting is a reasonable first pass. It isn't a substitute for someone actually ensuring the answers are correct when there are hundreds of thousands of dollars at stake.
You've got 200 questions and 5 days. Now what?
This is the exact situation an answer bank is built for, but if you don't have one yet, a sound strategy is going to be the best way to get through it:
- Sort before you write anything. Pull every question into three buckets:
- Answerable today, from your SOC 2 report, existing policies, or what you know just by the nature of being a founder
- Genuinely new, needing real input from the team
- Not applicable to your product or architecture
- Flag anything needing legal or engineering sign-off immediately, not on day four. That's the bucket most likely to actually blow the deadline, so it needs the longest runway.
- Turn on some music and grind through the questions you have solid answers on. It should be fast, it is like doing homework or eating your vegetables, but depending on the platform or follow ups you now have a strong story about its completion status.
- Write honest "not applicable" answers. A skipped question reads as evasive. One sentence explaining why it doesn't apply reads as competent.
- Don't guess on anything with real liability attached. A wrong answer on data handling or breach notification is worse than a slightly late one. If you don't know, say you're confirming and follow up, rather than answering confidently and incorrectly.
- Weigh the deal size before you sink real hours into it. A 300-question questionnaire for a $10,000-a-year deal usually isn't worth the sales, engineering, and compliance time it costs. Offer your SOC 2 or ISO report instead and let the buyer decide if that covers it. A questionnaire tied to a Fortune 100 contract worth two million dollars over three years is a different problem entirely. That's real annual revenue, and the same hours become an easy trade.
None of that requires new tooling. It requires not treating all 200 questions as equally hard, when in practice they aren't.
If this is a recurring fire drill rather than a one-off, that's usually a sign the company has outgrown improvising on compliance program management generally, whether the fix is a dedicated internal owner, better tooling, or bringing in outside help.
Who should actually own security questionnaires?
A security questionnaire is an odd document. A buyer's security team writes it, but it blocks a sales deal. Answering it well requires being accurate enough to survive a security review and clear enough to keep a deal moving.
Handed entirely to compliance, it tends to move slowly and read defensively. Handed entirely to sales, it risks answers that oversell the actual posture.
It works best when it's owned by whoever actually understands both the technical reality and the deal at stake. That's exactly where compliance and sales enablement overlap, rather than sitting in either lane alone.
FAQ: security questionnaires and deal delays
Does a security questionnaire delay lose the deal, or just delay it?
Usually just delay it, and that alone has a real cost: a later renewal date, sales capacity tied up longer, revenue landing in the following quarter. The bigger risk is what a long delay enables, a competitor answering faster, a champion losing momentum or leaving the company, procurement deprioritizing the deal. Track questionnaire turnaround against your own win rate and sales-cycle length rather than assuming a fixed dollar figure for every week of delay.
Is it risky to reuse the same answer across different questionnaires?
Having certainty about the answer is more important than having a fresh answer for every questionnaire, but that can be difficult as controls change, the product evolves, or a large enough client arrives that you are willing to build something unique for. It requires maintenance of a questionnaire answer bank, and a well informed team to keep it up to date.
What's the difference between a security questionnaire and a SOC 2 report?
A SOC 2 report is an independent auditor's opinion on a defined set of controls over a specific period, prepared once and reused across many buyers. A security questionnaire is a buyer-specific, custom set of questions that sometimes covers ground the SOC 2 report doesn't, and sometimes rehashes a lot of the same into an excel spreadsheet or bespoke questionnaire portal. A current SOC 2 report can answer a meaningful share of a questionnaire by reference, but it unfortunately doesn't replace the questionnaire process entirely.
Should sales or security own questionnaire responses?
Neither exclusively. The strongest setup is a workflow between sales and security that ensures a questionnaire bank is maintained so sales can easily grab answers that come up in conversations or are sent via email, while knowing that the security and compliance team is there to support them when the large VSQs inevitably arrive. A close integration between sales and security is key to a successful questionnaire process that moves quickly on the deals that matter.
What should a founder do with a 200-question questionnaire and a 5-day deadline?
Triage before you write. Sort the questions into what you can already answer from existing policy or your SOC 2 report, what genuinely needs a new answer, what needs review from others in the org, and what needs a straight 'not applicable' with a one-line reason. AI is likely going to be a reasonable tool if you ingest policies, procedures, and documentation but be careful! Although AI has improved a lot, it's still not a substitute for human review when enterprise deals are on the line!
The next questionnaire shouldn't be the reason a deal slips.
We'll help you build an answer bank that actually stays current, and figure out where compliance and sales enablement should meet at your company specifically.
See how Amomitto handles this →