Ask three MXDR providers for their response time and you will get three numbers that cannot be compared. One starts the clock when an alert reaches its SOC. Another stops it when a ticket is opened. A third quotes an average that a single bad week can drag around. A response time is only useful once you know exactly what it measures.
This post covers what MTTD and MTTR measure, where the clock should start, why most detection time passes before any provider sees a thing, and what to ask for. It also publishes our own numbers and says how we measure them.
MTTD, mean time to detect, is the time from a malicious event to a confirmed detection. MTTR, mean time to respond, is the time from detection to a response. The trouble is the word respond. Depending on the provider, it can mean notifying you, containing the threat or fully resolving it, and those numbers differ by hours.
Three common meanings of MTTR:
None of these is the wrong measure. The problem is a number quoted without saying which one it is.
At the event in your environment. Many providers start the clock later, when an alert lands in their SOC or when a ticket is opened. Each later starting point hides delay that has already happened, and an attacker was active for all of it. Ask for the starting point in writing.
Between an event and a phone call, there are six points where a provider could start or stop a clock:
A provider measuring MTTD from the fourth point can report a fast number while the first three quietly took an hour. The same applies to MTTR. If the two clocks don't connect, you can't add them up to get the number that matters most: how long from the event to someone acting on it.
Because the logs have to arrive first. Cloud, identity and endpoint platforms collect and deliver telemetry on their own schedules, and that delivery usually takes longer than the detection itself. A provider can only shorten the time it controls. An honest MTTD still includes the time it doesn't control.
Microsoft 365 is the clearest example. Microsoft's own documentation for the Office 365 Management Activity API, the feed most providers use for Microsoft 365 audit activity, states that there is no guaranteed maximum latency for notification delivery. Every provider that monitors Microsoft 365 through that feed inherits whatever delay Microsoft introduces. The difference is whether the provider's MTTD includes it.
In our case, the detection step is the fast part. Quorum AI's 8-stage detection pipeline, from parsing and OCSF normalization through correlation and SitRep generation, typically confirms a detection in 3 to 4 seconds once the telemetry arrives. Most of our MTTD is the time source platforms take to deliver their logs to QAI. We count that time anyway, because an attacker can leverage it.
Not on its own. One number hides how a provider performs by severity, by data source and on its worst days. Ask for targets by priority, both the median and the mean, and how often each target is actually met. Those three together tell you far more than any single figure.
A mean is easy to distort. A handful of incidents that took hours, often from one slow data source, can pull it far from what a typical incident looks like. A median shows the typical case but hides that slow tail. Ask for both. A large gap between them tells you some incidents are taking much longer than the headline suggests, and that is worth a follow-up question. Medians are not a vendor trick. Mandiant’s M-Trends report, one of the most cited sources in incident response, publishes its headline dwell time as a median.
A critical finding and an informational one should not share a target. A single response time for everything means either critical findings are slower than they should be or low-priority work is being padded to look fast.
Ask what percentage of incidents met their target over the last ninety days, and for the misses to be listed individually rather than averaged in. A provider that can show you its misses is measuring transparently.
Our typical time to detect is 5.6 minutes, measured from the event at the source to a confirmed detection. Our typical time to respond is 21.9 minutes, measured from first alert to customer notification. Together that's about 28 minutes from event to notification, inside our 30-minute target for critical findings.
How these are calculated: the average of per-source median times for October 2026, across 1,710 customer incidents and every endpoint, network, SaaS and identity source we monitor. The figures include projected values for sources with an update in progress. An incident here is a correlated finding, not a single raw alert.
Our response targets by priority:
Containment actions are taken within response rules each customer approves in advance, through the EDR, firewall and identity systems they already run. Each SitRep records what was done, what remains and who owns the next step.
Ask for both clocks with their start and stop points, targets by priority, and whether the figures are medians or means. Then ask for one recent critical incident with timestamps from first event to notification. A provider that measures honestly can answer all of that in a single email.
For the broader version of this test, see how to tell whether your MXDR service is actually working. If you run a small IT team and after-hours coverage is the real question, start with whether a one-person IT team can get 24/7 security coverage.
Usually not. Most providers measure MTTR to notification or containment, because full resolution often depends on the customer's team or MSP. Ours is measured from first alert to customer notification. Ask every provider which end point they use before comparing numbers.
Microsoft delivers Microsoft 365 audit activity through an API with no guaranteed maximum delivery latency. Any provider monitoring Microsoft 365 that way waits for the logs to arrive before it can detect anything. The honest measure includes that wait.
Both, paired with attainment against target. The median shows a typical incident. The mean shows how much the slow cases pull the average up. Attainment shows how often the provider actually met its targets. Our published figures are built from medians, and we say so.
Ours are service level objectives: targets we measure ourselves against, not a contractual SLA with penalty clauses. Ask any provider which one they are offering, how they measure it and what happens when they miss.
Whatever number a provider quotes, the first question is the same: when does the clock start?