Reading a vendor's response-time number: sample, clock, who measured

Vendor pages are full of response-time figures: 90 percent faster, 10 times faster, under five minutes. Some may be true. Almost none comes with enough detail to check. The rubric on this site treats an outcome number with no published method as partial at best, however large the number.

Four questions turn a number into something you can weigh.

1. Sample. How many incidents or alerts, from how many customers, over what period?
2. Clock. Which event starts the clock and which stops it? Is it triage, response, containment or closure?
3. Measurer. Did the vendor count, the customer count, or a third party?
4. Baseline. Faster than what, measured how, and by whom?

If a figure fails the first three, it is a claim. If it fails the fourth, the percentage has no denominator.

These are figures from vendor pages and customer stories, with what each page does and does not say. All are vendor or customer claims. None carries a published method.

Cyware. The Orchestrate page claims it reduces manual security tasks by 80 percent (read 2026-11-03). The page gives no data behind the figure. The measure is manual tasks, not response time.

Palo Alto Cortex XSOAR. The product page says reduce time spent on incidents by 90 percent (read 2026-11-03), reported as time savings from aggregated customer use cases. No baseline, sample or method. Time spent on incidents is analyst effort, not containment time.

Torq. A customer case study headline claims a global pharma customer cut MTTR by 92 percent (read 2026-11-03). The customer is unnamed, and the baseline, period and method are not stated. MTTR could mean response, resolution or repair, and the page does not say.

Swimlane. The home page claims Hero AI reduces MTTR by 75 percent (read 2026-11-03) with no method. The customers page carries a testimonial from Thetabyte of threats contained in under 5 minutes and a 70 percent reduction in incident response time (read 2026-11-03), from one customer, with no period. It is a customer claim, a testimonial published by the vendor. This is one of the few figures that names containment. It is still one customer's statement.

Prophet Security. The AI SOC Analyst page says it investigates and responds to alerts 10 times faster (read 2026-11-03), under a heading about lower MTTR. No figure, baseline or method. The home page claims validated escalations in under 30 minutes for its Watchtower service. That is escalation, not containment.

D3 Security. Its platform page claims about 90 seconds end to end on a typical alert (d3security.com/llms-full.txt, read 2026-11-03) through a five-stage pipeline. The page gives no sample, alert type or method. It measures triage and verdict.

Splunk. The SOAR page quotes Tide as moving to minutes to respond compared to hours previously (read 2026-11-03), a customer claim with no method. A separate seven-minute figure on the page is about detection.

Notice what repeats. The clock is not stated. The measurer is the vendor or one customer. The baseline is a phrase such as "previously". The sample is one.

Mate Security publishes no time-to-contain figure and no method on the pages read (home page, read 2026-11-03). Its home page does carry other outcome numbers, such as 98.7 percent accuracy on 7,200 alerts. Those are vendor claims about alert investigation. The sample size is stated, and where the alerts came from, how ground truth was set and who labelled them is not. They tell you nothing about containment time.

Google's Response Agent page and Microsoft's Sentinel automation page publish no time-to-contain figure either. For a platform, silence on the number is not a fault, and it is easier to live with than an unsupported figure. It does mean you must measure it yourself.

The most common sleight in these pages is to quote a triage figure beside a response claim. A platform can reach a verdict on an alert in 90 seconds and still wait 40 minutes for a human to approve the isolation. Triage speed matters because it feeds the clock. It is a different clock.

Whenever a page says response, ask whether the action ran or whether a case was created. Many do not know the difference in their own copy.

A named customer on a vendor page adds credibility about the existence of the customer. It adds little about the number. The customer was chosen by the vendor, quoted by the vendor and approved by the vendor. A percentage from a testimonial is a vendor claim with extra steps, and this site files it that way.

Ask each vendor for four things, in writing.

• A containment timeline from a real incident, anonymised, showing the first detection signal and the first confirmed containing action.
• The count of incidents behind any aggregate figure, and the period.
• A reference customer you may call, who can describe how the figure was counted.
• Permission to replay your own incidents through a trial.

Then measure it yourself. Our guide on what time to contain measures shows the six fields to log, and the guide on running a pilot shows how to compare a trial to your baseline.

• Every figure is filed with its page, read date, claimed value and the words "vendor claim" or "customer claim".
• Each figure has an entry for sample, clock, measurer and baseline, or the words "none published".
• Triage and verdict figures are kept apart from containment figures.
• Testimonial figures are not used in scoring.
• The vendor has been asked for an anonymised containment timeline and a reference you may call.
• You have your own measurement plan before the first trial begins.