Mean Time to Contain (MTTC) vs MTTR in an AI-Driven SOC

Mean time to contain (MTTC) is how long it takes, on average, to stop an attacker from getting any further once you know they are inside. In 2025, the average eCrime intrusion moved from the first compromised host to a second one in 29 minutes, according to the CrowdStrike 2026 Global Threat Report. The fastest breakout it recorded took 27 seconds.

Most SOC dashboards report a different number. Mean time to respond (MTTR) is the headline figure in most SOC metrics programs, yet the R in MTTR can stand for respond, recover, repair, or resolve. Atlassian's incident metrics guide makes the same point and advises teams to agree on which one they mean. SOC teams also stop the clock in different places. Some end it when the threat is contained. Others end it after cleanup, when the host has been reimaged and the ticket is closed. So a single MTTR figure can blend a 20-minute host isolation with a three-day rebuild, and it cannot tell you whether the attacker was stopped before they moved.

MTTC answers that question. Below, we cover what MTTC measures, how it compares with MTTR, how to instrument it with clean timestamps, and where containment time goes once AI handles the investigation.

{{ebook-cta}}

What Is Mean Time to Contain (MTTC)?

Mean time to contain (MTTC) is the average time between the moment a security team identifies a real threat and the moment it has stopped that threat from spreading, whether by isolating a host, disabling an account, revoking a session, or blocking an address.

The formula is simple. For each confirmed incident, subtract the time the threat was identified from the time containment was confirmed. Then add those durations together and divide by the number of incidents.

Three details decide whether the number means anything. First, the start point has to be fixed. IBM's annual Cost of a Data Breach study starts the clock when the breach happens and reports the time to identify and contain it as a single lifecycle, which reached 247 days in the 2026 edition, up from 241 the year before. Some SOC teams instead start at the first alert tied to the incident. Either choice works, as long as it never changes between reporting periods.

Second, containment is not the same as eradication or recovery. Containment stops the spread. Eradication removes the attacker's foothold, and recovery puts systems back into service. MTTC ends at the first of those three steps, which is why it is usually much shorter than a resolution-based MTTR.

Third, MTTC should only count true positives. A benign alert has nothing to contain. If closed false positives go into the average, they pull MTTC toward zero and hide how long real incidents take.

MTTC vs MTTR: What Each Metric Measures

MTTC measures how fast a team stops an attack from spreading, while MTTR, depending on the team, measures how fast it responds, resolves, or recovers, and usually covers a longer window that includes cleanup.

• Start of the clock: MTTC starts at identification of a confirmed threat, or at the first alert tied to it. MTTR starts at the security event or the alert, depending on the team.
• End of the clock: MTTC ends when the containment action is confirmed in the tool. MTTR ends at containment for some teams and at full resolution for others.
• Question it answers: MTTC answers whether the attacker was stopped before they could move. MTTR answers how long the whole response took.
• What inflates it: MTTC grows with queue wait, investigation time, and approval delays. MTTR grows with all of those plus reimaging, patching, and ticket closure.
• Who reads it: MTTC speaks to risk, so it fits CISO and board reporting. MTTR remains useful for recovery planning and IT operations.

Neither metric replaces the other. MTTR still tells you how much disruption an incident caused, and recovery time matters to the business. If you already report it, our guide on how to measure MTTR covers how to break it into stages. Detection speed has its own metric, MTTD, which measures the time from attacker activity to the first alert. When teams line up MTTD vs MTTR vs MTTC, MTTC starts roughly where MTTD ends and stops well before a resolution-based MTTR does.

Why Mean Time to Contain Tracks Attacker Risk

An attacker's progress depends on how long they can act without being stopped. Once a threat is identified, every minute before containment is a minute in which the attacker can still move laterally, escalate privileges, or stage data. After containment, those options close for the contained host or account, even if cleanup takes days. That is why a slow recovery and a slow containment carry very different risk, even when they produce the same MTTR.

Recent Gartner research on the roles an AI-enabled SOC requires points in a similar direction. It advises SOC leaders to drop alert volume, closure rates, and mean time to detect (MTTD) as primary KPIs, and to measure case accuracy, investigative cycle time, decision confidence, and outcome quality instead.

Practitioners have reached the same view on their own. One large-enterprise SOC director described the switch this way: "I stopped tracking MTTR and started tracking mean time to contain. That's all me, that's stopping the hacker." The point was ownership. Recovery depends on IT, application owners, and change windows. Containment is the part of the response the SOC controls most directly.

How to Measure MTTC: Start and Stop Timestamps

A reliable MTTC depends on two timestamps that mean the same thing on every incident. Most measurement problems come from one of them drifting.

For the start, use the earliest alert that belongs to the incident. That is usually the first moment the team had a chance to act, and it keeps queue time inside the measurement. Record the time the alert was confirmed malicious as a separate field, since the investigate segment below needs it.

For the stop, use the time the containment action was confirmed in the tool that performed it. That means the EDR shows the host as isolated, or the identity provider shows the sessions revoked and the account disabled. A ticket updated to say "contained" does not count, because tickets are often updated before or after the action happens.

With both timestamps in place, split MTTC into four segments:

• Wait: from the first alert to the moment someone, or something, starts investigating it.
• Investigate: from pickup to a determination that the activity is malicious.
• Decide: from determination to approval of a containment action.
• Act: from approval to confirmed containment in the tool.

Each segment has a different fix. Long waits often point to a staffing gap and to alert wait time building up in the queue. Long investigations point to missing context or manual pivots across consoles. Long decisions point to unclear approval rules. Long action times point to integrations that cannot execute the change.

Two reporting habits keep the number honest. Report MTTC by incident type, because disabling a compromised account and rotating an exposed cloud key do not take the same time, and a blended figure hides both. Also report the median and the 90th percentile next to the mean. A few long incidents can drag the mean far from what a typical incident looks like, and the 90th percentile shows where the slow cases sit.

Where Containment Time Goes When AI Runs the Investigation

AI investigation compresses the first two segments. When an AI SOC analyst picks up every alert as it arrives and runs the investigation right away, wait time drops to near zero and investigation time typically drops to minutes. For teams whose MTTC was mostly queue and investigation time, that removes most of it.

What remains is the decide and act segments. Both depend on decisions your team makes about approvals and tool access.

The decide segment is approval latency. Isolating a production server or disabling an executive's account usually needs a person to sign off. If the approver is in a meeting or asleep, containment waits, no matter how fast the investigation finished. Teams shrink this segment by setting rules ahead of time: which actions can run without approval, on which asset types and identities, and which always need a person. Our post on automated remediation walks through how teams draw those lines.

The act segment is execution. A containment decision only counts once the action lands in the EDR, identity provider, or firewall. In our conversations with SOC leaders, we have heard from teams that built their own LLM pipelines, got the analysis working, and then stalled at this step, because writing actions back into production tools safely is its own engineering problem.

So in an AI-driven SOC, MTTC mostly measures two things: how much containment authority you have granted to automation, and how fast people approve the actions you kept for them. That makes the segment view more useful than the headline number. If decide time dominates, the fix is a clearer approval policy.

Speed also needs a quality check. A fast MTTC means little if the containment actions behind it keep getting reversed. Track how often an automated containment is undone, and pair MTTC with AI disposition accuracy, so the team knows the actions it approves in advance are the right ones.

Final Thoughts

Average breakout time is now under 30 minutes. Mean time to contain, read alongside MTTD, tells leadership whether the SOC stops an intrusion inside that window, and the four segments show which part of the response is slowing it down.

Prophet AI investigates every alert and documents each query and piece of evidence behind its determination. Containment actions run under rules your team defines, scoped by action type, with approval required wherever you want a person in the loop, and your team can widen that scope as the actions prove accurate. If you want to see what that does to your own MTTC segments, request a demo.