Enterprise deals aren’t won by questionnaire answers.
They’re won on the calls before and after. And that’s where most deals quietly die: not because your sales team says something wrong, but because they say nothing with any conviction and nobody who knows anything about security is on the call from your side. Your salespeople hedge. They defer. They use phrases like “I believe we do that” and “I need to check.” The technical evaluators on the other side hear uncertainty, and uncertainty is indistinguishable from incompetence.
By the end of the call, the recommendation going back internally isn’t “they failed the review.” It’s more “I wasn’t confident they know their own environment.”
Who Should be Doing This?
Your security person is spending one or two days a week on sales questionnaires that a sales team member could answer. Perhaps sitting on calls where they wait for cumulative hours to repeat the same explanations they gave last month to a different buyer. Reviewing responses that haven’t changed since the last deal.
Meanwhile, the architecture review that actually matters is waiting. The incident response plan is half-finished. The vendor risk assessment is three weeks overdue. Your scarcest, most expensive resource is doing work that someone else could own, if anyone had bothered to teach them.
The hidden cost
Every hour your security leader spends on questionnaire calls is an hour they’re not spending on the work that actually reduces your risk. At £1-2k per day for senior security or CTO time, questionnaire support is extraordinarily expensive, and most of it doesn’t require that level of expertise.This is the real security questionnaire problem. It’s not a tooling problem. It’s a resource allocation problem disguised as a janky sales process.
The Tooling Trap
Everyone reaches for a questionnaire management platform or GenAI answer bank. That feels reasonable, right?
These compress response time from weeks to days. But they create a false sense of readiness. Your SaaS tool knows about 80% of your answers, but your sales team doesn’t. The questionnaire is rarely where deals are won or lost: it’s the conversation around it.
But they don’t solve the actual bottleneck. Your security person still has to review every response before it goes out. They still have to join every follow-up call. They’re still the only person in the building who can answer “why did you make that architectural choice?” without waffling.
The tool made the paperwork faster, but it didn’t remove the dependency.
If you have a fractional CISO two days a month, those days cannot be spent reviewing questionnaire responses. If you have a full-time security lead, they shouldn’t be spending a quarter of their week on sales support. Either way, you need your GTM team to carry more of this weight.
What actually happens in enterprise security reviews
The written questionnaire is maybe 30% of the trust-building exercise. Here’s the real sequence:
First, the written questionnaire arrives — 100 to 300 questions, depending on the buyer. Your tool handles this. Fine. The buyer’s team scores your answers.
Then comes the follow-up call. The buyer’s security team wants to probe the gaps and the edge cases. They go off-script. They ask “why” questions.
Your security person should be on this call. But they’re in an architecture review, or handling an incident, or it’s not one of their two days this month. So your GTM team takes it alone. And they waffle. The evaluators hear waffling, and they draw their own conclusions.
Then there are ad-hoc questions during contract negotiation. The buyer’s legal team wants to know about data residency. The buyer’s CISO’s office wants to understand your incident response timeline. Your champion in the buyer’s team is being asked questions they can’t answer and needs your team to step up.
Throughout all of this, the technical evaluators are reading your team. Not just your documents: your people too. They’re assessing whether the humans representing your company actually understand the security controls they claim to have, or whether they’re reading from a script someone else wrote.
The difference is obvious. “We use AES-256 encryption at rest” read from a sheet sounds completely different from the same fact explained with context — why that choice was made for your architecture, and a promise of a link to a useful policy document on your trust portal. The first sounds like a student reciting an answer, and the second sounds like someone who works there.
Another approach
Here’s a specific practice that solves both problems - the resource drain and the confidence gap. Every new GTM, GRC and security hire completes two security questionnaires as part of their onboarding.
One completed, historical questionnaire. Pick an older one, ideally one that was thorny. The new hire works through it from scratch using your tools and a list of “volunteer” contacts across engineering, infrastructure, and compliance.
The goal is not speed. The goal is that they have to find the right person, ask the right question, and understand the answer well enough to write it down coherently. They learn three things simultaneously: your organisation’s security architecture, the internal people who own each domain, and the language your company uses to describe its controls.
One live, incoming questionnaire: supervised but real. They own the response end to end. They use the tools, but they also have to make judgment calls: what can I answer from the existing answer bank? What needs a conversation with engineering? What needs escalation because the answer has changed? There is an art to giving an honest answer too, but one which leads to a higher evaluation score. This is the chance to teach it!
An answer bank is a maintained library of pre-approved responses to common security questions. Good ones include context about when the answer was last verified and who owns it. Most companies have one; few keep it current.
Modern answer banks that use GenAI are magical, but can be very wrong, your people need to know when that happens and ensure that the answers are correct.
The side effect nobody expects
Your GTM team builds real relationships with technical staff. When a buyer asks something unexpected on a call six months later, your account executive knows exactly who to message — and probably already knows the answer. Technical buyers detect the difference immediately, and greatly appreciate it.Making it work
The volunteer contact list. Identify 8-12 people across the business who own security- and tech-relevant knowledge: your lead infrastructure engineer, someone from the platform team, your compliance person, whoever manages vendor relationships, the person who handles access control. Brief them: tell them a new hire will reach out as part of onboarding, and you’d appreciate 10 minutes of their time every few weeks. Most people are happy to help.
Time investment. Roughly a day per questionnaire. Two days of onboarding time total. That sounds expensive until you compare it to the alternative: your security lead spending a quarter of every week doing work that a well-prepared account executive/salesperson could handle.
What “done” looks like. The new hire can explain your top 10 security controls conversationally, without notes. They know who owns what internally. They can describe your security architecture well enough for a buyer call — not deep technical detail, but enough to be credible. And critically, they know when to say “let me get you the right person for that specific question” instead of waffling through an answer they don’t actually have.
Where your security person still matters. They review the answer bank quarterly. They join calls where the buyer has flagged genuinely complex architectural questions. They handle the 10-20% of questionnaires that involve novel scenarios or non-standard requirements. That’s a few hours a month, and not a few days a week.
Tools in their proper place
None of this is anti-tool. Questionnaire management platforms and AI-assisted answer banks are genuinely useful. They handle the repetitive work, ensure consistency, and save time.
But tools should augment people who understand the material, not replace understanding. The best setup is a well-maintained answer bank that your GTM staff actually contributed to and can contextualise — not one they’ve never read and treat as a black box that produces correct-sounding text.
The test
Ask your most experienced account executive/salesperson to explain your data sovereignty approach without looking anything up. If they can’t do it in 60 seconds, your tooling is masking a knowledge gap that your buyers have already noticed.What you get back
Two days of onboarding investment per GTM hire. In return:
Your security person gets their time back. The work that actually reduces risk - architecture reviews, incident planning, vendor assessments - stops being perpetually deferred. Your security posture improves because your security people are doing security work.
Your pipeline moves faster. Questionnaire responses go out without waiting for your security person to review every line. Follow-up calls happen on your account executive’s schedule, not your security lead’s. Deals stop stalling because the security call couldn’t be booked for three weeks.
Your buyers trust you more. When your sales team can talk about security with earned confidence rather than rehearsed confidence, the technical evaluators notice. The internal recommendation shifts from “I wasn’t sure they knew their stuff” to “they clearly know what they’re doing.” And that’s the difference between a deal that closes and one that is smothered in a buyer’s deal committee.
This was never a tool problem. Teach your people, and the tools work better too.