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.
What do MTTD and MTTR actually measure?
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:
- Time to notify. The provider tells you what happened. This produces the smallest number.
- Time to contain. A host is isolated, an account is disabled or an IP is blocked at the firewall.
- Time to resolve. The environment is clean and the root cause is fixed. This often depends on your own team or MSP, so few providers quote it.
None of these is the wrong measure. The problem is a number quoted without saying which one it is.
Where should the response clock start?
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:
- The event occurs in your environment
- The source platform, such as Microsoft 365 or your EDR, records it
- That platform delivers the telemetry to the provider
- The provider confirms a detection
- A ticket or report is created
- You are notified, or containment happens
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.
Why does most detection time pass before the provider sees anything?
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.
Should you trust a single headline number?
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.
Median versus mean
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.
Targets by priority
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.
Attainment against target
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.
What MTTD and MTTR does Gradient Cyber deliver?
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:
- Priority 1, Critical: 30 minutes. Phone call, email or SMS, and a SitRep alert. Quarantine of affected endpoints, blocking identified threats at the firewall, threat hunting and root cause analysis.
- Priority 2, High: 60 minutes. Email or SMS and a SitRep alert. Affected assets identified, threats quarantined or deleted, and malicious external sources added to firewall blocklists.
- Priority 3, Medium: 4 hours. Email or SMS and a SitRep alert. Threats quarantined on endpoints and blocked at the firewall.
- Priority 4, Low: 8 hours. Email or SMS and a SitRep alert. Threats quarantined on endpoints and blocked at the firewall.
- Priority 5, Informational: 24 hours. Email or SMS and a SitRep alert, with recommendations for policy and process improvements.
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.
What should you ask an MXDR provider for?
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.
- Where does your MTTD clock start: at the event, at telemetry arrival or at the alert?
- Where does your MTTR clock stop: at notification, at containment or at resolution?
- Are these medians or means, and over what period and how many incidents?
- What are your targets by priority, and how often did you meet them last quarter?
- Do your numbers include data sources that deliver slowly, or only the fast ones?
- Can you walk me through one recent critical incident, timestamp by timestamp?
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.
Frequently asked questions
Is MTTR the time it takes to fix the problem?
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.
Why does Microsoft 365 slow down detection?
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.
Should a provider report the mean or the median?
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.
Are response-time targets guaranteed?
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?