Mean Time to Contain (MTTC) in Cybersecurity: Formula, Benchmarks and How to Reduce It
Mean Time to Contain (MTTC) is a cybersecurity operations metric used to measure how quickly an organization limits the spread or further impact of a confirmed security incident.
Detection tells you that something is wrong.
Containment answers the next question:
How quickly can we stop the attacker from causing additional harm?
Depending on the incident, containment may involve:
- isolating an endpoint;
- disabling a compromised account;
- revoking active sessions;
- removing malicious OAuth access;
- blocking attacker infrastructure;
- restricting network communication;
- segmenting affected systems;
- disabling compromised integrations.
MTTC is useful because detecting an attacker quickly does not automatically mean the incident is under control.
An organization can have an excellent Mean Time to Detect and still suffer serious damage if containment takes hours.
NIST’s current incident-response guidance, SP 800-61 Rev. 3, emphasizes improving the efficiency and effectiveness of incident detection, response, and recovery as part of broader cybersecurity risk management.
The practical objective of MTTC is therefore:
reduce the time between confirming a meaningful incident and effectively limiting its ability to spread or cause additional impact.
MTTC at a Glance
| Metric | What it measures |
|---|---|
| MTTD | Malicious activity → detection |
| MTTA | Alert → analyst acknowledgement |
| Validation Time | Alert → confirmed incident |
| MTTC | Confirmed incident → effective containment |
| MTTR | Defined response start → defined response milestone |
| Eradication Time | Containment → attacker persistence/root cause removed |
| Recovery Time | Containment/remediation → trusted service restored |
| Dwell Time | Attacker presence before discovery/detection |
These are related but should not be treated as interchangeable.
Table of Contents
What Is Mean Time to Contain?
A practical MTTC definition is:
The average elapsed time between a defined incident-confirmation point and the point at which further spread or harm has been effectively limited.
The exact start and end points should be documented by the organization.
For example:
Start: incident confirmed as malicious
End: endpoint isolated + compromised sessions revoked
Another organization might use:
Start: severity classified as High/Critical
End: attacker access effectively blocked
Both can work if used consistently.
The measurement becomes unreliable when one incident uses:
detection → containment
and another uses:
alert acknowledgement → recovery
Consistency matters more than the label.
MTTC Formula
The basic formula is:
MTTC = Total Containment Time ÷ Number of Incidents
Suppose four confirmed incidents require the following time to containment:
| Incident | Confirmed | Contained | Interval |
|---|---|---|---|
| A | 09:00 | 09:20 | 20 min |
| B | 10:00 | 10:45 | 45 min |
| C | 13:00 | 13:15 | 15 min |
| D | 16:00 | 16:40 | 40 min |
Total containment time:
20 + 45 + 15 + 40 = 120 minutes
Number of incidents:
4
Therefore:
MTTC = 120 ÷ 4 = 30 minutes
The organization’s MTTC for this dataset is:
30 minutes
Define “Contained” Before Measuring MTTC
This is one of the most important parts of the metric.
Containment should represent a meaningful reduction in attacker capability.
For example:
Endpoint malware
Contained when:
- device is isolated;
- malicious outbound communication is blocked.
Account takeover
Contained when:
- account is disabled or secured;
- active sessions/tokens are revoked;
- attacker can no longer authenticate.
Cloud compromise
Contained when:
- unauthorized identities are disabled;
- malicious tokens are revoked;
- compromised API keys are rotated;
- attacker access is blocked.
Ransomware
Contained when:
- affected endpoints are isolated;
- lateral movement is stopped;
- compromised identity paths are disabled.
Simply clicking “isolate” is not enough if the attacker still controls another identity or host.
Partial Containment vs Effective Containment
A useful improvement is to distinguish:
partial containment
from:
effective containment.
Example:
10:00 — Infected laptop isolated.
But investigators later discover:
10:25 — Same attacker has active cloud-admin session.
The laptop was contained.
The incident was not.
A mature MTTC metric should generally stop when the organization has reasonable confidence that the incident’s ability to continue spreading or causing immediate harm has been significantly limited.
Cybersecurity Time Containment Timeline
| Event | Time |
|---|---|
| High-severity alert | 09:00 |
| Analyst acknowledgement | 09:05 |
| Malicious activity confirmed | 09:14 |
| Incident declared | 09:18 |
| Endpoint isolation | 09:24 |
| Compromised user disabled | 09:28 |
| Active sessions revoked | 09:31 |
| Malicious IP blocked | 09:34 |
| Effective containment declared | 09:38 |
If the organization’s MTTC starts at confirmation:
09:14 → 09:38 = 24 minutes
This provides far more operational value than simply saying:
“Incident handled in under one hour.”
Why MTTC Matters
Once attackers gain access, they may attempt to:
- escalate privileges;
- steal credentials;
- move laterally;
- access sensitive information;
- establish persistence;
- disable security tools;
- target backups;
- deploy ransomware.
Current Mandiant research illustrates both ends of the problem. M-Trends 2026 reports a global median dwell time of 14 days across Mandiant’s 2025 investigations, while some hand-offs between initial-access actors and secondary threat groups can occur in less than 30 seconds.
That does not create a universal MTTC benchmark.
It demonstrates why containment capability needs to support both:
- slow, stealthy intrusions;
- very fast-moving attacks.
MTTC vs MTTD
These metrics measure different problems.
MTTD
Answers:
How long did it take us to detect the threat?
Example:
Attack began 08:00 → detected 08:35
Detection interval:
35 minutes
MTTC
Answers:
How long did it take us to contain the incident after our chosen containment clock started?
Example:
Incident confirmed 08:45 → contained 09:05
Containment interval:
20 minutes
An organization can therefore have:
MTTD = 8 hours
MTTC = 10 minutes
That means detection was poor, but response after confirmation was fast.
Or:
MTTD = 5 minutes
MTTC = 3 hours
That means detection was excellent, but containment was slow.
For the full detection metric, see Mean Time to Detect.
MTTC vs MTTR
Your current article should be corrected here.
MTTR is not universally defined as “time to remediate and recover.”
Different organizations use MTTR to mean:
- Mean Time to Respond;
- Mean Time to Repair;
- Mean Time to Remediate;
- Mean Time to Recover.
On Cybersecurity Time, we recommend defining MTTR as Mean Time to Respond when using that term and stating the exact start and end points.
See Mean Time to Respond.
A cleaner measurement chain is:
MTTD → MTTA → Validation → MTTC → Eradication → Recovery
MTTC vs Dwell Time
Dwell time describes attacker presence before detection or discovery, depending on the research methodology.
MTTC concerns defensive containment after a defined response trigger.
Mandiant’s 2026 report found a global median dwell time of 14 days in its 2025 incident-response investigations. It also found that 52% of investigated organizations first detected evidence of malicious activity internally.
That figure should not be presented as an MTTC benchmark.
For the distinction, see Dwell Time Cybersecurity.
What Containment Means in Modern Incident Response
Containment is broader than endpoint isolation.
Modern attackers operate across:
- endpoints;
- identities;
- SaaS;
- cloud;
- networks;
- virtualization infrastructure;
- edge devices.
Mandiant’s 2026 findings specifically highlight attackers using edge devices and infrastructure that may lack standard endpoint telemetry.
Containment should therefore be attack-path aware.
Endpoint Containment
Possible actions:
- isolate endpoint through EDR;
- block network access;
- terminate malicious processes;
- quarantine files.
Identity Containment
Possible actions:
- disable account;
- reset password;
- revoke refresh tokens;
- invalidate sessions;
- remove unauthorized MFA methods;
- rotate privileged credentials.
Identity containment is especially important because changing only a password may not invalidate existing attacker sessions.
Cloud Containment
Possible actions:
- disable compromised IAM principal;
- rotate API keys;
- remove malicious OAuth consent;
- revoke tokens;
- restrict roles;
- apply conditional access;
- isolate compromised workloads.
Network Containment
Possible actions:
- firewall blocking;
- segment affected network;
- disable remote access;
- quarantine VLAN;
- isolate management interfaces.
Email Containment
Possible actions:
- quarantine malicious messages;
- block sender/domain;
- remove delivered messages;
- disable compromised mailbox rules;
- revoke sessions.
Ransomware Containment
Ransomware may require coordinated containment across:
- endpoints;
- identity;
- file shares;
- virtualization;
- backups;
- remote-management systems.
NIST published an updated Ransomware Risk Management: Cybersecurity Framework 2.0 Community Profile (IR 8374 Rev. 1) in June 2026, alongside its broader incident-response guidance.
Mean vs Median MTTC
Like MTTD and MTTR, MTTC should not always be reported using only an arithmetic mean.
Suppose five incidents have containment times:
8, 12, 14, 18, 240 minutes
Most incidents are contained quickly.
But one takes four hours.
The mean rises sharply because of that outlier.
That outlier matters, but leadership needs context.
Report:
- mean;
- median;
- P90;
- P95;
- maximum.
Example MTTC Dashboard
| Metric | Result |
|---|---|
| Mean MTTC | 38 min |
| Median MTTC | 21 min |
| P90 MTTC | 1.9 hrs |
| P95 MTTC | 3.7 hrs |
| Critical MTTC | 11 min |
| High MTTC | 27 min |
| Cloud incidents | 54 min |
| Third-party incidents | 3.1 hrs |
This tells leadership much more than:
MTTC = 38 minutes.
Measure MTTC by Severity
A mature SOC should distinguish severity.
Example internal targets:
| Severity | Illustrative target |
|---|---|
| Critical | <15 min |
| High | <30 min |
| Medium | <2 hrs |
| Low | <8 hrs |
These are illustrative internal targets, not universal standards.
Every organization should set targets based on:
- business criticality;
- attack speed;
- staffing;
- infrastructure;
- regulatory requirements;
- acceptable operational risk.
There Is No Universal “Good MTTC”
Your current article is correct on this point.
There is no credible universal rule such as:
Good MTTC = 30 minutes.
A hospital dealing with ransomware may need containment within minutes.
A low-risk malware event on an isolated test device may tolerate a longer interval.
A better question is:
Does containment speed match the risk and likely attack progression?
International Standards Relevant to Containment
Your current standards section needs updating.
NIST SP 800-61 Rev. 3
NIST finalized Rev. 3 in April 2025.
It supersedes Rev. 2 and integrates incident response into the six CSF 2.0 functions.
Use:
Do not continue linking to Rev. 2.
ISO/IEC 27035-1:2023
The current foundational ISO incident-management standard is ISO/IEC 27035-1:2023.
It covers a structured approach to:
- preparation;
- detection;
- reporting;
- assessment;
- response;
- lessons learned.
Use:
ISO/IEC 27035-2:2023
Part 2 focuses on planning and preparing for incident response, including:
- policies;
- management commitment;
- incident management plans;
- incident teams.
Use:
ISO/IEC 27035-3:2020
Part 3 addresses ICT incident response operations and explicitly includes:
- detection;
- reporting;
- triage;
- analysis;
- response;
- containment;
- eradication;
- recovery;
- conclusion.
Use:
This is a stronger ISO reference for the MTTC article than the withdrawn 2016 link currently on your page.
10 Practical Ways to Reduce MTTC
1. Predefine Containment Authority
One of the biggest causes of delay is:
“Who is allowed to isolate this system?”
Pre-authorize common actions for appropriately trained responders.
For example:
SOC may isolate employee endpoints without executive approval
while:
production database isolation requires incident commander + service owner approval
Document the difference.
2. Enable Rapid Endpoint Isolation
EDR platforms often provide rapid endpoint isolation.
Ensure responders:
- know how to use it;
- have appropriate permissions;
- understand business consequences;
- test the procedure.
A containment feature nobody has permission to activate during an emergency does not reduce MTTC.
3. Strengthen Identity Containment
Build rapid workflows for:
- account disablement;
- session revocation;
- token revocation;
- password reset;
- privileged credential rotation.
For identity controls, see Phishing-Resistant MFA Checklist.
4. Implement Network Segmentation
Segmentation reduces the attacker’s ability to move between systems.
Useful approaches may include:
- VLAN separation;
- workload segmentation;
- firewall policy;
- zero-trust access controls;
- restricted administrative networks.
Segmentation can reduce both blast radius and containment complexity.
5. Automate High-Confidence Actions
Automation can reduce delay for:
- confirmed malicious IP blocking;
- known compromised endpoint isolation;
- malicious message quarantine;
- high-confidence token revocation.
But automatic containment should be risk-based.
A false positive that shuts down a critical business system may cause significant harm.
6. Maintain Accurate Asset Visibility
You cannot contain a system you cannot identify.
Maintain:
- asset inventory;
- owners;
- IP/device mapping;
- cloud resource inventory;
- service dependencies;
- criticality.
During an incident, responders should immediately know:
What is this asset, who owns it, and what breaks if we isolate it?
7. Conduct Containment Exercises
Run realistic drills for:
- ransomware;
- identity compromise;
- cloud account takeover;
- supplier compromise;
- data exfiltration.
Measure:
confirmation → decision → action → effective containment
rather than simply asking whether the tabletop was “successful.”
For the full incident lifecycle, see Cybersecurity Incident Response Timeline.
8. Reduce Alert Fatigue
Poor alert quality can indirectly increase MTTC.
If analysts are overwhelmed:
- validation slows;
- escalation slows;
- containment begins later.
Improve:
- alert precision;
- severity classification;
- correlation;
- prioritization.
9. Create Severity-Based Playbooks
Containment authority should reflect incident severity.
Example:
Critical ransomware
Immediate:
- isolate endpoints;
- disable compromised identities;
- restrict SMB;
- protect backups.
High-risk account takeover
Immediate:
- revoke sessions;
- rotate credentials;
- inspect privilege changes.
Medium malware detection
Investigate first if containment can be safely delayed.
10. Measure MTTC Consistently
Do not change the definition every quarter.
Document:
Clock starts: confirmed incident
Clock stops: effective containment
Population: High + Critical incidents
Time basis: elapsed 24/7 time
Then compare quarter-to-quarter.
Cybersecurity Time Containment Funnel
A useful measurement chain is:
Alert
↓
Acknowledged
↓
Validated
↓
Containment decision
↓
Containment executed
↓
Containment validated
Each transition can be measured separately.
This helps answer whether delay occurs in:
- analysis;
- decision making;
- technical execution;
- verification.
Decision Time vs Execution Time
Suppose:
Incident confirmed: 09:00
Containment approved: 09:35
Containment technically completed: 09:41
MTTC:
41 minutes
But the underlying problem is clear:
35 minutes decision delay
versus only:
6 minutes technical execution
Buying faster EDR will not fix that.
The organization needs faster authority and escalation.
Third-Party Incidents Can Increase MTTC
Modern incidents increasingly involve:
- MSPs;
- cloud providers;
- SaaS providers;
- software suppliers;
- identity providers.
If the supplier controls the affected infrastructure, your internal team may be unable to complete containment alone.
Track third-party MTTC separately.
A supplier-dependent incident may show:
Internal containment decision: 18 minutes
but:
Vendor containment completed: 4 hours
That is a contract and governance problem.
For supplier management, see Third-Party Risk Assessment Checklist.
MTTC and Regulatory Readiness
MTTC itself is generally an operational metric, not a regulatory filing deadline.
But faster containment can improve:
- incident understanding;
- data-loss limitation;
- evidence preservation;
- regulatory assessment;
- customer impact.
Do not confuse:
MTTC
with:
legal notification time.
For regulatory clocks, see Cyber Incident Reporting Deadlines 2026: US vs UK.
Real-World Scenario 1: Ransomware
08:00 — EDR detects suspicious encryption behavior.
08:04 — Analyst acknowledges.
08:09 — Ransomware activity confirmed.
08:13 — Host isolated.
08:16 — Compromised user disabled.
08:19 — Sessions revoked.
08:25 — Lateral movement blocked.
If effective containment is declared at 08:25:
MTTC = 16 minutes
from confirmation at 08:09.
Scenario 2: Cloud Account Compromise
11:00 — Suspicious cloud-admin login.
11:07 — Analyst reviews.
11:15 — Unauthorized activity confirmed.
11:19 — Account disabled.
11:22 — Sessions revoked.
11:28 — Unauthorized OAuth grant removed.
11:34 — Access review confirms no active attacker sessions.
MTTC:
19 minutes
from confirmation.
Scenario 3: Phishing Campaign
14:00 — Malicious email reported.
14:07 — Payload confirmed.
14:11 — Message search begins.
14:15 — Delivered copies quarantined.
14:18 — Malicious domain blocked.
14:25 — Affected sessions revoked.
Effective campaign containment:
18 minutes
from validation.
Scenario 4: Third-Party Compromise
09:00 — Vendor reports compromise.
09:10 — Your organization identifies affected integration.
09:18 — Decision made to revoke vendor access.
09:24 — Local credentials revoked.
11:40 — Vendor confirms attacker access removed from its environment.
Depending on your measurement policy, you may track:
internal MTTC
and:
full ecosystem containment time
separately.
That distinction provides better management insight.
Common MTTC Measurement Mistakes
Mistake 1: Starting the Clock at Different Points
Use one definition.
Mistake 2: Treating First Action as Containment
An isolated endpoint does not mean the entire incident is contained.
Mistake 3: Confusing Containment With Eradication
Containment limits further harm.
Eradication removes attacker persistence/root cause.
Mistake 4: Confusing MTTC With Recovery
Services can remain offline long after the attacker has been contained.
Mistake 5: Reporting Only the Mean
Add:
- median;
- P90/P95;
- maximum.
Mistake 6: Ignoring Incident Severity
Containment expectations should be risk-based.
Mistake 7: Ignoring Identity Sessions
Resetting a password without revoking sessions may leave attacker access active.
Mistake 8: Ignoring Third Parties
Supplier-controlled systems may become your biggest containment bottleneck.
MTTC Scorecard Example
| Metric | Q1 | Q2 | Q3 |
|---|---|---|---|
| Mean MTTC | 51 min | 39 min | 27 min |
| Median MTTC | 34 min | 25 min | 19 min |
| P90 | 4.2 hrs | 2.8 hrs | 1.7 hrs |
| Critical MTTC | 18 min | 13 min | 9 min |
| Cloud MTTC | 67 min | 49 min | 32 min |
| Vendor-dependent MTTC | 5.4 hrs | 4.2 hrs | 3.0 hrs |
This shows whether improvement is occurring across the full response population.
90-Day MTTC Improvement Plan
Days 1–30: Define and Measure
Establish:
- start point;
- end point;
- severity population;
- baseline mean;
- median;
- P90.
Days 31–60: Remove Bottlenecks
Investigate:
- approval delays;
- inaccessible EDR controls;
- IAM delays;
- vendor dependencies;
- incomplete asset inventory.
Days 61–90: Test
Run:
- ransomware drill;
- cloud-account takeover;
- compromised administrator;
- vendor compromise.
Measure containment intervals and compare them with the baseline.
Frequently Asked Questions
What does MTTC mean in cybersecurity?
MTTC usually means Mean Time to Contain.
It measures the average elapsed time required to effectively limit the spread or further impact of security incidents according to a consistently defined measurement policy.
What is the MTTC formula?
MTTC = Total Containment Time ÷ Number of Incidents
When should the MTTC clock start?
A useful approach is to start at:
incident confirmation or validation
rather than the first raw alert.
The important point is to use the same definition consistently.
When should the MTTC clock stop?
When the organization has reasonably established effective containment, meaning the attacker’s ability to continue spreading or causing immediate harm has been significantly limited.
Is MTTC the same as MTTD?
No.
MTTD measures detection.
MTTC measures containment after a defined response starting point.
Is MTTC the same as MTTR?
Not necessarily.
MTTR is an ambiguous acronym and should always be explicitly defined.
On Cybersecurity Time, MTTR is treated as Mean Time to Respond, while MTTC specifically focuses on containment.
Is containment the same as eradication?
No.
Containment stops or limits additional damage.
Eradication removes:
- malware;
- persistence;
- compromised credentials;
- exploited vulnerabilities;
- root causes.
What is a good MTTC?
There is no universal benchmark.
Targets should reflect:
- severity;
- business criticality;
- attack speed;
- environment;
- operational constraints.
Does faster containment always mean better security?
Not automatically.
Containment that is too aggressive can cause unnecessary disruption or destroy evidence.
The goal is:
fast + accurate + proportionate containment.
Is NIST SP 800-61 Rev. 2 still current?
No.
NIST finalized SP 800-61 Rev. 3 in April 2025, superseding Rev. 2.
Which ISO standard is current for incident management?
Use the current ISO/IEC 27035 series, including:
- ISO/IEC 27035-1:2023;
- ISO/IEC 27035-2:2023;
- ISO/IEC 27035-3:2020.
Final Takeaway
Mean Time to Contain is one of the most useful operational cybersecurity metrics when it is clearly defined.
A practical measurement model is:
incident confirmed → containment action → containment validated
The basic formula is:
Total containment time ÷ incidents = MTTC
But mature security programs should go further.
Measure:
Mean MTTC
Median MTTC
P90/P95
severity
incident type
third-party dependency
Then investigate where delay occurs.
Sometimes the problem is:
slow technical execution.
Sometimes it is:
unclear approval authority.
Sometimes it is:
identity sessions that were never revoked.
Sometimes it is:
a supplier that takes four hours to respond.
Current threat research reinforces why containment speed matters. Mandiant’s 2026 data shows both long-lived stealthy intrusions and attack hand-offs occurring in less than 30 seconds, while NIST’s current guidance treats incident response as an integrated risk-management capability rather than a single SOC procedure.
The right question for a CISO is therefore not merely:
“What is our MTTC?”
It is:
“When an attacker is active, how long does it take us to actually remove their ability to keep causing harm?”
That is what containment performance should measure.
Primary External Sources
For a Wikipedia-style article, I recommend using primarily authoritative sources and only using Wikipedia for general terminology where useful.
- Mean Time to Detect (MTTD)
- Mean Time to Respond
- Dwell Time Cybersecurity
- Cybersecurity Incident Response Timeline
- Data Breach Timeline Template
- Phishing-Resistant MFA Checklist
- Third-Party Risk Assessment Checklist
- Cyber Incident Reporting Deadlines US vs UK
For a general reader-facing definition of incident response, you can optionally add a contextual Wikipedia link:
But I would not use Wikipedia as evidence for technical standards or benchmark claims. For those, NIST, ISO, CISA, and major threat-research sources are much stronger.
