The rubric: eight criteria, one metric
Every score on this site comes from the table below. The weights are published, each platform is scored on the same evidence, and totals are computed in code. Version 2026.11, written 2026-11-03, applied to pages read 2026-11-03 and 2026-11-04.
0the clock starts at detection
The metric the rubric is organised around
Time to contain: Elapsed time from the first detection signal on an incident to the first action that stops the attacker spreading or acting (host isolated, session revoked, account disabled, message pulled, key rotated, address blocked). Not time to close the ticket, not time to resolve.
Containment is the step automation can shorten most and the step where a wrong action costs most. Every criterion below is a reason a platform's time to contain is either fast and safe, or fast and unsafe, or slow.
100points in total
Eight criteria and their weights
| Criterion | Weight | The question it answers |
|---|---|---|
| Native containment coverage | 25 | Of the containment actions a SOC needs across EDR, identity, email, cloud and network, how many can the platform take through documented, vendor-shipped integrations? |
| Published time-to-contain evidence with method | 15 | Does the vendor publish a time-to-contain or equivalent figure, and does it say what was measured, on how many incidents, by whom, and when? |
| Approval, rollback and blast-radius controls documented | 15 | Can a SOC lead read, before buying, how an automated containment action is gated, limited in scope, and undone? |
| Explanation and audit trail | 15 | After an automated action, what can a reviewer or regulator read: who or what decided, on what evidence, what was executed, with what result, and can it be exported? |
| Integration depth documented | 10 | How many integrations and actions, and can a buyer check them in a public list? |
| Detection-to-response coupling | 8 | Does the platform take detections directly from EDR, identity, email and cloud tools, or does it need a SIEM in front? |
| Pricing transparency | 6 | Can a buyer find a price or a pricing unit without a sales call? |
| Deployment and data handling | 6 | Where does it run, where does data live, and is customer data used to train models? |
What documented, partial and not documented mean
Each criterion has three statuses with a fixed score band. A reviewer reads the vendor's pages, picks the status the evidence supports, and records the score, the reason, the source URL and the read date.
- documented: scores 8.0 to 9.5
- A page the vendor controls (docs, product page, release notes) states the capability with specifics a reader can check: named actions, named modes, a figure with its method, or a published price.
- partial: scores 5.0 to 7.9
- The capability is stated but thinly: a figure with no method, a mode named without detail, a count with no list, a preview feature, a price on a marketplace listing only, or evidence that exists only in a secondary source.
- not documented: scores 2.0 to 4.9
- Nothing on the pages read states it, or the page could not be read. This is a finding about public material, not a claim that the capability is absent.
Per criterion
| Criterion | Documented, 8.0 to 9.5 | Partial, 5.0 to 7.9 | Not documented, 2.0 to 4.9 |
|---|---|---|---|
| Published time-to-contain evidence with method | A containment or response-time figure with sample size, who measured it, period and what clock start and stop mean. | A figure (customer quote or vendor aggregate) with no method, or a metric that is adjacent (MTTR, time saved, cases closed) rather than containment. | No figure, or only adjectives such as 'in seconds' or 'at machine speed'. |
| Approval, rollback and blast-radius controls documented | Approval modes by risk tier or action, per-action or per-integration overrides, and either rollback or an explicit scope limit (one session, one host, a count cap), in vendor docs. | Approval or human-in-the-loop is named without tiers or overrides; or rollback is only for workflow versions, not for actions. | No approval, rollback or scope control stated. |
| Explanation and audit trail | Per-action record (actor, time, evidence, command, outcome) described with its contents, plus export or retention stated. | An audit trail or 'shows its work' is stated without its contents, export or retention. | Nothing stated about what is recorded after an action. |
| Integration depth documented | A public count and a browsable list of integrations or actions with action-level detail. | A count or a list of logos without action-level detail. | No count and no list. |
| Detection-to-response coupling | States direct ingestion from named detection sources, or is itself the detection layer (SIEM or XDR). | Accepts alerts through webhooks or connectors, with the SIEM question unaddressed. | Not stated. |
| Pricing transparency | Public prices with unit and date, or a self-serve tier with limits and prices. | A pricing unit, a free tier, a trial, or a marketplace listing price, but no price list. | Talk to sales, or a pricing page that does not resolve. |
| Deployment and data handling | Deployment options, data regions or isolation, and model-training statement, in vendor docs. | Certifications or a trust-centre link without the specifics, or only some of the three. | Not stated on the pages read. |
Ceiling. Nobody scores 10. The ceiling is 9.5. A score above 9.0 needs a documented status plus a second independent source (docs and release notes, or vendor docs and a customer or analyst statement).
Vendor claims. A vendor's own statement about itself is a vendor claim and is labelled as such. A vendor claim can reach documented status for a design or control (what the product does), never for an outcome number (accuracy, closure rate, MTTR) unless the method is published. Outcome numbers without a method cap the criterion at partial. A statement on a vendor's own page is labelled vendor claim wherever it appears on this site.
Not documented. A status of not documented is a finding about public material. It is not a claim that the capability is missing, and a page that could not be read, for example one that returned HTTP 403 or 404, is scored as not documented with the reason shown.
25actions in the catalogue
How native containment coverage is computed
Coverage is the heaviest criterion, at 25 of 100 points, and the only one computed from a count. The containment coverage scorecard checks 25 actions across EDR, identity, email, cloud and network against each vendor's own documentation.
- Count. The action appears in the vendor's own documentation (integration action list, action reference, or product docs) as a shipped action for at least one named product in that domain. A generic HTTP request step, a custom script, a community-contributed pack that the vendor does not list in its own docs, or a statement such as 'integrates with CrowdStrike' does not count.
- Share. Coverage share is native plus partner actions divided by 25. Custom and not documented count as zero.
- Score. Score is 2.0 plus 7.5 times the share, rounded to one decimal and capped at 9.5. The rubric file proposed a 12-action catalogue and this formula; the scorecard has 25 actions, so the denominator is 25 and the formula is unchanged.
- Status. Documented from two thirds of the actions with four or more of the five domains covered, partial from one third, not documented below that. These are the rubric's thresholds of 8 and 4 of 12, scaled to 25.
Worked example: D3 Security has 19 of 25 actions, a share of 76 percent, so its coverage score is 2.0 plus 7.5 times 0.76, which rounds to 7.7.
7.23the top total today
How totals are built, and when they are a band
Total is the sum over all eight criteria of weight times score, divided by 100, shown to two decimals. Every platform page prints the eight weighted parts, and the build checks that the printed total equals their sum.
Totals are grouped by one rule: a band is a run of neighbouring totals with no gap of more than 0.25 between one total and the next, so a band can span more than 0.25 from top to bottom. A band is not a ladder. Bands chain: a new band starts only where the gap to the total above exceeds 0.25, so a band can be wider than 0.25 and the order inside it is not an order. The order inside a band is not settled by the evidence, and the home table shades the rows of every band with more than one platform.
Before the scorecard existed, totals were provisional: they were computed over the seven non-coverage criteria and rescaled. Those provisional scores are the ones the profiles call the seven other criteria. Final totals include coverage.
5reweightings
Buyer-type weights
The published rubric keeps the weights above. The buyer-type rankings reweight the same scores for a regulated financial team, a lean team, an MSSP, a Microsoft estate and a CrowdStrike estate. Each set of weights sums to 100 and is checked in the build.
What this rubric does not do
It scores what is public. A vendor that documents little ranks lower, whether or not the product is good. It does not test products, it does not measure how fast an action runs, and it does not credit a customer logo as a reference. Scores can change when a vendor publishes documentation, and every change is logged on the corrections page. See the editorial policy and the scorecard method.