"It Has to Go Through Security Review" — Surviving the Questionnaire Without Losing the Quarter

The deal you already lost

You ran a clean cycle. Discovery was real, the demo landed, the technical evaluator said "this is what we need," and procurement asked for the order form. Then someone on the call said the sentence: it has to go through security review.

You wrote "security review" in the next-steps field. You put the deal in commit. And then nothing happened for six weeks, your champion stopped replying with the same speed, and the quarter closed without you.

That is the most common way I have watched good reps lose a deal they had already won. Not to a competitor. Not to price. To a workstream they treated as paperwork.

The security review is not the end of the sale. It is a second sale, to a second buyer, with a different scoring model, and almost nobody runs it deliberately. This post is how to run it.

Why reps treat this as admin

Because it looks like admin. A questionnaire arrives, it runs to hundreds of lines, it asks about key rotation and data residency and your incident response runbook, and none of it is language a seller owns. So the rep forwards it to solutions engineering or to whoever at the company gets stuck with these, and goes back to prospecting.

That forwarding motion is where the deal dies. The moment you hand it off, three things happen at once. You lose visibility into the timeline. You lose the ability to escalate, because you no longer know what stage it is at. And your champion, who was carrying momentum, gets a lull in which someone above them can ask "do we actually need this now?"

Security review is a queue. Queues punish the passive. Every other vendor in that queue is also waiting politely. The one that gets pulled forward is the one whose seller made it easy, cheap and low-risk for the reviewer to say yes, and gave the internal sponsor something to push with.

The reframe I use: from the moment the questionnaire appears, my job is no longer to sell the product. My job is to reduce the reviewer's workload. That is the whole game.

Get the questionnaire before the verbal yes

The single highest-leverage change you can make costs you one question in discovery and moves the entire review left by weeks.

Ask for the questionnaire before you have the technical win, not after.

In regulated buyers — health systems, banks, wealth platforms, anyone who runs a SOC or reports into one — the security review document is not a secret. It is a standard artifact. Your champion can send it to you the same day. But they will only send it if you ask, and reps do not ask, because asking feels like inviting friction into a deal that is going well.

Here is how I ask, usually on the second or third call, right after the buyer says something that indicates real intent:

"One thing I want to get ahead of. When you have bought tooling like this before, there is normally a security and vendor risk step. Can you send me the questionnaire you use, or the last one you filled out with a vendor? I would rather answer it now while nobody is waiting on it than have it show up in week nine."

Nobody has ever refused. What you get back is a map. You learn the framework they align to, whether they will demand a recent penetration test, whether they will insist on a specific certification you do not hold, and whether there is a question in there you are going to fail.

That last one matters most. If there is a hard blocker — no single sign-on, data stored in a region they will not accept, a subprocessor they have banned — you want to know in week two, not week ten. Knowing early gives you three options: fix it, get an exception approved by the reviewer in advance, or disqualify and go spend the quarter somewhere winnable. All three of those are better than finding out on a Thursday in the last week of the quarter.

This is also why security questions belong in discovery rather than in the closing stretch. When I am selling into a security org specifically, I work them into the diagnostic itself — the 25-minute discovery framework for diagnosing a SOC before you pitch it exists partly because the technical buyer and the reviewing buyer are often the same person, and treating them as one conversation saves a cycle.

Queue-based or triggered — find out which

There are two kinds of security review process and they behave nothing alike. Reps who do not know which one they are in cannot forecast, cannot escalate and cannot pull anything forward.

Queue-based review means there is a vendor risk team, a backlog, and a first-in-first-out list. Your submission joins the end. The team has a fixed capacity and it does not flex for your quarter. In this world, submission date is everything. A day of delay in getting the questionnaire back is a day of delay at the far end, and it compounds because the whole queue shifts.

Triggered review means a reviewer is assigned when the business sponsor raises the request, and the clock starts when they pick it up. There is no backlog to wait behind. The bottleneck is the reviewer's attention and the completeness of your submission. In this world, quality of submission matters more than speed of submission, and a single round trip for missing information can cost you more than a week of prep would have.

The question that separates them:

"When this goes to security, does it join a queue that the team works through in order, or does someone get assigned to it when you raise the ticket?"

Follow it with:

"And what has that looked like recently — what was the last vendor that went through, and how long did it take from submission to sign-off?"

That second question is the useful one. You are asking for a comparable. Champions can almost always name the last tool their team bought. If they tell you the last one took a month, you have a benchmark you can forecast against. If they say "honestly, I do not know, that was before my time," you have learned something else — your champion has never driven a vendor through this process and cannot be relied on to drive yours.

That is not a reason to panic. It is a reason to go find someone who has.

Find the actual reviewer and get twenty minutes with them

This is the step that separates deals that close in the quarter from deals that close whenever.

Somewhere in that organisation is a specific human being who will open your questionnaire, read your answers and decide whether to approve, reject or come back with questions. That person has a name. Most reps never learn it. They deal exclusively with the champion and the procurement contact, and they treat the reviewer as a black box that either emits an approval or does not.

Ask your champion directly:

"Who actually reviews this? Not the team — the person. I would like to offer them twenty minutes to walk through our architecture so they are not reverse-engineering it from a spreadsheet. It usually saves them a round trip."

Notice the framing. You are not asking for a meeting so you can sell. You are offering to save the reviewer work. That is a real offer, and it is usually true.

Some champions will refuse. Some organisations genuinely firewall the review team from vendors, and if that is the policy, respect it and do not push — pushing marks you as the vendor who does not respect controls, which is a bad thing to be in a security review. But in my experience most champions say yes, because they want the deal moving too and a call that unblocks the reviewer is in their interest.

What the twenty minutes should contain

Do not demo. The reviewer does not care what the product does for the business. Come with an architecture picture and answer four things without being asked: what data enters your system, where it physically sits, who at your company can see it, and what happens when something goes wrong.

Then shut up and take notes. The most valuable output of that call is not anything you say. It is the reviewer telling you, unprompted, which parts of the questionnaire they actually weight and which parts are boilerplate they skim. Every reviewer has a personal set of things they care about. One will be obsessed with subprocessors. Another will not care about subprocessors at all but will refuse to approve anything without SCIM provisioning. You cannot guess this. You can ask.

End the call with a commitment question:

"If I get you the completed questionnaire and the pen test summary by Friday, what does your side of the timeline look like from there?"

Write down the answer verbatim. You will use it later.

Pre-answer the four questions that always cause the round trip

The reason reviews take three cycles instead of one is that the first submission is incomplete, the reviewer sends it back, and the round trip costs a week each way because both sides are context-switching.

Four things cause most of those round trips. Answer them before you are asked, in writing, in the submission itself.

Where the data lives and who at your company can touch it. Not just region. Reviewers want the specific answer to "can a support engineer at your company read our records, and if so, under what circumstances, with what logging, and can we turn that off?" A vague answer here generates a follow-up every single time. A precise one — including the unflattering parts, if there are any — usually does not.

Your subprocessor list. Every vendor you use who touches customer data, named, with what they do. If you send a partial list and the reviewer finds a fifth-party in your own documentation that you did not disclose, you have created a trust problem that is much more expensive than the disclosure would have been. Send the full list unprompted.

Identity and provisioning. Single sign-on, SAML or OIDC, SCIM provisioning, whether it is available on the tier they are buying. This is where a lot of deals discover a nasty commercial surprise: the enterprise SSO the reviewer requires sits on a package above the one procurement negotiated. Find that out before pricing is locked, not after — trying to reopen a number after the technical win is a losing position, and if you find yourself there anyway, the approach in the financial services pricing negotiation script for holding your number after the technical win is the closest thing to a recovery I know.

Penetration testing and remediation. Two documents: your most recent test summary, and evidence that the findings were remediated. A test report with open critical findings and no remediation note is worse than no report. If they demand the right to run their own test against your environment, that is a legal and engineering conversation, not a sales one, and you need to start it the day it is mentioned rather than the day it becomes urgent.

Bundle all of this into one package with a short cover note that says what is in it. Reviewers deal with vendors who send things in dribs and drabs across nine emails. Being the one who sends a complete package with an index buys you goodwill you can spend later.

Telling a real timeline from a polite burial

This is the part reps get wrong most often, because both look identical in the CRM. "In security review" is a status that can mean a live process or a dead one.

A real timeline has three properties. It has a named owner. It has a next date, not a duration — "the committee meets on the twelfth" rather than "it usually takes about a month." And your champion can tell you what happens immediately after approval, because they have thought past it.

A burial has none of those. The signature phrases are "it is with security," "we are waiting to hear back," and "I will chase them." Passive voice, no owner, no date. If you ask who owns it and your champion does not know, and asks you not to contact anyone, and cannot name what happens after sign-off, you are not in a review. You are in a queue behind a decision that has already been made about you.

The test I use is a small, specific, low-cost ask. Something like:

"Can you forward me the ticket number so I can reference it when I send the pen test docs?"

A live process produces a ticket number in a day. A burial produces silence or a deflection. It costs you nothing to ask and it converts a vague status into a binary.

The other test is escalation tolerance. Ask your champion: "if this is still sitting in two weeks, who do we go to?" A champion in a live deal answers with a name and often volunteers to make the introduction. A champion in a dead deal says they would rather not push. That reluctance is the answer. It usually means the budget moved, a competing priority won, or someone senior has cooled and your champion has not wanted to tell you.

When you spot a burial, do not spend the quarter nursing it. Say it out loud, kindly and directly: "I get the sense this has slipped down the list. If that is right, I would rather know so I stop chasing you — and we can pick it up next quarter when it is real." I have had that sentence resurrect deals, because the champion feels the permission to be honest and then explains the actual blocker, which is often something you can solve. I have also had it end deals cleanly in October that would otherwise have haunted my forecast until January. Both outcomes beat waiting.

Run it as a workstream, not a status

Practically, from the moment security review is mentioned, I keep four things current: the name of the reviewer, the submission date, the next scheduled decision date, and the single open item blocking progress. If any of those four is blank, that is my work for the day.

And run it in parallel with everything else. Security review does not need the commercials to be finished, and commercials do not need security to be finished. Reps serialise these because it feels tidy. Serialising them doubles your cycle. Ask for the questionnaire while you are still building the business case — the same way a good clinical demo surfaces objections early rather than saving them for the end, which is the whole logic behind running a clinical demo for a CMIO who has already killed two vendors.

What I would do next

If I were building this skill from scratch, I would not read another article about it. I would practise the four conversations out loud until they stopped sounding like a script: asking for the questionnaire before the verbal yes, asking whether review is queued or triggered, asking for twenty minutes with the reviewer, and naming a burial without sounding accusatory. Those are all short, awkward, high-stakes asks, and the reason reps skip them is not that they do not know to make them — it is that they have never said the words before and the live call is a bad place to hear yourself say them for the first time. That is exactly what we built DrillCall for: reps run the conversation against an AI buyer who pushes back, until the awkward ask comes out flat and confident. Ten minutes a day on those four asks will save you more pipeline this year than any new prospecting sequence.

The technical win is not the win. The review is the win. Go run it.