Knockout criteria are the few requirements where a failure ends the evaluation, whatever the total score. Pick three to six, write them as testable statements, and agree on them before you see any vendor material. Everything else becomes a scored extra.
Why gates and scores should be separate
A weighted score lets a strong feature hide a fatal gap. A tool that scores well on usability but cannot run inside your network still cannot be deployed. Gates stop that. Scores then decide among the vendors who are actually viable.
Without gates, teams also drift into a favourite and bend the weights toward it. Fixed gates written early limit that.
What belongs in a gate
A gate should be binary, testable and tied to a real constraint. Good candidates:
- Supports the languages and package managers you ship today
- Can deploy in the way your data rules require, for example in your own cloud account or on premises
- Integrates with your source host and CI system
- Supports single sign on and role based access
- Lets you export findings and configuration in an open format
- Meets your written data handling terms, such as no training on your code
Poor candidates: "has AI," "is easy to use," "is market leading." None of those can be tested pass or fail.
What belongs in the scored list
Anything where more is better but absence is survivable: depth of reachability analysis, quality of fix suggestions, dashboard design, number of integrations beyond the ones you use, reporting depth. Give these weights as in a weighted rubric.
A test for each gate
Write the test next to the gate. Examples:
- Language support: scan the two largest repos in the pilot and confirm dependencies resolve.
- Deployment: the vendor completes the install in a clean environment you provide.
- Export: export all findings and diff the counts against the console.
- Data terms: a written clause reviewed by your counsel.
If you cannot write a test, you have a preference, not a gate.
Keep the list short
Every added gate removes vendors. Ten gates often means zero vendors, and then someone quietly waives one, which defeats the exercise. Review each proposed gate with one question: would we really refuse to buy a tool that failed only this?
Handle partial passes
Some gates have shades. A vendor might support eight of your nine package managers. Decide in advance: either the ninth is a scored extra, or the gate is "all nine" and the vendor is out. Do not decide after you see who is affected.
Quick check
Can a gate change mid evaluation?
Only for a factual error, such as a misread requirement. Record the change and tell every vendor.
How do gates fit into the RFP?
Put them in the first section as yes or no questions with a demonstration requirement. See RFP structure.
Last reviewed: 19 October 2026.
