how to run a security POC that ends in a decision

A security POC ends in a decision when the decision was agreed before the POC started. That means three things written down at kickoff: who decides, what result counts as success, and what happens the week after a successful readout. Everything else in this guide is a way of getting those three on paper without sounding like procurement.

a passed POC and a buying decision are two different layers

The POC answers a technical question. Does the product detect what it should, integrate with what they run, and stay quiet enough for the team to live with it. The buying decision answers a different set of questions: is this worth the money this year, who signs, and who takes the blame if it goes wrong.

The way this goes wrong is quiet. The POC passes the first layer and never touches the second. The engineers liked it. The report is green. Nothing moves.

The size of the second layer is the reason. Forrester’s State of Business Buying 2026 puts a typical B2B purchase at 13 internal stakeholders and nine external influencers. The people who ran your POC are three or four of them. The rest will hear about it in a slide, or not at all.

And the default outcome is doing nothing. Matt Dixon and Ted McKenna, working from about 2.5 million recorded sales conversations, report that 40% to 60% of deals end with the customer making no decision. A POC that is not tied to a decision process feeds that number. It gives a nervous buyer a structured, respectable reason to wait.

agree to a POC only when three things are true

A POC costs real money on both sides. Your side pays in senior presales time, environments and escalations to product. Their side pays in evaluator hours, an IT admin, a security reviewer and a project lead. Before saying yes, check three conditions:

1. The doubt cannot be resolved more cheaply. Ask what they would need to see to recommend the purchase. If the answer is a specific behaviour in their environment, a POC may be the right tool. If the doubt is about you as a company, references and an executive call answer it faster. If it is about risk, security documentation and an architecture review do.
2. They will decide when the doubt is resolved. There is a decision date tied to something they care about: a contract expiry, an audit, a budget cycle, a NIS2 or DORA milestone.
3. They are investing their own people. Named evaluators, an environment, data, time in calendars. A buyer who will not commit staff is telling you the priority.

The requests to push back on look familiar. The POC request arrives before discovery. Nobody can say who decides. The evaluation team is junior and the budget holder has never heard of the project. The scope is “let us play with it”. The requirements match one competitor’s datasheet line by line.

There is also a quieter signal. 6sense’s 2025 buyer experience report, a vendor survey of about 4,000 buyers, found that 95% bought from the vendor list they started with. If you were invited late into a bake-off, it is fair to ask how the shortlist was formed before you spend four weeks of an engineer on it.

Saying no does not have to end the conversation. Turn the refusal into conditions: “If your architect confirms the integration approach and we agree what a good result looks like, we can start the week after.” That tests commitment and keeps the door open.

the entry gate: what must exist before day one

You have the most bargaining power before the POC starts. After kickoff, your investment is sunk and their position gets stronger. GitLab’s public handbook states the principle plainly: a customer request is not approval, and execution starts only after scope, readiness and manager approval are done.

A workable gate covers six items:

• The problem and its owner. Written, from discovery, with the cost of leaving it unsolved.
• The decision process and the paper process. How they will decide, and the steps from decision to signature. A technical win that enters an unknown procurement process can sit there for a quarter.
• Named people on both sides. Evaluators, a champion, and the person who owns the budget. Evaluators without a named budget owner is a common setup for a technical win followed by silence.
• A ready environment, or a dated plan for one. Network access, accounts, test data, approval to install agents, firewall changes.
• The security and legal path. If their security team must approve you before data moves, start that review now. If personal data will reach a vendor-hosted environment, you are probably a processor under GDPR Article 28 and the processing terms need to be signed first.
• The commercial consequence of success. A price range already discussed, procurement steps already scheduled, or at least a verbal agreement with the budget owner on what happens next.

The last item is the one most often skipped, and the one that matters most. Present the gate as protection for their team’s time: “Before we take five of your people for a month, let’s make sure we can give you a decision at the end.”

success criteria the buyer signs

Success criteria are the contract of the evaluation. GitLab asks for one to three measurable goals, each with a baseline, a target, a metric and an evidence source. Guideflow suggests three to five. The numbers differ; the rule is the same. Few, measurable, written, approved by the people who decide.

“Fast search” is a wish. “Median query response under two seconds on your 90-day log set with 20 analysts working at the same time” is a criterion. “Easy to use” becomes “three analysts with no prior training complete the five core tasks within 30 minutes after a one-hour onboarding”. Converting the vague version into the measurable one is discovery in its own right, because it forces the buyer to say what they mean.

Sort the criteria into tiers. Mandatory ones must all pass. Weighted ones add to a score. Observations get recorded without scoring. Without tiers, one minor gap gets presented as failure by whoever wanted the incumbent to stay.

Two traps on your side. Criteria your product passes easily but that do not bear on the decision produce a green report and no deal. Criteria copied from a competitor’s evaluation guide test the competitor’s strengths.

Then write the consequence. One sentence: “If criteria one to three are met, we proceed to commercial negotiation for the scope described, targeting signature by the end of the quarter.” Many buyers will not sign that sentence. Their refusal is information you get for free, before you spend the engineering time.

timebox it, and start the clock at the right moment

Evaluations expand to fill the time available. GitLab runs its standard evaluation over 30 days, with a check around day 15 and a readout at day 30. Rework’s 2026 guidance puts it bluntly: anything longer than 12 weeks is not a POC. These are vendor norms and nobody has measured them, but they point the same way. Most POCs should finish in one to two months.

Count day one from the first day evaluators can work. Set a separate readiness deadline for the environment, so setup delays are visible instead of eating the timebox.

Treat every extension as a change request. Written, with a reason, with what will be done in the extra time, approved by the same people who approved the plan. One extension for a documented delay is normal. A second one means the decision is not real, and the next conversation belongs with the budget owner.

security POCs fail in their own ways

A security product proves its value in events that should be rare. A quiet network for four weeks shows nothing. So a security POC usually needs three kinds of evidence: attack simulation against an agreed test plan, observation of normal operation to measure noise, and integration with the tools they already run.

Agree in advance what counts as a detection, at what severity and within what delay, and what counts as a false positive. Then add a noise rule: a cap on analyst hours per week spent on alerts. A product that catches everything and buries a five-person team in alerts has failed the test that matters to them.

Write down which response actions are switched on and on which systems. An agent that isolates a production host during a POC ends the evaluation, and possibly your relationship with the champion.

Expect them to test your own security too. CISA’s Secure by Demand guide lists questions buyers can ask about patching, default authentication, audit logs and vulnerability disclosure. They make good POC criteria, and a vendor that brings its own answers to the kickoff saves a week of questionnaires later.

when a partner runs the POC

In much of Central and Eastern Europe the POC is run by a distributor’s or integrator’s engineers. That brings local language, local regulation and the people who will implement the product. It also brings a gap: the vendor learns about a failed partner-run POC after the deal is lost.

Close the gap with structure. Give partners the same success criteria and readout templates you use. Review the criteria before kickoff on anything above a threshold. Record the POC in the deal registration, so the partner’s work is protected and you see the pipeline. And keep an escalation path to your own engineers open for the duration.

the readout is the decision meeting

Send the written results to your champion before the meeting, so surprises get handled in private. Have the commercial proposal ready. “We’ll send pricing next week” loses the deal at the moment of highest conviction.

Structure the readout around the criteria they signed: the problem, each criterion with the evidence against it (their data where possible), what did not work and why, the implementation path, and the ask. State your gaps before they raise them.

There are four honest outcomes. A technical win with agreement to proceed moves to negotiation. An inconclusive result needs a short, scoped extension or a stop. A technical loss gets recorded with specific reasons and sent to product. And a technical win without agreement to proceed is the dangerous one. It means the decision process or the budget was never confirmed, and the work goes back to qualification.

a word on POC conversion statistics

You will see claims that POCs convert at 60% to 80%. PreSales Pulse reports a 41% median demo-to-close rate for POC-anchored approaches against 15% for scripted demos, from aggregated data that does not disclose deal counts. Rework states 60% to 80% for POCs “done right” without citing a source.

All of these share one problem: POCs are run on deals that are already qualified and often already favoured. A high close rate among them does not show that the POC caused the win. I looked for an independent benchmark of sales-assisted POC conversion and did not find one. Your own numbers are more useful: approved requests, POCs finished on time, technical wins, closes after a technical win, and the time from readout to signature.

what to do with the next POC request

Ask one question in the first meeting, before anyone mentions an environment: “If this works the way you need it to, what happens next, and who makes that call?” The answer tells you whether you are being invited into a decision or into research.