MTTD and MTTR are the two metrics used to measure time within a security incident. MTTD (Mean Time To Detect) is how long an organization takes to realize that something is happening. MTTR is how long it takes to do something about it, and that is where the confusion begins, because those four letters are used for four different things.
Why they matter fits in two data points. The CrowdStrike 2026 Global Threat Report puts the average breakout time of an eCrime attack at 29 minutes, with a fastest observed time of 27 seconds. The IBM Cost of a Data Breach 2026 puts the mean time to identify a breach at 183 days.
Twenty-nine minutes versus one hundred eighty-three days. The whole conversation about detection and response lives inside that gap.
What is MTTD?
The MTTD (Mean Time To Detect), or mean time to detect, is the average time an organization takes to identify an incident from the moment the incident started. It is calculated by adding up the detection time of all incidents in a period and dividing by the number of incidents.
The key word in that definition is started. And it is where almost every dashboard lies a little.
If the clock starts when the SIEM generated the alert, what you are measuring is how fast your team handles alerts, not how fast your company sees an attack. The honest clock starts at the first indicator of compromise that the forensic investigation finds afterward, even if no one saw it at the time. That is the uncomfortable number, and it is the one that can be improved.
What is MTTR and why does it mean four things?
Here it pays to be very literal, because I have read contracts where the provider and the client signed the same acronym thinking of times that differ by weeks.
| Acronym | What it measures | When the clock stops |
|---|---|---|
| Mean Time To Respond | Reaction | When an analyst takes the case and executes the first real action |
| Mean Time To Contain | Containment | When the threat stops spreading: device isolated, account blocked, session terminated |
| Mean Time To Repair | Technical remediation | When the affected system is clean and operational |
| Mean Time To Recover | Business recovery | When the service returns to normal for the end user |
All four are useful and measure legitimate things. The problem is signing for one without saying which. At ZetTateK, when we talk about MTTR in a service agreement we mean response and containment, because that is the stretch that a SOC controls end to end. Full recovery depends on backups, on vendors and on business decisions that no analyst signs off on alone.
How are they calculated, with a real example?
Suppose four incidents in a month, detected at 4 hours, 30 minutes, 12 hours and 6 minutes after the compromise. The total is 16 hours and 36 minutes, divided by four: an MTTD of 4 hours and 9 minutes.
That average looks reasonable and hides what matters: one of those incidents took 12 hours. If the attacker spreads in 29 minutes, the 4-hour average does not describe the risk, it dresses it up. That is why I always ask the dashboards I review for two more things: the 90th percentile (the time that 9 out of 10 incidents do not exceed) and the breakdown by incident type, because a phishing email reported by a user and a ransomware attack with lateral movement do not belong in the same average.
What numbers are considered normal today?
The industry reference figure comes from this year's IBM report, which analyzed 602 organizations with breaches that occurred between March 2025 and February 2026. The full breach lifecycle rose to 247 days: 183 to identify it and 64 to contain it. It is the first increase after five years of decline.
Cost moves with the clock. Breaches closed after day 200 averaged 5.65 million dollars. Those closed earlier, 4.32 million. A difference of almost a third, and what explains it is the clock.
There is a third data point from the same report that often goes unnoticed and that I find the most useful for justifying a budget: internal security teams discovered about 4 out of 10 breaches and closed them some five weeks earlier than the global average. When the one who gives notice is the attacker, and that happened in roughly 1 out of 6 cases, the breach turned out to be the most expensive of all.
What really brings MTTD down?
None of these things is a purchase; all of them are an operational decision.
- Real 24-hour coverage. Cybercrime does not keep office hours and chooses nights, weekends or long holiday weekends precisely because no one is watching. An office-hours shift does not lower MTTD, it postpones it.
- Telemetry where it is needed. Endpoint, identity, cloud and email. What does not send logs does not get detected, and it is usually the old server no one wanted to touch.
- Correlation, not isolated alerts. Three signals that are harmless on their own are an attack when read together. That is the job of a SIEM that is well tuned and a layer of XDR.
- Automation of the first action. A playbook in SOAR that isolates a device in seconds does for MTTR what no manual process is going to achieve at three in the morning.
- Proactive hunting. Threat hunting exists precisely to find what did not trigger any alert, which is the material the 183 days are made of.
Where does measurement break down?
Four failures I see repeated in audits, ordered by how expensive they turn out to be.
The first is survivorship bias. You can only measure the incidents you detected. The ones you never saw are not in the average, and they are exactly the ones that define your exposure. An MTTD that improves while the volume of detected incidents plummets is not good news, it is an alarm.
The second is stopping the MTTR clock when the ticket is closed. The ticket is closed when the analyst finished their work, and the business recovers when the user is billing again. It is almost never the same minute.
The third is measuring only the average. A 90th percentile of 14 hours coexists perfectly well with an average of 20 minutes, and the attacker always slips in through the percentile.
The fourth is measuring nothing and assuming. It is more common than it seems: the company has tools, has a contract with a provider and does not have a single written number on how long it took to find out last time.
Five questions for your security provider
- What were your measured MTTD and MTTR last quarter, and are they in writing in the SLA?
- From what exact moment does each clock start and at which one does it stop?
- Is that MTTR response, containment, remediation or recovery?
- Is the number the same at three in the morning on a Sunday as at eleven on a Tuesday?
- Will you give me the 90th percentile and the breakdown by incident type, or only the average?
If a provider cannot answer all five, the conversation about price is premature.
Frequently asked questions
Measuring is the first control
A client once told me he did not measure his times because the result would embarrass him. I told him what I always say: the number exists anyway, whether you measure it or not, and the attacker already knows it.
Our service for managed 24/7 SOC reports MTTD and MTTR per incident and per quarter, with the clock starting at the compromise and not at the alert. If you don't have those two numbers yet, the no-cost security assessment is the fastest way to get the first one. You can review the other terms in this article in our cybersecurity glossary.
An attacker needs 29 minutes. The question is not whether your company is protected, it is how many minutes it takes to find out.
