MTTD vs MTTR vs MTTC vs Dwell Time: Cybersecurity Metrics Compared
Cybersecurity teams often use MTTD, MTTR, MTTC and dwell time to measure how quickly threats are discovered and handled.
The four metrics are related, but they are not interchangeable.
A security team might detect an attack quickly but take too long to contain it. Another organization might respond quickly once an incident is confirmed but fail to notice attackers for days. A third organization may contain an incident within minutes while taking hours or days to restore normal business operations.
That is why no single time-based metric provides a complete picture of incident-response performance.
A useful simplified sequence is:
Attacker activity → Detection → Validation → Response → Containment → Eradication → Recovery
Different metrics describe different portions of that timeline.
NIST’s current SP 800-61 Rev. 3 integrates incident response into the NIST Cybersecurity Framework 2.0 and emphasizes improving the effectiveness and efficiency of incident detection, response and recovery rather than reducing incident management to one metric. NIST finalized Rev. 3 in April 2025, replacing Rev. 2.
MTTD vs MTTR vs MTTC vs Dwell Time at a Glance
| Metric | Main question | Typical measurement concept |
|---|---|---|
| MTTD | How quickly did we detect the threat? | Defined malicious-activity start → detection |
| MTTR | How quickly did we respond? | Defined response trigger → defined response action |
| MTTC | How quickly did we stop further harm? | Alert/validation → effective containment |
| Dwell Time | How long was the attacker present before discovery? | Initial compromise/activity → discovery/detection |
| Recovery Time | How quickly did operations return safely? | Incident/containment → trusted restoration |
The table is deliberately conceptual because the exact start and end points should be documented by each organization.
Table of Contents
Why Definitions Matter
The biggest problem with cybersecurity time metrics is usually not the mathematics.
It is inconsistent terminology.
Suppose one company reports:
MTTR = 35 minutes
and another reports:
MTTR = 14 hours
That comparison means almost nothing unless both companies define:
what starts the clock
and
what stops the clock.
One company may mean:
alert → first response
while another means:
incident → full business recovery.
Both may use the acronym MTTR.
This is why a mature cybersecurity metrics program should publish a small internal data dictionary containing the definition of every time metric.
AWS’s current Security Incident Response Guide provides a good illustration. It separately defines mean time to respond, mean time to contain, and mean time to recover, rather than treating them as one measurement.
What Is Mean Time to Detect (MTTD)?
Mean Time to Detect (MTTD) measures the average amount of time required to detect security incidents according to a consistently defined starting point.
A simple formula is:
MTTD = Total Detection Time ÷ Number of Incidents
Consider three incidents:
| Incident | Activity begins | Detected | Detection interval |
|---|---|---|---|
| A | 08:00 | 08:20 | 20 min |
| B | 10:00 | 11:30 | 90 min |
| C | 14:00 | 14:10 | 10 min |
Total:
120 minutes
Incidents:
3
Therefore:
MTTD = 40 minutes
The arithmetic is straightforward.
The difficult part is deciding what “activity begins” means.
It might mean:
- estimated initial compromise;
- first confirmed malicious action;
- first technically observable malicious activity.
Use one definition consistently.
For the full calculation and measurement methodology, see Mean Time to Detect (MTTD).
What MTTD Actually Tells You
MTTD primarily helps answer questions about detection capability.
A high MTTD may point to gaps in:
- logging;
- telemetry;
- detection engineering;
- identity monitoring;
- cloud visibility;
- alert correlation;
- analyst workflows.
But a low MTTD does not necessarily mean the incident-response program is mature.
You could detect malware in five minutes and still allow it to spread for another three hours.
That is why MTTC and response metrics matter too.
What Is Mean Time to Respond (MTTR)?
For this site, we use MTTR to mean Mean Time to Respond.
That definition must be stated because MTTR is ambiguous.
Elsewhere in technology, MTTR may mean:
Mean Time to Repair, Mean Time to Recover, or Mean Time to Remediate.
AWS defines mean time to respond as the average time from the initial alert or discovery of a possible security incident until the first responsive actions are taken.
A basic calculation is:
MTTR = Total Response Time ÷ Number of Incidents
Suppose your organization defines response as:
incident validation → first approved containment action
and three incidents took:
15 minutes + 25 minutes + 50 minutes = 90 minutes
Then:
MTTR = 90 ÷ 3 = 30 minutes
The metric is meaningful only because the organization defined the interval first.
See Mean Time to Respond in Cybersecurity for the full methodology.
Why MTTR Is the Most Confusing Metric
Consider these four phrases:
Mean Time to Respond
Mean Time to Repair
Mean Time to Remediate
Mean Time to Recover
All may appear as MTTR.
They measure different things.
For SEO and reader clarity, Cybersecurity Time should therefore avoid writing:
MTTR measures recovery time.
Instead use:
In this guide, MTTR means Mean Time to Respond. Other organizations may use MTTR differently, so always verify the definition.
This creates consistency across your MTTD, MTTR and MTTC article cluster.
What Is Mean Time to Contain (MTTC)?
Mean Time to Contain (MTTC) measures how long an organization takes to effectively limit additional damage from an incident.
AWS defines mean time to contain as the average time between the initial alert or discovery of a possible security incident and completion of responsive actions that effectively prevent attackers or compromised systems from causing further harm.
Your organization may instead choose incident validation as the starting point.
The key is to document that choice.
A basic formula is:
MTTC = Total Containment Time ÷ Number of Incidents
Example:
| Incident | Confirmed | Effectively contained | MTTC interval |
|---|---|---|---|
| A | 09:00 | 09:15 | 15 min |
| B | 11:00 | 11:40 | 40 min |
| C | 15:00 | 15:20 | 20 min |
Total:
75 minutes
Therefore:
MTTC = 75 ÷ 3 = 25 minutes
See Mean Time to Contain (MTTC) for the detailed containment guide.
What Does “Contained” Mean?
Containment should mean the attacker’s ability to continue causing immediate harm has been effectively restricted.
For an endpoint incident, that might mean:
endpoint isolated + malicious communications blocked
For an account takeover:
account secured + sessions revoked + unauthorized tokens removed
For cloud compromise:
access removed + keys rotated + malicious persistence disabled
For ransomware:
affected systems isolated + compromised identities disabled + lateral movement stopped
This distinction matters because taking one action does not necessarily contain the whole incident.
For example:
09:10 — infected laptop isolated
but:
09:25 — attacker still has a stolen cloud-admin session
The endpoint is contained.
The incident is not.
What Is Dwell Time?
Dwell time describes the period during which a threat actor remains present in an environment before the compromise is discovered or detected.
A simplified representation is:
Dwell Time = Discovery Time − Initial Compromise Time
However, research organizations may define and calculate dwell time somewhat differently, so methodology matters.
Mandiant’s M-Trends 2026 reports that global median dwell time across its 2025 investigations increased to 14 days, compared with 11 days in the preceding reporting period. Mandiant attributes much of the increase to long-running espionage activity and North Korean IT-worker operations.
Mandiant also found that organizations first discovered malicious activity internally in 52% of its 2025 investigations, compared with 43% in the prior year.
Those are useful threat-research statistics.
They are not universal MTTD benchmarks.
MTTD vs Dwell Time: Why They Are Not Identical
MTTD and dwell time may look similar.
Both involve the period before detection.
But their intended use differs.
MTTD is generally an internal operational average across multiple incidents.
Dwell time usually describes attacker presence in an individual intrusion or summarizes such durations across an incident-response research dataset.
For example:
Your SOC could report:
Quarterly MTTD = 25 minutes
while an external incident-response firm reports:
Median dwell time across investigations = 14 days
Those two figures should not be compared directly.
For a deeper explanation, see Dwell Time Cybersecurity.
Direct Comparison: MTTD vs MTTR vs MTTC vs Dwell Time
| Metric | Primary purpose | Example start | Example end | What poor performance may indicate |
|---|---|---|---|---|
| MTTD | Detection efficiency | Malicious activity | Detection | Visibility/detection gaps |
| MTTR | Response efficiency | Validation | Response action | Slow triage or escalation |
| MTTC | Containment efficiency | Validation | Effective containment | Slow authority/tools/process |
| Dwell Time | Exposure duration | Initial compromise | Discovery | Attacker remained hidden |
| Recovery Time | Operational restoration | Containment | Trusted restoration | Weak resilience/recovery |
This table should replace the oversimplified comparison on your existing page.
A Better Incident Response Timeline
Instead of:
MTTD → MTTC → MTTR → Dwell Time
use this:
Initial compromise
↓
Undetected attacker activity
← Dwell Time →
↓
Detection
← MTTD ends →
↓
Acknowledgement
↓
Incident validation
↓
Response action
← Mean Time to Respond milestone →
↓
Effective containment
← MTTC milestone →
↓
Eradication
↓
Recovery
This is much more technically defensible.
MTTD Does Not Automatically Equal Dwell Time
Consider this example.
Monday 01:00 — attacker initially compromises VPN.
Monday 08:00 — suspicious authentication event becomes visible in monitoring.
Monday 08:05 — SIEM triggers an alert.
Monday 08:12 — analyst investigates.
Monday 08:25 — incident confirmed.
Different teams might measure:
Attacker dwell time: approximately 7 hours before discovery.
Detection-system latency: 5 minutes from observable event to alert.
Analyst acknowledgement time: 7 minutes.
Validation time: 13 minutes.
One number cannot explain this incident.
Why Mean Alone Can Mislead
Suppose containment times are:
8, 10, 12, 14, 180 minutes
The arithmetic mean is:
44.8 minutes
But the median is:
12 minutes
Most incidents are contained relatively quickly, while one incident took three hours.
Both facts matter.
That is why mature teams should consider:
mean + median + P90/P95 + maximum
rather than reporting only mean values.
Cybersecurity Time Metrics Dashboard
A useful SOC dashboard might look like:
| Metric | Current | Previous quarter | Direction |
|---|---|---|---|
| Median MTTD | 17 min | 24 min | Improving |
| Mean MTTD | 29 min | 37 min | Improving |
| P90 MTTD | 2.1 hrs | 3.4 hrs | Improving |
| MTTA | 5 min | 7 min | Improving |
| Median MTTC | 21 min | 29 min | Improving |
| P90 MTTC | 1.7 hrs | 2.8 hrs | Improving |
| Recovery time | 7.5 hrs | 9.1 hrs | Improving |
| Externally discovered incidents | 12% | 17% | Improving |
This creates a much stronger management picture than four isolated averages.
Measure by Incident Severity
A ransomware event and a low-risk endpoint alert should not necessarily share the same performance target.
A useful approach is to segment metrics by:
Critical
High
Medium
Low
For example:
| Severity | MTTD | MTTC |
|---|---|---|
| Critical | 8 min | 12 min |
| High | 18 min | 27 min |
| Medium | 44 min | 1.8 hrs |
| Low | 3 hrs | 6 hrs |
These values are illustrative, not industry standards.
There is no universal MTTD, MTTC or MTTR target that fits every organization.
Measure by Incident Type
Another useful segmentation is attack type.
| Incident | MTTD | MTTC |
|---|---|---|
| Ransomware | 9 min | 14 min |
| Identity compromise | 20 min | 18 min |
| Cloud account takeover | 38 min | 41 min |
| Data exfiltration | 55 min | 48 min |
| Third-party incident | 5.2 hrs | 3.6 hrs |
This could reveal that your biggest problem is not endpoint security.
It may be:
cloud visibility
or:
supplier notification delay.
Detection Source Matters
Mandiant’s 2026 data illustrates why discovery source deserves attention.
Across its 2025 investigations:
52% were first discovered internally.
34% involved notification from an external entity.
14% involved the adversary informing the organization.
For ransomware cases specifically, attacker notification remains more prominent because the attacker’s business model often requires making the victim aware of the compromise.
A useful internal metric is therefore:
percentage of serious incidents detected internally
versus:
percentage discovered by customers, suppliers, researchers, law enforcement or attackers.
The 2026 Threat Environment Compresses Response Time
Mandiant’s 2026 research shows two very different attacker patterns.
Some threat actors maintain stealthy access for extended periods.
Others move extraordinarily quickly: Mandiant reports cases where an initial-access partner hands control to another threat group in less than 30 seconds.
This creates a practical lesson:
Your incident-response process has to handle both:
slow, quiet compromise
and:
rapid attack escalation.
A single universal time target cannot describe both effectively.
NIST’s Current Incident Response Model
Your existing article links to the old NIST Rev. 2 page.
Replace it.
NIST finalized SP 800-61 Rev. 3 in April 2025. It specifically states that the scope differs significantly from earlier versions because incident-response practices change rapidly across technologies and environments.
Rev. 3 incorporates incident response throughout CSF 2.0’s six functions:
Govern
Identify
Protect
Detect
Respond
Recover
The key lesson for your metrics article is that detection, response, containment and recovery should be evaluated as parts of a broader risk-management capability—not as disconnected numbers.
ISO/IEC 27035 and Incident Response Metrics
The ISO/IEC 27035 series provides another useful incident-management reference.
ISO/IEC 27035-1:2023 establishes the overall incident-management principles and process, covering preparation, detection, reporting, assessment, response and lessons learned.
ISO/IEC 27035-3:2020 addresses operational incident response and explicitly covers detection, reporting, triage, analysis, response, containment, eradication and recovery.
This is more appropriate than the old ISO/IEC 27035-1:2016 link on your existing page, because that edition has been replaced by the 2023 version.
AWS Definitions Are Useful for Operational Measurement
AWS’s current Security Incident Response Guide gives particularly clear operational definitions.
It separates:
Mean time to respond — time to begin initial responsive action.
Mean time to contain — time until responsive actions effectively prevent additional harm.
Mean time to recover — time required to return to safe operations.
That distinction is useful because it prevents the common mistake of forcing the entire incident lifecycle under a single “MTTR” label.
AWS Security Incident Response Guide
How the Metrics Work Together
Consider a hypothetical account takeover.
| Event | Time |
|---|---|
| Credentials stolen | 08:00 |
| Suspicious login | 09:00 |
| SIEM alert | 09:02 |
| Analyst acknowledgement | 09:06 |
| Incident validated | 09:14 |
| Account disabled | 09:20 |
| Sessions revoked | 09:24 |
| Attacker access confirmed stopped | 09:28 |
| Normal account operation restored | 11:00 |
Depending on your definitions:
Dwell time: approximately 1 hour before discovery.
MTTD interval: based on your defined compromise/detection points.
MTTA: 4 minutes.
Validation interval: 8 minutes.
MTTC: 14 minutes from validation at 09:14 to effective containment at 09:28.
Recovery interval: substantially longer.
This tells the story of the incident much better than:
MTTR = 3 hours.
One Metric Can Be Good While Another Is Poor
Imagine:
MTTD: 8 minutes
MTTC: 4 hours
The organization detects attacks rapidly but struggles to stop them.
Possible causes include:
- approval delays;
- poor endpoint controls;
- identity containment gaps;
- business resistance to isolation.
Now consider:
MTTD: 3 days
MTTC: 10 minutes
The incident-response team moves quickly once the attacker is found, but detection visibility is weak.
The solutions are completely different.
This is why executives should never evaluate SOC maturity using one time metric alone.
Common Measurement Mistakes
The most common errors are using inconsistent start points, treating first containment action as full containment, confusing dwell time with MTTD, using MTTR without defining what “R” means, reporting only averages, combining Critical and Low-severity incidents into one unexplained metric, and comparing internal metrics directly with external threat-research statistics that use different methodologies.
The cure is straightforward:
define → measure → segment → compare over time → investigate outliers.
Build a Cybersecurity Metrics Dictionary
Before publishing dashboards internally, create definitions such as:
| Metric | Internal definition |
|---|---|
| MTTD | First confirmed malicious activity → detection |
| MTTA | Alert generated → analyst acknowledges |
| Validation Time | Analyst acknowledgement → incident confirmed |
| MTTR | Incident confirmed → first defined response action |
| MTTC | Incident confirmed → effective containment |
| Eradication Time | Containment → persistence/root cause removed |
| Recovery Time | Containment → trusted operations restored |
| Dwell Time | Initial compromise → discovery |
Then document:
time zone
data source
incident population
severity filters
calculation method
That makes quarter-over-quarter comparisons defensible.
Mean vs Median vs P90
A strong metrics program should answer three different questions.
Mean
What is our average performance across all incidents?
Median
What does the typical middle incident look like?
P90/P95
How bad are our slower incidents?
For executive decision-making, the P90 or P95 number can be particularly useful because major exposure often hides in the long tail.
Metrics Should Drive Investigation, Not Competition
An improving MTTC number does not necessarily prove security has improved.
Suppose the SOC’s containment time falls dramatically because analysts automatically isolate anything suspicious.
At the same time:
- false-positive containment doubles;
- production disruptions increase;
- users lose access unnecessarily.
The metric improved.
The security outcome may not have.
Cybersecurity metrics should therefore be interpreted alongside:
- false-positive rate;
- severity;
- operational impact;
- recurrence;
- customer impact.
MTTD, MTTR and MTTC Are Not Regulatory Clocks
This distinction is important for your compliance-focused site.
Operational metrics do not automatically determine legal reporting deadlines.
For example:
SEC Item 1.05 depends on materiality determination, not MTTD.
UK GDPR uses awareness of a reportable personal-data breach.
DORA uses its own incident-awareness and classification framework.
NIS2 uses its own significant-incident notification requirements.
MTTD and MTTC influence how quickly an organization can understand and manage an incident, but they are not substitutes for the legal trigger analysis.
For the regulatory comparison, see Cyber Incident Reporting Deadlines: US vs UK.
Metrics and the Incident Timeline
Every useful time metric requires reliable incident timestamps.
Your master incident record should capture events such as:
malicious activity identified
alert generated
alert acknowledged
incident validated
containment started
containment completed
eradication completed
service restored
For a reusable chronology structure, see Data Breach Timeline Template.
For the wider lifecycle, see Cybersecurity Incident Response Timeline.
Cybersecurity Time Incident Metrics Model
A useful measurement model is:
Threat activity
↓
Dwell / exposure period
↓
Detection — MTTD
↓
Acknowledgement — MTTA
↓
Validation
↓
Response — MTTR as defined
↓
Containment — MTTC
↓
Eradication
↓
Recovery
This model avoids treating response as one giant metric.
Which Metric Should a CISO Prioritize?
There is no single answer.
If attackers remain undetected for long periods:
Prioritize detection and dwell time.
If alerts are generated but analysts respond slowly:
Prioritize acknowledgement and response time.
If incidents are confirmed rapidly but spread continues:
Prioritize MTTC.
If systems remain unavailable long after containment:
Prioritize recovery time and resilience.
The correct metric is the one that identifies your actual bottleneck.
Questions Boards Should Ask
A board does not need raw SOC dashboards.
More useful questions include:
Are Critical incidents detected faster than last year?
What percentage of major incidents are discovered externally?
What is our P90 containment time?
Which systems have the poorest telemetry?
Do supplier incidents take longer to contain?
What causes the longest response delays?
Have recovery times improved?
These questions connect operational metrics to business risk.
Frequently Asked Questions
What is the difference between MTTD and MTTC?
MTTD measures detection speed.
MTTC measures the time required to effectively contain an incident according to the organization’s defined start and end points.
What does MTTR mean in cybersecurity?
It varies.
MTTR can mean Respond, Recover, Repair, or Remediate.
On Cybersecurity Time, we use Mean Time to Respond and state the definition explicitly.
AWS likewise distinguishes mean time to respond, mean time to contain and mean time to recover as separate measurements.
Is dwell time the same as MTTD?
No.
They overlap conceptually but are used differently.
MTTD is generally an internal average detection metric.
Dwell time usually describes how long an attacker remains in an environment before discovery.
What is a good MTTD?
There is no universal benchmark.
The appropriate target depends on:
- threat type;
- asset criticality;
- attack speed;
- telemetry;
- staffing.
What is a good MTTC?
There is also no universal benchmark.
Active ransomware or privileged account compromise may justify minute-level internal targets, while lower-risk events can have different requirements.
Should we use mean or median?
Ideally use both.
Also consider P90 or P95 to expose unusually slow incidents.
Why shouldn’t we compare our MTTD to Mandiant’s 14-day dwell time?
Because they are different measurements.
Mandiant’s 14-day figure is the global median dwell time in its 2025 investigation dataset, not a universal organizational MTTD benchmark.
Is NIST SP 800-61 Rev. 2 still current?
No.
NIST finalized SP 800-61 Rev. 3 on April 3, 2025, and Rev. 3 supersedes Rev. 2.
Final Takeaway
MTTD, MTTR, MTTC and dwell time measure different parts of the same security problem.
A useful model is:
Dwell/exposure → Detection → Response → Containment → Eradication → Recovery
MTTD asks:
How quickly did we detect it?
MTTR, when defined as Mean Time to Respond, asks:
How quickly did we begin meaningful defensive action?
MTTC asks:
How quickly did we actually stop further harm?
Dwell time asks:
How long was the adversary present before discovery?
No single metric provides the complete picture.
A mature security program therefore measures the transitions between stages, uses consistent definitions, reports averages alongside medians and percentiles, segments incidents by severity and type, and investigates the outliers.
NIST’s current incident-response guidance supports this broader perspective by integrating detection, response and recovery into organization-wide cybersecurity risk management rather than treating them as isolated SOC activities.
The most useful executive question is therefore not:
“Is our MTTR good?”
It is:
“Where in the attack-to-recovery timeline are we losing the most time, and what can we change to reduce that exposure?”
That is the question these metrics are supposed to help answer.
