Cybersecurity Benchmarks 2026: How to Measure MTTD, MTTC, MTTR and Dwell Time Correctly
Cybersecurity teams rely on benchmarks to answer an important question:
Are our detection and response capabilities improving fast enough to reduce business risk?
The problem is that cybersecurity benchmarks are often compared incorrectly.
One report may measure:
- Mean Time to Detect (MTTD);
- median dwell time;
- Mean Time to Contain (MTTC);
- Mean Time to Respond;
- Mean Time to Recover;
- breach identification;
- combined identification and containment.
Those are different measurements.
A 14-day median dwell time should not be compared directly with a 30-minute internal MTTD.
A 241-day breach identify-and-contain lifecycle should not be described as detection time.
And a company’s Mean Time to Respond should not be compared with another organization’s Mean Time to Recover simply because both use the acronym MTTR.
In 2026, the strongest benchmarking strategy is therefore not to search for one universal “good” number.
It is to:
define → measure → segment → compare → investigate → improve.
NIST’s current SP 800-61 Rev. 3, finalized in April 2025, integrates incident response into Cybersecurity Framework 2.0 and focuses on improving the efficiency and effectiveness of incident detection, response, and recovery. It supersedes SP 800-61 Rev. 2.
Cybersecurity Benchmarks 2026 at a Glance
| Metric | Main question | Best benchmarking approach |
|---|---|---|
| MTTD | How quickly do we detect incidents? | Mean + median + P90/P95 over time |
| MTTA | How quickly are alerts acknowledged? | Compare by severity and source |
| MTTC | How quickly is further harm effectively stopped? | Compare by attack type and criticality |
| MTTR — Respond | How quickly does meaningful response begin? | Explicitly define start/end points |
| Recovery Time | How quickly do operations return safely? | Compare with business recovery objectives |
| Dwell Time | How long was the attacker undiscovered? | Use median and long-tail analysis |
| Internal Discovery Rate | Do we find serious incidents ourselves? | Track trend by quarter |
| External Discovery Rate | How often do outsiders discover compromise first? | Investigate visibility gaps |
There is no authoritative universal table saying every mature SOC should achieve exactly the same numbers.
Table of Contents
Why Cybersecurity Benchmarks Matter
Benchmarks are valuable when they help teams identify:
- detection blind spots;
- analyst bottlenecks;
- containment delays;
- long-tail incidents;
- weak recovery processes;
- poor visibility;
- third-party dependencies.
They are much less useful when they become arbitrary targets.
For example:
MTTD = 40 minutes
is not automatically good or bad.
For a low-risk endpoint event, it may be acceptable.
For active ransomware encryption on a critical server, 40 minutes may represent a serious delay.
The metric needs context.
The Most Important Benchmarking Rule
Every time-based security metric should answer:
What starts the clock?
and:
What stops the clock?
Without those definitions, benchmarking becomes unreliable.
Example:
Organization A defines MTTR as:
incident confirmed → first response action
Organization B defines MTTR as:
incident discovered → business restored
Organization A reports:
MTTR = 18 minutes
Organization B reports:
MTTR = 15 hours
Those figures cannot be meaningfully compared.
AWS’s current incident-response guide explicitly separates mean time to respond, mean time to contain, and mean time to recover for this reason.
Benchmark 1: Mean Time to Detect (MTTD)
Mean Time to Detect measures the average detection interval across a defined group of security incidents.
A basic formula is:
MTTD = Total Detection Time ÷ Number of Incidents
Suppose four confirmed incidents took:
10 minutes
20 minutes
30 minutes
60 minutes
to detect.
Total:
120 minutes
Incidents:
4
Therefore:
MTTD = 30 minutes
The mathematics is simple.
The difficult question is:
When exactly did each detection interval begin?
Possible starting points include:
- estimated initial compromise;
- first confirmed malicious activity;
- first technically observable malicious event.
Your organization should choose one definition and document it.
For the full methodology:
Mean Time to Detect (MTTD) Guide
Is There a Universal 2026 MTTD Benchmark?
No reliable authoritative source establishes:
High maturity = 30 minutes to 4 hours
or:
Average enterprise = 6 to 24 hours
as universal 2026 standards.
Those figures in your current article should be removed.
The better benchmark is your own historical performance.
Example:
| Quarter | Median MTTD | Mean MTTD | P90 MTTD |
|---|---|---|---|
| Q1 | 38 min | 55 min | 5.2 hrs |
| Q2 | 29 min | 44 min | 3.7 hrs |
| Q3 | 21 min | 32 min | 2.3 hrs |
These numbers are illustrative.
What matters is that the methodology remains stable.
Benchmark MTTD by Severity
One enterprise-wide MTTD can hide important risk.
Consider:
| Severity | Illustrative MTTD |
|---|---|
| Critical | 8 min |
| High | 19 min |
| Medium | 47 min |
| Low | 3.1 hrs |
These are examples, not industry standards.
This segmentation tells leadership whether the most dangerous attacks are being detected fastest.
Benchmark MTTD by Environment
Also compare:
- endpoint;
- identity;
- cloud;
- SaaS;
- network;
- OT;
- edge infrastructure.
Example:
Endpoint MTTD: 14 min
Cloud identity MTTD: 49 min
Edge-device MTTD: 7.4 hrs
A single average could hide the edge-device weakness.
Mandiant’s 2026 findings specifically highlight long-lived compromises on edge systems that often lack standard telemetry.
Benchmark 2: Mean Time to Acknowledge (MTTA)
MTTA measures how long it takes an analyst or responder to acknowledge an alert.
Example:
Critical alert generated: 09:00
Analyst begins review: 09:07
Acknowledgement interval:
7 minutes
Track MTTA separately from MTTD.
A security tool may detect the attack immediately while the alert waits in a queue for an hour.
That is an operational problem, not a detection-engine problem.
Benchmark MTTA by Severity
A useful dashboard can compare:
| Severity | Median MTTA | P90 MTTA |
|---|---|---|
| Critical | 4 min | 9 min |
| High | 8 min | 21 min |
| Medium | 22 min | 55 min |
Again, these are illustrative.
Use internally approved response objectives.
Benchmark 3: Mean Time to Contain (MTTC)
Mean Time to Contain measures how quickly an organization effectively prevents an incident from causing additional harm.
AWS defines it as the average time between the initial alert or discovery and completion of responsive actions that effectively prevent an attacker or compromised systems from causing further harm.
An organization may instead choose:
confirmed incident → effective containment
The important thing is consistency.
Formula:
MTTC = Total Containment Time ÷ Number of Incidents
For detailed guidance:
Mean Time to Contain MTTC Guide
There Is No Universal MTTC Target
Your current:
Advanced teams: under four hours
Mid-tier: 8–24 hours
Low maturity: 1–3 days
table should be removed.
Containment depends heavily on incident type.
Consider:
Standard workstation malware
Isolation may happen quickly.
Cloud administrator compromise
Containment may require:
- account disablement;
- token revocation;
- key rotation;
- permission review.
Enterprise ransomware
Containment may involve:
- endpoints;
- identity;
- network segments;
- virtualization;
- backups;
- cloud accounts.
A single MTTC benchmark cannot accurately describe all three.
Partial Containment vs Effective Containment
This distinction is important.
Suppose:
10:00 — compromised laptop isolated
but:
10:15 — attacker still possesses an active cloud-admin session.
The endpoint is contained.
The incident is not.
AWS similarly distinguishes containment decisions based on whether containment is partial or full and emphasizes reversible, staged containment where appropriate.
Benchmark 4: Mean Time to Respond (MTTR)
For Cybersecurity Time, use MTTR to mean:
Mean Time to Respond
and say so every time the acronym is introduced.
AWS defines mean time to respond as the average interval from initial alert or discovery until the first responsive actions are taken.
A simplified formula is:
MTTR = Total Response Time ÷ Number of Incidents
Example:
Alert validated: 10:00
First response action: 10:12
Response interval:
12 minutes
Across multiple incidents, average those intervals.
For the dedicated guide:
Why MTTR Is Dangerous Without a Definition
MTTR can also mean:
- Mean Time to Repair;
- Mean Time to Recover;
- Mean Time to Remediate.
Those are not interchangeable.
Do not write:
MTTR measures complete remediation and system restoration.
unless you explicitly define MTTR as Mean Time to Recover.
For this site, we have standardized MTTR as:
Mean Time to Respond.
Use Recovery Time separately.
Benchmark 5: Recovery Time
Recovery should measure how long it takes the organization to return affected operations to a safe and trusted state.
AWS defines mean time to recover separately from response and containment as the average time from alert/discovery until business operations safely return to normal.
Examples of recovery activities include:
- clean system rebuild;
- backup restoration;
- identity validation;
- service restoration;
- enhanced monitoring.
A board may compare recovery performance against:
- RTO;
- business impact analysis;
- service criticality.
This is much more meaningful than a generic:
Mature programs recover in 1–3 days.
Benchmark 6: Dwell Time
Dwell time generally measures how long an attacker remains present before discovery.
This is where current authoritative external data becomes useful.
Mandiant’s M-Trends 2026 reports:
14 days — global median dwell time
up from:
11 days in the prior reporting period.
Mandiant states that its 2026 figures are based on investigations conducted between January 1 and December 31, 2025.
That is a real benchmark.
But it must be labeled correctly.
It is:
global median dwell time in Mandiant’s investigation dataset
It is not:
- global average MTTD;
- universal enterprise benchmark;
- target every organization should try to meet.
Why “Global Average Dwell Time 10–16 Days” Should Be Removed
Your current article provides:
Global average: 10–16 days
That is weaker than the real current statistic.
Replace it with:
Mandiant M-Trends 2026 reported a 14-day global median dwell time across its 2025 investigations.
Mandiant also found that cyber-espionage and DPRK IT-worker incidents each had a 122-day median dwell time, showing why attack type dramatically changes the picture.
Long-Tail Dwell Time Matters
Some compromises remain hidden much longer.
Mandiant reports certain threat actors achieving persistence beyond one year; it also discusses BRICKSTORM-related investigations with very long dwell time, illustrating why short log-retention policies can make historical reconstruction difficult.
That means organizations should track:
- median dwell time;
- P90/P95;
- maximum;
- attack type;
- environment.
Benchmark 7: Internal Discovery Rate
One of the strongest current operational benchmarks is:
Who discovered the intrusion?
Mandiant reports that across its 2025 investigations:
52% were first detected internally.
34% were disclosed by an external entity.
14% were revealed by the adversary.
This can inspire a useful internal KPI:
Percentage of High/Critical incidents first discovered internally
Why Discovery Source Matters
An incident found by your SOC says something different from one reported by:
- customer;
- supplier;
- threat actor;
- law enforcement;
- researcher.
Suppose:
Q1 internal discovery = 61%
Q2 = 72%
Q3 = 81%
That trend may indicate better visibility.
But external benchmark numbers should be treated as context, not mandatory targets.
Mandiant 2026 Also Shows Why One Speed Benchmark Fails
At one end of the spectrum, Mandiant reports 14-day global median dwell time and much longer stealthy compromises.
At the other end, the median time between opportunistic initial access and hand-off to a secondary threat group fell to just 22 seconds in its 2025 observations.
That tells us something important:
modern defenders must be prepared for both slow stealth and machine-speed escalation.
There is no single detection-time target appropriate for every attack.
Benchmark 8: Ransomware Context
Verizon’s 2026 DBIR reports that ransomware was involved in 48% of breaches in its dataset, up from 44% in the previous year’s dataset.
That does not provide a universal ransomware MTTC.
Instead, it supports prioritizing ransomware metrics such as:
- ransomware MTTD;
- identity containment time;
- network containment;
- backup protection time;
- business recovery time.
For your dedicated guide:
Ransomware Containment Time 2026
Benchmark 9: Third-Party Exposure
Verizon’s 2026 DBIR reports that breaches involving third parties increased 60% from the prior year’s dataset, reaching 48% of total breaches in the 2026 dataset.
This suggests organizations should measure:
- vendor notification time;
- supplier incident validation;
- third-party containment time;
- external discovery source;
- critical supplier exposure.
A SOC might perform very well internally while still having a serious third-party response bottleneck.
Benchmark 10: Vulnerability Exploitation
Verizon’s 2026 DBIR reports that 31% of breaches began with exploitation of software vulnerabilities, overtaking stolen credentials as the leading initial-access route in its dataset.
This supports tracking:
- time from critical vulnerability identification to remediation;
- internet-facing vulnerability exposure;
- CISA KEV remediation;
- exploited vulnerability detection;
- asset visibility.
Again, this is more useful than a generic “maturity score.”
What IBM 2026 Can and Cannot Benchmark
IBM’s Cost of a Data Breach Report 2026 provides valuable financial context.
IBM reports:
$4.99 million — global average breach cost.
56% — increase in AI-driven attacks.
$1.93 million — average cost savings associated with extensive use of AI and automation in security compared with organizations using none.
Those are useful benchmarks.
They are not direct MTTD, MTTC, MTTR, or dwell-time benchmarks.
Do not transform IBM cost figures into unsupported claims such as:
“AI reduces MTTC by 50%.”
unless IBM actually measured that specific metric.
Security Automation Is a Capability, Not a Benchmark
Automation can help:
- enrich alerts;
- correlate events;
- isolate endpoints;
- revoke sessions;
- execute playbooks.
IBM’s cost data indicates meaningful economic benefit associated with extensive AI/security automation.
But a better operational benchmark is:
Did automation improve our actual response metrics?
Measure:
- triage time before/after;
- MTTA before/after;
- MTTC before/after;
- false containment;
- analyst overrides.
For the detailed workflow:
AI and Incident Response Automation
Mean vs Median: One of the Biggest Benchmarking Mistakes
Suppose five detection intervals are:
10 minutes
15 minutes
20 minutes
30 minutes
10 days
The mean becomes heavily affected by the long incident.
The median remains:
20 minutes
Neither number is inherently wrong.
They answer different questions.
A mature benchmark dashboard should include:
- mean;
- median;
- P90;
- P95;
- maximum.
Why P90 and P95 Matter
Consider:
Median MTTD = 15 minutes
That sounds strong.
But:
P95 MTTD = 14 hours
That tells leadership that a small set of incidents still remain invisible much longer.
Long-tail events may involve:
- cloud identities;
- edge devices;
- OT;
- suppliers;
- sophisticated attackers.
Those incidents often deserve more attention than the average.
Example 2026 Cybersecurity Benchmark Dashboard
A useful internal dashboard might look like:
| Metric | Current | Previous Quarter | Trend |
|---|---|---|---|
| Median MTTD | 18 min | 26 min | Improving |
| Mean MTTD | 29 min | 41 min | Improving |
| P90 MTTD | 2.1 hrs | 3.4 hrs | Improving |
| MTTA | 5 min | 7 min | Improving |
| Median MTTC | 24 min | 34 min | Improving |
| Mean Time to Respond | 12 min | 17 min | Improving |
| Internal discovery | 82% | 76% | Improving |
| Critical recovery time | 5.8 hrs | 7.2 hrs | Improving |
These are illustrative values.
Do not present them as global industry benchmarks.
Benchmark by Severity
A Critical incident should not necessarily have the same performance objective as a Low event.
Example:
| Severity | Detection target | Containment priority |
|---|---|---|
| Critical | Immediate escalation | Highest priority |
| High | Aggressive | High priority |
| Medium | Risk-based | Standard workflow |
| Low | Risk-based | Standard workflow |
Use internally approved objectives rather than invented global thresholds.
Benchmark by Attack Type
Track separately:
Ransomware
- MTTD;
- MTTC;
- backup impact;
- recovery.
Identity compromise
- suspicious-login detection;
- session revocation;
- privileged-account containment.
Cloud compromise
- IAM detection;
- token abuse;
- unauthorized API activity.
Third-party incidents
- supplier notification;
- validation delay;
- business exposure.
Edge-device intrusion
- discovery source;
- dwell time;
- logging coverage.
Different threats create different timelines.
Benchmark by Environment
One company-wide number can hide weak areas.
Segment:
Endpoint
Identity
Cloud
Network
SaaS
OT
Edge infrastructure
For example:
Endpoint MTTD improving; cloud MTTD unchanged; edge-device incidents still externally discovered.
That gives executives something actionable.
Internal Benchmark vs External Benchmark
Use internal benchmarks first.
Ask:
Are we better than last quarter?
Then use external research for context.
Internal benchmarking
Best for:
- MTTD;
- MTTC;
- MTTA;
- recovery;
- backlog;
- response.
External benchmarking
Best for:
- threat patterns;
- dwell-time context;
- breach cost;
- discovery patterns;
- industry risk.
External data should help explain your risk—not replace your own measurements.
Current External Benchmark Sources for 2026
Mandiant M-Trends 2026
Best for:
- median dwell time;
- discovery source;
- attacker pacing;
- edge-device persistence.
Mandiant’s data is grounded in more than 500,000 hours of frontline incident investigations performed in 2025.
Mandiant M-Trends 2026 Executive Edition
Verizon DBIR 2026
Best for:
- initial access;
- ransomware prevalence;
- third-party involvement;
- industry attack patterns.
Key current figures include:
31% software-vulnerability initial access
48% ransomware involvement
48% third-party involvement in the dataset.
Verizon 2026 Data Breach Investigations Report
IBM Cost of a Data Breach 2026
Best for:
- financial impact;
- AI-enabled attacks;
- AI/security-automation economics.
IBM Cost of a Data Breach Report 2026
IBM reports a record global average breach cost of $4.99 million in its 2026 study.
NIST SP 800-61 Rev. 3
Best for:
- incident-response framework;
- detection;
- response;
- recovery;
- governance.
Rev. 3 was finalized in April 2025 and superseded the older Rev. 2 guide.
AWS Security Incident Response Guide
Best for:
- clear operational definitions;
- response;
- containment;
- recovery.
AWS separately defines mean time to respond, mean time to contain, and mean time to recover, making it a useful reference when designing an internal metrics dictionary.
Create a Cybersecurity Metrics Dictionary
Before benchmarking, document definitions.
Example:
| Metric | Internal definition |
|---|---|
| MTTD | First confirmed malicious activity → detection |
| MTTA | Alert generated → analyst acknowledgement |
| Validation Time | Analyst review → confirmed incident |
| MTTR | Confirmed incident → first defined response action |
| MTTC | Confirmed incident → effective containment |
| Recovery Time | Containment → trusted business restoration |
| Dwell Time | Estimated initial compromise → discovery |
Also record:
- time zone;
- incident severity;
- data source;
- excluded events;
- calculation method.
Without these rules, quarterly comparisons can become inconsistent.
How to Improve Your Cybersecurity Benchmarks
1. Improve Asset Visibility
Unknown systems cannot be measured or protected reliably.
2. Improve Logging
Collect useful telemetry across:
- endpoint;
- identity;
- cloud;
- network;
- SaaS;
- edge infrastructure.
Mandiant’s 2026 findings emphasize how gaps in logging and telemetry can allow sophisticated intrusions to persist.
3. Improve Alert Routing
Reduce acknowledgement delays.
4. Automate Enrichment
Give analysts context sooner.
5. Predefine Containment Authority
Do not wait for emergency approval for every routine action.
6. Segment Metrics
Separate:
- Critical;
- High;
- ransomware;
- identity;
- cloud;
- third-party.
7. Measure Recovery Separately
Containment and recovery answer different questions.
8. Investigate the Long Tail
Look closely at P90/P95 incidents.
9. Track Discovery Source
Find out whether outsiders are discovering serious incidents before you.
10. Review Quarterly Trends
The direction is often more useful than a generic external benchmark.
What Executives Should Ask
Instead of:
Are we better than the industry average?
ask:
- Are Critical incidents detected faster?
- What is our P95 detection time?
- Which attack types have the longest dwell time?
- What percentage of serious incidents do we discover ourselves?
- Which systems have the weakest telemetry?
- Where is containment delayed?
- Are recovery times within business tolerance?
- Are supplier incidents slower than internally controlled incidents?
- What caused our slowest incident this quarter?
These questions produce useful management decisions.
Common Cybersecurity Benchmarking Mistakes
1. Inventing Universal Performance Ranges
Do not publish unsupported hour/day bands as 2026 standards.
2. Comparing Mean and Median
Always state the statistical method.
3. Calling Dwell Time MTTD
They are related but different.
4. Using MTTR Without Defining “R”
State Respond, Recover, Repair, or Remediate.
5. Comparing Different Incident Types
Ransomware and low-risk phishing should not share one benchmark blindly.
6. Treating External Reports as Internal Targets
Threat research is context, not necessarily an SLA.
7. Ignoring Long-Tail Incidents
Mean performance can hide severe outliers.
8. Ignoring Third Parties
Supplier dependencies can dominate response time.
9. Benchmarking Tools Instead of Outcomes
Buying more tools does not automatically improve MTTD.
10. Optimizing Metrics Instead of Risk
A beautiful dashboard does not equal stronger security.
Frequently Asked Questions
What is a good MTTD in 2026?
There is no universal MTTD that applies to every organization.
Set risk-based internal targets based on:
- severity;
- attack type;
- system criticality;
- telemetry coverage.
Then monitor mean, median, and P90/P95 trends.
Is 30 minutes to four hours an industry-standard MTTD?
I could not verify that range as an authoritative universal 2026 industry standard.
I recommend removing it from the existing article.
What is a good MTTC?
There is no universal MTTC benchmark either.
Containment expectations depend on the attack type, architecture, business impact, and required response actions.
What does MTTR mean?
It is ambiguous.
AWS distinguishes Mean Time to Respond from Mean Time to Recover.
On Cybersecurity Time, use:
MTTR = Mean Time to Respond
and label recovery separately.
What is the current global dwell-time benchmark?
Mandiant M-Trends 2026 reports a 14-day global median dwell time across its 2025 investigations.
It is not a universal MTTD target.
Are top organizations under five days of dwell time?
I could not verify a primary 2026 source supporting “under five days” as a universal top-performing benchmark.
Remove that claim unless you have a specific dataset supporting it.
Are high-risk industries above 20 days?
There is no authoritative universal 2026 rule stating that all “high-risk industries” have dwell time above 20 days.
Sector and attack-type variation is substantial.
What percentage of incidents are detected internally?
Mandiant reports 52% internal discovery across its 2025 investigation dataset.
That is dataset-specific, not a universal organizational target.
How common is ransomware in current breach data?
Verizon’s 2026 DBIR reports ransomware involvement in 48% of breaches in its dataset.
Why should we track third-party response performance?
Verizon’s 2026 DBIR reports third-party involvement in 48% of breaches in its dataset, up substantially from the prior year.
That makes supplier notification and response delay increasingly relevant.
Final Takeaway
The most important lesson from cybersecurity benchmarks in 2026 is that there is no single universal table defining:
good MTTD
good MTTC
good MTTR
or:
good dwell time.
Your current fixed maturity ranges should therefore be removed.
Instead, organizations should establish consistent internal definitions and track:
MTTD
MTTA
MTTC
Mean Time to Respond
Recovery Time
Dwell Time
Internal Discovery Rate
across:
mean + median + P90/P95 + severity + attack type + environment.
External studies then provide context.
Mandiant tells us the global median dwell time in its 2025 investigations was 14 days and that internal discovery reached 52%.
Verizon tells us that software vulnerability exploitation now accounts for 31% of breaches, while ransomware and third-party involvement each appear in 48% of the 2026 DBIR breach dataset.
IBM shows that the average breach in its 2026 study costs $4.99 million, while extensive AI/security automation is associated with $1.93 million lower breach costs than environments using none.
NIST provides the most important governance principle: incident detection, response, and recovery should be integrated into cybersecurity risk management rather than optimized as isolated statistics.
The right executive question is therefore not:
“Are we inside the industry benchmark?”
It is:
“Are our highest-risk incidents being detected, contained, and recovered from faster than before—and where is the remaining delay creating unacceptable business risk?”
Recommended Links
MTTD vs MTTR vs MTTC vs Dwell Time
