Stop a security tool trial early when a pre-agreed kill criterion is met, such as a failed must-have test, a data handling answer you cannot accept, or results that cannot be reproduced. Write these criteria before the trial begins, so ending it is a planned decision rather than a mood.
Why plan an early exit
Trials drift. A vendor offers more time, a champion gets attached and the sunk cost grows. Teams then spend weeks on a tool that failed on day three. Writing kill criteria in advance protects your time and keeps the vendor relationship fair, because they know the rules too.
Five triggers worth writing down
- A must-have fails. If a requirement you marked mandatory does not work on your repository, the trial has answered its main question. Examples include no support for a core language, or no way to export findings.
- A data answer is unacceptable. If the vendor's answer on where code or findings go, how long they are kept, or whether they train models on them conflicts with your policy, stop. Ask for the answer in writing first.
- Results are not reproducible. If the same scan on the same commit returns different results and the vendor cannot explain why, you cannot build a process on it.
- Noise overwhelms signal. If a sampled review shows most surfaced findings are not actionable, and tuning does not change that within an agreed effort, the cost per useful finding is too high.
- Support fails the test. If a question you asked during the trial goes unanswered beyond the agreed window, expect the same after you sign.
Each trigger needs a number or an event, not a feeling. "Most findings" should become a percentage you chose in advance.
A simple record
| Criterion | Threshold | Checked on | Result |
|---|---|---|---|
| Must-have test passed | All pass | Day 3 | |
| Data handling accepted | Written answer matches policy | Day 2 | |
| Reproducibility | Same output twice | Day 4 | |
| Noise sample | Agreed share actionable | Day 10 | |
| Support response | Within agreed window | Throughout |
Share the table with the vendor on day one. Fewer surprises follow.
How to end it well
If a criterion triggers, tell the vendor the same day, name the criterion and ask whether they believe it was measured fairly. Sometimes they will point to a setup mistake, and you can decide whether to re-run once. Then ask for deletion of any data you shared and confirm it in writing. Keep a one page summary for the file so the next evaluation starts from what you learned.
Do not confuse early exit with a verdict on everything
Ending a trial because one must-have failed does not mean the product is poor. It means it does not fit your requirements today. Record the reason precisely, such as "no support for our build tool", so that you can revisit the vendor if that changes, and so your team learns which requirements truly drive your choices.
Where Safeguard fits
The same rules apply if Safeguard is on your list. Begin with the free scan at gold.safeguard.sh/scan, and write your own criteria for any longer trial before it starts.
Quick check
Is stopping early unfair to the vendor?
Not if the criteria were shared at the start. It saves both sides time.
Can a vendor ask to restart the clock?
They can ask. Agree only if the cause was a measurable setup error, and restart with the same criteria.
Last reviewed: 19 October 2026.
