MTTD and MTTR in Plain Terms
MTTD and MTTR are two timing metrics for security incidents. MTTD, mean time to detect, is the average time an incident runs before anyone notices it. MTTR, mean time to respond, is the average time from that moment to dealing with it. Together they measure how fast you catch and stop an attack.
The gap between those two numbers is where damage happens. An attacker who sits undetected for weeks has time to read email, move between systems and copy data before a single control reacts.
This is why MTTD and MTTR turn up in board decks, vendor pitches and NIS2 conversations. Regulators now set reporting deadlines measured in hours, and the cost of a breach rises the longer it runs. Slow detection and response is no longer a technical footnote. It is a financial and legal exposure.
How MTTD and MTTR Are Measured
Both metrics are plain averages. You take every incident over a period, add up the time each one took and divide by the number of incidents. MTTD divides the total time to detection. MTTR divides the total time to response or recovery. The arithmetic is simple. The hard part is agreeing where each clock starts and stops.
Every incident runs through the same stages, and each metric times a different stretch of it.
- Compromise: the attacker gets in. The MTTD clock starts here, usually before any alert exists.
- Detection: a tool or a person notices. MTTD stops and the response clock starts.
- Acknowledgement: someone picks up the alert and owns it. This is MTTA, mean time to acknowledge.
- Containment: the spread is stopped. IBM calls this mean time to contain.
- Recovery: normal service returns. This is where mean time to recover lands.
One warning before you compare numbers with anyone. MTTD and MTTR are measured at two very different scales, and the two are often confused.
At the whole-breach scale the clock starts at the first compromise and runs until the breach is found, and the figures are measured in months. At the operational scale the clock starts when a specific alert fires in your tooling and runs until an analyst acts, and a well-run team works in minutes to hours.
A vendor quoting a response in minutes and a report quoting months are not disagreeing. They are timing different things.
The Metrics Family Around MTTD and MTTR
MTTD and MTTR rarely travel alone. A handful of related metrics describe the same incident lifecycle, and naming them correctly stops a lot of confused reporting.
- MTTD, mean time to detect: how long an incident runs before it is spotted.
- MTTA, mean time to acknowledge: how long an alert waits before a human takes it on.
- MTTC, mean time to contain: how long it takes to stop an active incident spreading.
- Dwell time: the attacker’s time inside before detection, the same idea as MTTD seen from the attacker’s side.
- MTBF, mean time between failures: a reliability metric that tracks how often systems fail, borrowed from engineering.
MTTR is the slippery one. The letters are used for at least four different measures, and teams often assume they all mean the same stretch of time.
- Mean time to respond: from detection to the first response action.
- Mean time to resolve: from detection to the incident being fully closed.
- Mean time to recover: from the incident to normal operations returning.
- Mean time to repair: from a failure to the fix, a term carried over from IT operations.
None of these is wrong. The mistake is leaving it unstated. Before you quote an MTTR or read one in a report, check which of the four it counts, or the number means very little.
Why Slow Detection and Response Costs More
The business case for cutting these numbers is not abstract. The longer an incident runs, the more it costs, and the relationship is steep.
The global average breach in 2025 took 241 days to identify and contain, split into 181 days to find and 60 days to stop (IBM, 2025). That is close to eight months of attacker access on the typical breach.
Time drives the bill directly. Breaches with a lifecycle under 200 days cost significantly less than those that run longer (IBM, 2025). Every extra week of dwell time is more data copied, more systems reached and a longer, costlier clean-up.
A long incident costs more through several mechanisms at once.
- More data exposed: an attacker with weeks inside copies far more than one caught in hours.
- Wider blast radius: time lets an intrusion spread from one machine to the whole estate.
- Longer recovery: a deep, established intrusion takes longer to clean out and rebuild.
- Regulatory exposure: miss a reporting deadline and fines and scrutiny follow.
Recovery time is the half people underestimate. After the Akira attack on Tietoevry’s Swedish data centre in January 2024, restoration ran for weeks while universities and government agencies fell back on manual payroll routines. Detection ends an incident’s secret phase. Recovery is what the business actually feels.
Real-World Cases
Four incidents show what MTTD and MTTR look like when they go wrong, and once when recovery went right.
Equifax, 76 Days Blind
In 2017 attackers reached Equifax through an unpatched flaw in Apache Struts and then sat inside for about 76 days without being seen (GAO, 2018).
Equifax had a tool that inspected encrypted traffic for exactly this kind of theft. Its digital certificate had expired about 10 months earlier, so the tool had quietly stopped inspecting anything. The moment staff renewed the certificate on 29 July 2017, the intrusion showed up at once. By then the data of about 145.5 million people was gone.
A detection tool that silently stops working turns MTTD into never. The lesson is to monitor the health of your monitoring, so a dead certificate raises an alarm long before an attacker does.
Target, the Alerts Nobody Answered
Target’s 2013 breach is the opposite failure. Its detection system worked. During the intrusion it fired several malware alerts, each flagged as high priority (US Senate, 2014).
No one acted on them. Target learned it had been breached about two weeks later, from the US Department of Justice, after roughly 40 million payment cards and the personal data of up to 70 million customers had already been taken.
Fast detection bought nothing because the response never started. Alerts only help when a team is staffed and empowered to triage them around the clock, with automatic containment ready for the clearest cases.
Maersk, Ten Days to Rebuild
Not every story is a failure. In June 2017 theNotPetya malware tore through Maersk, then the world’s largest container shipper NotPetya was built to destroy, not to extort, so paying would have restored nothing.
Maersk reinstalled about 4,000 servers, 45,000 PCs and 2,500 applications in roughly 10 days, a rebuild its chairman said would normally take six months (World Economic Forum, 2018). The company kept most cargo moving by hand while it worked. The damage still reached 250 to 300 million dollars.
What saved them was partly luck. One domain controller in Ghana survived on a power cut and held the only clean copy of the directory. Resilience you can count on is engineered, through tested offline backups and a recovery plan you have actually rehearsed.
Miljödata, a Swedish Supply-Chain Lesson
The most recent warning is close to home. On Saturday 23 August 2025 Miljödata, an HR systems supplier used by about 80% of Swedish municipalities, detected an intrusion. The attack disrupted services across roughly 200 of Sweden’s 290 municipalities.
Sweden’s data protection authority, IMY, later found the supplier had no automated real-time intrusion monitoring in place and issued a 1.8 million kronor fine (IMY, 2026).
Here the regulator named the missing control directly. Continuous monitoring across your own systems and your suppliers is what keeps MTTD from stretching into days, and it is increasingly what the law expects.
MTTD, MTTR and Compliance
In Sweden the law now puts a clock on response, which means it also puts a clock on detection. You cannot report in hours what you only detect in weeks.
Cybersäkerhetslagen (SFS 2025:1506), in force since 15 January 2026, transposes the EU NIS2 directive. It sets a reporting cascade to MCF (formerly MSB) and your sector authority. An early warning is due within 24 hours, a full notification within 72 hours and a final report within one month.
Those windows are detection deadlines in disguise. The 24-hour clock starts when you become aware of a significant incident, so a team that detects fast has hours to prepare while a team that detects slowly has already missed the first deadline.
The duty does not stop at reporting. Article 21 requires continuous monitoring and incident handling, and Article 20 makes the board responsible for overseeing security, with supervisory authorities able to hold members personally accountable. MTTD and MTTR are the numbers that show whether those duties are being met.
Other regimes add their own clocks. GDPR compliance requires notifying IMY of a personal-data breach within 72 hours under Article 33, and DORA compliance sets ICT incident-management duties for financial entities supervised by Finansinspektionen. For the full picture of the Swedish regime see our guide to NIS2 in Sweden.
What Good MTTD and MTTR Look Like
There is no single target that fits every organisation, but public frontline data gives you a frame.
The average breach in 2025 still took 181 days to detect (IBM, 2025), and the median time to fully remediate a known-exploited
critical vulnerability, one listed in CISA’s Known Exploited Vulnerabilities catalogue, was 43 days, up from 32 the year before (Verizon DBIR, 2026). Most organisations are slower than they think.
At the operational level the goal is different. A tuned detection pipeline flags a serious alert in minutes and a staffed team begins response within the hour. A benchmark earns its keep by telling you whether you are measured in minutes, hours or weeks, so you can move in the right direction.
One honest caveat. A speed metric is easy to game and easy to misread.
- Use medians, not averages: one 90-day incident can drag a mean far from the typical case.
- Segment by severity: a fast MTTR across trivial tickets hides a slow one on the incidents that matter.
- Pair speed with quality: closing alerts quickly looks good until you count the ones reopened or missed.
A low MTTR that only means you shut tickets fast is a vanity metric. Speed is worth measuring only alongside whether the response was actually right.
How to Reduce MTTD and MTTR
Cutting these numbers is a mix of people, process and technology, and no single tool does it on its own.
- Centralise your logs and monitor them continuously. A SIEM or an equivalent gives detection something to see, the thing Equifax’s expired certificate took away.
- Staff triage around the clock, or buy it. Alerts only cut MTTR if someone acts on them day and night, through an in-house team or managed detection and response.
- Automate the first response. Let clear-cut detections isolate a host or disable an account on their own, so containment does not wait for a human.
- Define which MTTR you mean, and track the whole lifecycle. Measure detection, response and recovery separately, by severity, using medians.
- Test that detection actually works. Run regular exercises and alert on the health of your tooling, so a silent failure surfaces fast.
- Keep tested, offline backups and rehearse recovery. Mean time to recover is short only when the restore has been practised, not just planned.
- Patch your exposed edge fast. The internet-facing devices attackers hit first are the ones to fix on the shortest clock.
Start by writing down your current numbers. You cannot improve a detection and response time you have never measured, and the first honest baseline is usually the most useful number you will produce all year.
