Straight answer

Turn each criterion into one requirement your team can test, mark each as a must-have or a nice-to-have, and set your weights before the first demo, so every vendor is scored against your needs rather than its pitch.

Why write requirements before the first demo?

Requirements written after a demo tend to describe the product that was just shown. Writing them first, from a fixed set of criteria, keeps every vendor on the same list. The seven criteria this site scores are a reasonable starting set for teams asking our buyer question; drop or add rows to fit yours.

One requirement per criterion

  1. Data reach without new ingestion: the tool queries the platforms on our list in place, without a new ingestion pipeline, and anything it must ingest is named in writing.
  2. Intel-to-detection speed: given a threat advisory published this week, the tool produces a tested detection rule in the native query language of each of our platforms and shows the steps.
  3. Continuous hunting: hunts run without an analyst starting each one, on a schedule or when new intelligence arrives, and each finding reaches an analyst with its evidence.
  4. Time to first value: the first hunt runs on our own data within a period we agree before signing, with every setup task listed and owned.
  5. Coverage measurement against ATT&CK: the tool shows our rules mapped to ATT&CK techniques, with gaps, on the current ATT&CK version.
  6. Rule lifecycle: every rule is tested against our past data before it goes live, has a version history and can be rolled back.
  7. Buyer transparency: before signing we can read documentation, see the connector list and receive pricing in writing.

Which requirements are must-haves?

Mark each requirement as a must-have or a nice-to-have. A vendor that cannot meet a must-have leaves the shortlist, whatever its other scores. Keep must-haves few, or no tool will pass.

Set weights before you score

Give the nice-to-haves weights that add up to 100. Our weights are data reach without new ingestion 25%, intel-to-detection speed 20%, continuous hunting 20%, time to first value 15%, coverage measurement against ATT&CK 8%, rule lifecycle 7% and buyer transparency 5%; yours may differ. Enter yours in the calculator to see how the six tools order on our scores with your priorities, and use the same weights when you score demo answers.

Agree the scale in advance

For each requirement, agree what a 5, a 3 and a 1 look like before the demos. This site uses five levels, from 5, documented in detail with specifics, to 1, not addressed or built for a different job. A shared scale keeps scores consistent across reviewers and across vendors.

Keep it short enough to use

Seven requirements on one page is enough for a first round. The detail belongs in the proof of concept, which the buyer note Running a proof of concept for hunting on existing data covers.

Next lesson

From demo to decision

Score demo answers on one scale, separate what was shown from what was said, ask the pricing and procurement questions early, and run a proof of concept before deciding.

Related

Editorial assessment · Desk research from public vendor material, last reviewed September 2026