The person blocking you is not evaluating your product
A security or vendor-risk reviewer has a different job from everybody else in the deal, and misreading that is why these blocks turn into stalemates. They are not weighing benefit against cost. They are attesting, in a process that will be examined later, that a third party meets a standard their organisation has committed to. If they wave you through and something goes wrong, the record shows they approved it. That asymmetry explains behaviour that looks obstructive from the sales side and is entirely rational from theirs.
Which means the objective is not to persuade them that the risk is acceptable. It is to give them something they can put on the file. Everything useful in this scenario follows from that reframing, including the parts that feel counter-intuitive, like volunteering a limitation they had not spotted.
Find out what actually failed
You cannot respond until you know which answer caused it, and the message that reaches you rarely says. It arrives via the sponsor, filtered through a summary — "security are not comfortable", "we failed their assessment" — and acting on the summary means arguing with a paraphrase.
So the first move is a specific request: which requirement, which of our answers, and what would need to be different. Ask for it through the sponsor if that is the only channel, but ask for the reviewer's own words rather than an interpretation. And ask for a call with the reviewer, framed as wanting to understand their standard rather than to challenge the outcome, because that framing is usually the difference between being granted the call and being handled by email for three weeks.
While waiting, go and read what you actually submitted. Frequently enough to be worth checking every time, the block traces to an answer that was completed by somebody who was not close to the system, or was true of a previous architecture, or answered a narrower question than the one asked.
Three blockers that need three different responses
| What the block actually is | How you can tell | The move |
|---|
| A real control gap | The requirement is clear, you do not meet it, and you know why | Compensating controls with evidence, plus a dated commitment if it is on the roadmap |
| A wording or scope problem | You do the thing, described differently, or their question assumed an architecture you do not have | Correct the answer with detail, and explain the mapping in their terms |
| An immovable policy | Applied to every vendor, written into their standards, no exception path | Ask what the exception process is, then decide whether the deal survives without it |
The middle row is the most common and the most infuriating, because it means the deal stalled over a translation failure. Their questionnaire asks whether you support a particular mechanism; you achieve the same control by another route; whoever answered wrote no, or wrote yes with a caveat that read as a hedge. The fix is a precise, technical restatement — what the control objective is, how you meet it, what evidence exists — sent to somebody qualified to assess it.
The top row is where credibility is made. If you genuinely do not meet the requirement, say so first and without decoration, then offer what you do have: the mitigation, the boundary that limits the exposure, the monitoring that would detect abuse, and whatever independent evidence you can point at. A reviewer who has been told a plain no and given a coherent mitigation will sometimes write an accepted-risk entry and let you through. A reviewer who suspects they were managed will not, and they will look harder at everything else you submitted.
Never edit an answer to make it pass
At some point in one of these situations, someone will suggest that an answer be softened, or that a control described as planned be described as in place. It may come from an account executive under quarter pressure, and it will be presented as a matter of emphasis rather than accuracy. This is the moment the question is really testing.
Refuse it, and know why the answer is easy rather than brave. The questionnaire response is a written representation that typically ends up referenced in or attached to the contract, so an inaccurate answer is a misrepresentation that survives the deal and outlives everyone in the room. It will also be tested — by an audit, by the customer's own review cycle, or by an incident, which is the worst possible moment. And the reviewer's professional instinct is to verify, so the chance of being caught is not small.
What you can legitimately do is different and usually sufficient: correct an answer that was wrong, add detail where the answer was thin, split a compound question that was answered as a single one, and state a roadmap item as a roadmap item with whatever commitment you are authorised to make. That last constraint matters — a date you did not set is not yours to give, and here it would be going into a document with contractual weight.
Work with the reviewer, not around them
The sponsor will sometimes offer to escalate, get an exception, or go over the reviewer's head. Be careful with that offer. Sometimes it is legitimate, because many organisations have a formal risk-acceptance route where an accountable business owner can accept a documented risk, and using a defined process is entirely proper. Ask what the process is and let it run.
An informal override is a different thing, and it costs more than it looks. The reviewer remains in post, retains a veto at renewal, and will be involved in every subsequent expansion of your footprint in that account. Winning by going around them buys a signature and creates an adversary in the exact function that will assess you again next year. It also tends to produce conditions attached to the approval that nobody in your delivery team knows about.
The better posture is to make the reviewer's job easy, repeatedly. Send the material unprompted, in the form they use. Answer within a day. Bring somebody technical who can answer without hedging. If they cite a standard you do not know, read it before the next call. Reviewers deal mostly with vendors who are evasive, and being the exception has a disproportionate effect on how the remaining questions go.
Feed it back, or you will do this again next quarter
The last part of a senior answer is what happens after the deal closes. A block of this kind is intelligence: it tells you a requirement that a class of buyer will apply, and if you are selling into a sector, the next three prospects will apply it too. That belongs somewhere product can see it, with the deal attached, so the pattern is visible rather than each occurrence being handled as a one-off by whoever is on the deal.
The same applies to the questionnaire responses themselves. If an answer was wrong, the correction has to go back into the source your team answers from, otherwise the identical block recurs and you spend three weeks on it again. And anything you offered as a compensating control, or committed to as a change, needs to reach the proposal and the delivery team in the words you used, because a mitigation promised to a security reviewer is a commitment somebody will be audited against.
A security reviewer needs something they can defend on the file, not persuasion. Establish which answer failed, sort a real gap from a translation failure, and treat any suggestion to reword an answer so it passes as the one thing you will not do.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).