How to Negotiate a Security Tool Contract After the Bake-off

This guide follows on from running a structured bake-off. If you haven't built your bake-off scorecard yet, start there.

The evaluation is done. You have a winner. Now comes the part nobody prepares for — and where most of the value gets left on the table.

Most security teams treat the contract negotiation as a separate event from the evaluation — something that happens after the technical decision, handled by procurement, focused primarily on getting a percentage discount off the list price. This is a mistake. The most powerful negotiating position you will ever have with a security vendor is the moment immediately after your bake-off concludes, before you've told them they've won. At that moment, you have something the vendor desperately wants — a committed buyer — and something they don't know you have: a scored gap analysis that tells you exactly where their product fell short. That gap analysis is worth money. Here's how to use it.

Before the negotiation: what to extract from your bake-off results Before you contact the winning vendor's commercial team, extract three things from your evaluation:

1. The gap list. Every criterion where the winning vendor scored below 8. These are the areas where their product didn't fully meet your requirements. Some of them may be acceptable gaps. Some of them may be things you'll need to work around. All of them are negotiating leverage.
2. The runner-up's superior scores. Identify every criterion where the runner-up scored higher than the winner. These are the areas where you're accepting a compromise by choosing the winner — and they're the specific points where the winner needs to demonstrate they're worth the tradeoff.
3. The delta between the POC and the vendor's claims. If the vendor claimed sub-60-second MTTD and you measured 3 minutes in your environment, that's a specific, documented performance gap. If they claimed native SIEM integration and you spent two days on configuration, that's a gap. These deltas become SLA clauses.

The five things you should always negotiate

1. Performance SLAs tied to your POC benchmarks The best outcome of a structured bake-off is documented performance data from your own environment. Your MTTD measurement, your false positive rate, your SIEM integration latency — all of these become the baseline for contractual SLAs. The ask: "We measured [specific metric] during our POC. We want a contractual SLA that the product maintains this level of performance in production. If it doesn't, we want a defined remediation process and termination rights." Most vendors will push back on this. Many will accept it with some modification — perhaps a shorter remedy period, or a narrower definition of the metric. Whatever you agree on, get it in writing. A vendor confident in their product's production performance will accept reasonable SLAs. A vendor who resists all performance commitments is telling you something important.
2. Price protection on the renewal Security vendor contracts routinely include renewal price increases of 10–20% as a standard term. This is frequently not prominently disclosed in the initial commercial conversation. The ask: "We want a contractual cap on annual price increases — typically CPI or a fixed percentage (5–7%) — for the duration of our initial commitment and through at least one renewal." This is a standard ask in enterprise software procurement and most vendors will accept some version of it. The alternative — signing a 3-year contract with no price protection — means your year 3 cost is unknowable.
3. Expansion pricing locked at current rates If your company is growing, you will add users, endpoints or workloads during the contract term. Expansion pricing — what you pay for those additional units — is almost always higher than the rate you negotiated for the initial contract. The ask: "We want expansion pricing locked at the same rate as our initial contract for the duration of the term." Some vendors will offer a fixed rate at a slight premium to the initial rate. Get the expansion rate in writing before you sign the initial contract.
4. The capabilities you identified as gaps — as a contractual commitment If your evaluation identified a specific capability the vendor claimed was on their roadmap, but which wasn't available during the POC, decide whether that capability is important enough to require a contractual commitment. The ask: "Your product's [specific capability] is on the roadmap for [specific quarter]. We want a contractual commitment that if this capability is not delivered by [date], we have the right to renegotiate or exit the contract without penalty." Vendors will often accept reasonable roadmap commitments for capabilities they are genuinely planning to deliver. A vendor who refuses to commit to their own roadmap is signalling that the timeline is less certain than their sales team implied.
5. Exit rights tied to performance The single most important clause in any security vendor contract — and the one most commonly absent — is a clear, specific process for exiting the contract if the product doesn't perform. The ask: "If the product fails to meet the agreed performance SLAs for [X consecutive months], we want the right to exit the contract without penalty." Define the SLAs clearly, define what "failure" means, define the process for documenting and escalating performance issues, and define the exit mechanism. This clause is difficult to invoke in practice and you may never need it. But its presence changes the dynamic of the vendor relationship: you are not locked in unconditionally, and the vendor knows it. That knowledge changes how seriously support escalations are taken.

Using the runner-up as leverage — carefully The runner-up's superior scores are your most direct negotiating leverage. If SentinelOne scored 9 on pricing transparency and the winner scored 7, you tell the winner's commercial team: "We have an alternative that scored higher on commercial flexibility. If you want to close this deal, we need to close the pricing transparency gap." This is legitimate and effective. Do it carefully and honestly — don't fabricate scores or claim the runner-up won when it didn't. But the runner-up's genuine advantages are real, they're documented, and the winner's commercial team knows you have an alternative. The leverage decreases the longer you wait to use it. The moment you tell the winning vendor they've won, your leverage collapses. Tell them they're your preferred vendor, not that they've won. Keep the runner-up warm until the contract is signed.

The timing that most teams get wrong Most security teams announce a winner, then begin commercial negotiations. The vendor knows they've won. The urgency is gone. The negotiating position has shifted entirely to the vendor. The right sequence: Complete your bake-off and have a clear winner internally. Contact the runner-up's commercial team and let them know they were competitive but you have some concerns — leave the door open. You may not need them, but their continued engagement is leverage. Contact the winning vendor's commercial team and tell them they're your preferred vendor, pending satisfactory commercial terms. Negotiate against the specific list above. Only announce the winner externally — to the runner-up and internally — after the contract is signed. This sequence preserves your leverage for the entire commercial process. It's uncomfortable, but it's the correct approach.

The one thing to get right above everything else The most important outcome of a good bake-off negotiation is not the discount. It's the performance SLAs. Discounts are a one-time saving. Performance SLAs govern the entire relationship for the duration of the contract. A vendor with contractual performance commitments tied to your POC benchmarks is a vendor who has skin in the game. A vendor without those commitments is a vendor who has your signature and nothing else holding them to the performance you evaluated. If you can only win one thing from the negotiation, win the SLAs.

The gap analysis, the runner-up scores and the POC benchmarks that make this negotiation possible are all outputs of a structured bake-off on pmpa. Free for security teams. → picari.io May the best contender win.

---

What to read next: Once you've negotiated the contract, the final step is presenting your verdict to your CISO. Ready to run a structured evaluation? Start your briefing →