What do MTTD, MTTA, MTTC and MTTR measure?
The four metrics split an incident's lifecycle into stages. Together they answer one question: how much time did the attacker have to act before you stopped them?
| Metric | Name | Starts | Ends |
|---|---|---|---|
| MTTD | Mean time to detect | Start of the malicious activity | First alert or detection |
| MTTA | Mean time to acknowledge | Alert generated | A person or system starts working on it |
| MTTC | Mean time to contain | Detection | Threat contained: machine isolated, account blocked or communication cut off |
| MTTR | Mean time to respond, remediate, resolve or recover | Detection | Response completed or service restored, depending on the definition |
The R in MTTR is ambiguous. For some it means response (investigating and acting), for others remediation (removing the cause) and for others recovery (returning to normal operations). All are valid, but two MTTR figures with different definitions cannot be compared. Write down yours and always use it the same way.
How are they calculated? Formulas and an example
All of them are averages of time differences across the incidents in a period, where n is the number of incidents (or alerts, in the case of MTTA):
- MTTD = Σ (detection time - start time) / n
- MTTA = Σ (acknowledgment time - alert time) / n
- MTTC = Σ (containment time - detection time) / n
- MTTR = Σ (resolution time - detection time) / n
| Incident | Start | Detection | Containment | Resolution |
|---|---|---|---|---|
| A: phishing with credential theft | Monday 9:00 a.m. | Monday 1:00 p.m. (4 h) | Monday 2:00 p.m. (1 h) | Tuesday 1:00 p.m. (24 h) |
| B: malware on a laptop | Wednesday 10:00 a.m. | Wednesday 10:30 a.m. (0.5 h) | Wednesday 10:45 a.m. (0.25 h) | Wednesday 4:30 p.m. (6 h) |
| C: remote access with a valid account | Friday 10:00 p.m. | Monday 8:00 a.m. (58 h) | Monday 9:00 a.m. (1 h) | Tuesday 8:00 a.m. (24 h) |
Result: MTTD = (4 + 0.5 + 58) / 3 ≈ 20.8 hours; MTTC = (1 + 0.25 + 1) / 3 = 0.75 hours (45 minutes); MTTR = (24 + 6 + 24) / 3 = 18 hours. The median time to detect is 4 hours: incident C, which started on a Friday night and went unnoticed until Monday, drives up the average. That is why it is worth publishing both the mean and the median, and analyzing after-hours incidents separately.
What is dwell time and how does it relate to MTTD?
Dwell time is the time an attacker spends inside the environment before being detected. It measures the same thing as MTTD, but it is usually published by incident response firms based on the cases they investigate, and normally as a median rather than a mean. According to Mandiant's M-Trends 2026 report, the global median was 14 days in its 2025 investigations, up from 11 days the previous year. Sophos's 2026 Active Adversary Report puts the median at 3 days across its incident response and MDR cases. The gap shows how much the figure depends on the sample: the type of client, attack and service.
Why does speed matter so much?
Sophos's data gives a sense of the margin. In its cases, once inside, attackers took a median of 3.4 hours to go after the Active Directory server. Data exfiltration happened just over three days (78.8 hours) after the start of the attack and only 1.87 hours before it was detected. An MTTC measured in hours can come too late if the attacker already controls the domain.
What drives up MTTD and MTTR?
- Sources not integrated: if you do not collect identity, email or cloud logs, attacks that go through those layers generate no alerts.
- Generic or outdated detections: rules that do not cover the techniques used against your industry.
- Noise: thousands of false positives leave real alerts waiting in the queue, and MTTA skyrockets.
- Manual triage: every alert requires checking several consoles to gather context.
- Office hours: anything that happens at night or on the weekend waits for the next shift.
- Slow approvals: nobody authorized to isolate a server at 3 a.m.
- Tools that detect but do not allow remote containment.
How do you reduce MTTD, MTTC and MTTR?
- Extend visibility to endpoint, identity, email, network and cloud. Prioritize identity: many attacks get in with valid credentials.
- Align detections with MITRE ATT&CK and review which techniques you really cover.
- Automate triage and enrichment so the analyst receives cases with context instead of raw alerts.
- Define containment playbooks with pre-approved actions by incident type and asset criticality.
- Guarantee 24/7 coverage with people authorized to contain, at night too.
- Do threat hunting to find what no rule detected, and turn every finding into a new detection.
- Review every incident: where time was lost and what change prevents it next time.
What mistakes are made when measuring?
- Excluding incidents detected by a third party: MTTD comes out artificially low.
- Confusing MTTR with ticket closure time.
- Using only the mean: a couple of extreme cases distort it.
- Mixing alerts and incidents: MTTA is measured on alerts; MTTD, MTTC and MTTR on confirmed incidents.
- Optimizing the metric instead of the outcome: closing alerts quickly without investigating them lowers MTTR and raises risk.
How Ciberia helps
Ciberia MDR acts on the stages where the most time is lost. It integrates with more than 600 sources (EDR/XDR, SIEM, firewall, email, identity and cloud), so it works on the telemetry you already have. Its AI agents automate about 90% of triage and deliver every case with context, and an analyst validates decisions with impact. For critical alerts, the contractual SLA is 15 minutes to initial containment, 24/7. With Threat Hunting, findings become new detection rules.
