Q: Who really kills security deals?

Most often a technical evaluator who never joined a vendor call. A senior engineer is asked for a private read, spends under an hour with the documentation, and posts a short verdict in an internal channel. The buying committee acts on it, and the vendor is told only that the answer is no.

Q: What do security engineers look for when they evaluate a product?

Credibility signals readable in under an hour: documentation that describes error states and limits rather than only the happy path, an API shape that implies a workable architecture, a changelog showing active maintenance, and a security page whose claims survive five minutes of checking against public evidence.

Q: How should a buying committee use its technical evaluator?

Ask early and in writing. Give the engineer the documentation and one question: what would make you not want to operate this? Record the answer in the evaluation file where procurement and the security leader can both see it, so the objection gets resolved in week two rather than discovered in month three.

Deepak Gupta

The pattern repeated often enough that I stopped treating it as bad luck.

An enterprise evaluation would run for weeks. The CISO was engaged. Procurement had a number. The security architect had joined two calls and asked good questions. Then the thread went quiet, and four weeks later the answer came back as a polite no with no reason attached.

Every time we could reconstruct what happened, it was the same thing. Somebody who had never been on a call, usually a senior engineer, had been asked for a private read. They spent forty minutes with the documentation, formed a view, and posted three sentences in an internal channel. Those three sentences ended the evaluation.

What made it visible

I only learned this because a few buyers told me afterward, off the record, usually months later and usually because they had moved to a different company and no longer cared about the awkwardness.

The three sentences were rarely about a feature. They were about credibility signals an engineer can read in under an hour:

The documentation described the happy path and nothing else. No error semantics, no rate limits, no migration story.
The API shape implied an architecture the engineer did not believe would hold under their load.
A security page made a claim the engineer could disprove from public evidence in five minutes.
The changelog was quiet for eight months, or it was noisy in a way that suggested churn.

None of these came up on a call, because the person who noticed them was never invited to one. And none of them were reported back to the vendor, because there was no mechanism to report them and no upside in doing so.

Why it generalizes

The structure of a security buying committee makes this inevitable rather than accidental. Gartner puts the modern buying group at five to sixteen people across up to four functions. The people with authority to approve are a small subset of that. The people with authority to stop it are almost all of them.

Approval requires a positive case that survives four functions. Rejection requires one credible objection from anyone. That asymmetry means the marginal opinion in a security evaluation is almost always a negative one, and negative opinions are cheap to form and expensive to surface.

Add the rep-free preference on top. Gartner found 67% of B2B buyers prefer to evaluate without a sales representative, up from 61% a year earlier. The technical evaluator is the person most likely to prefer that, most likely to form their view from public material alone, and least likely to ever tell you what they concluded.

What the forty minutes actually contains

Having been on the receiving end of enough of these, and having later been the person doing them, the sequence is remarkably consistent.

Minutes 0 to 5: the docs homepage. Not the marketing site. The engineer is checking whether documentation exists as a first-class thing or as an afterthought, and they form a strong prior in under a minute from the information density of that one page.

Minutes 5 to 15: one hard page. They pick the thing they know is difficult in this category and read only that. For an identity product it is the SCIM or SAML edge cases. For a detection product it is how you tune false positives. For anything with an agent it is the resource footprint. What they are looking for is whether the hard part is documented honestly or elided.

Minutes 15 to 25: errors and limits. Rate limits, error codes, what happens on partial failure. A product whose docs describe only success is a product whose authors have not operated it at scale, and engineers read that signal correctly more often than not.

Minutes 25 to 35: the changelog and the status page. Release cadence, incident history, whether postmortems are public. Eight silent months reads as abandonment. Weekly breaking changes read as churn. A public incident with an honest writeup is a strong positive, which surprises vendors who hide them.

Minutes 35 to 40: one search. Usually the product name plus a term like "issues", "migration", or "problems", to see what people who already run it are saying in places the vendor does not control.

The whole assessment is documentation-shaped. Almost none of it touches the demo, the pricing page, or anything a salesperson controls.

If you are buying

The engineer's forty-minute read is the highest signal-to-noise input in your evaluation, and most committees waste it by collecting it informally and late.

Ask for it deliberately, early, and in writing. Give the person the documentation and one question: what would make you not want to operate this? Then put the answer in the evaluation record where procurement and the CISO can both see it. You will either resolve the objection while there is still time or kill the evaluation in week two instead of month three, and both outcomes are better than the one where it dies silently.

If you are selling

You cannot get into that channel. Stop trying. What you can do is write the material that gets read in it.

That means documentation that describes failure, not just success. A public architecture page that survives a hostile skim. A changelog that shows a maintained product. A security page that does not overclaim. None of this is marketing work and none of it converts on a form fill, which is exactly why so few vendors do it.

Why vendors cannot see this happening

The structural reason this stays invisible is worth naming, because it explains why the pattern persists across an entire industry rather than at a few badly-run companies.

There is no feedback path. The engineer has no incentive to tell the vendor: it costs them time, invites a sales follow-up, and risks being wrong in public. The buyer's champion has no incentive either, because relaying "our architect thinks your agent will fall over" is an uncomfortable message to deliver to someone they have been friendly with. And the salesperson, if they do ask, gets the polite version, which is almost always budget or timing.

So the vendor's CRM fills up with losses coded as "no budget" and "timing", and the roadmap gets built against that. Meanwhile the actual reason sits in a Slack channel the vendor will never see.

I have watched a vendor spend two quarters building a feature to answer a competitive gap that was not the problem, while three consecutive deals died on an undocumented rate limit that would have taken a week to write up.

If you sell in this market, the single highest-value thing you can do is find one former buyer who will tell you the truth about a loss. Not a win-loss survey. One honest conversation, months later, with someone who no longer has anything at stake.

The limit of this

Not every silent no is a technical veto. Budgets move, sponsors leave, priorities get reset by an incident somewhere else in the business, and sometimes a competitor genuinely won. Treating every quiet loss as an engineering objection will send you optimizing documentation when the real problem was that your champion changed jobs.

The claim here is narrower: when a deal dies without a stated reason and the technical evaluator was never in the room, that is the first place to look. It is not the only place.

The Engineer Who Killed Your Deal Was Never on a Call