SOC metrics come in many shapes, and plenty of them have nothing to do with time. The time-based ones are the SOC clocks that measure an alert's life, and the one worth watching in 2026 is mean time to conclusion.
Your security operations center (SOC) runs on a single question. Are you reaching defensible answers faster than alerts arrive? Not detecting faster, not acknowledging faster, but concluding. MTTC measures exactly that, which is detection plus acknowledgment plus investigation in one number.
What does MTTC stand for in cybersecurity?
MTTC has two expansions in active use, and they measure different things.
- Mean time to conclusion runs from the first sign of a threat to a defensible verdict with a response plan ready. It answers whether you understand what happened.
- Mean time to contain runs to the point where the threat has been stopped from spreading. It answers whether you have limited the damage.
Most of the market uses the second. Dropzone AI uses the first, because conclusion is the milestone an analyst actually produces and the one AI moves. Whichever you track, state which expansion you mean before you compare your number to anyone else's, since the two are not interchangeable.
This guide covers mean time to conclusion.
What mean time to conclusion measures
A defensible verdict means one of two outcomes, a true positive escalated or a false positive ruled out, with the evidence attached and a response plan ready. Anything short of that is not a conclusion, and a ticket closed as "probably nothing" certainly is not.
Conclusion spans three of the five clocks that describe an alert's full arc, from the moment something fires to the moment the response is done.
MTTD vs MTTA vs MTTI vs MTTC vs MTTR
Each clock starts and stops somewhere different. Read them side by side to see where your time goes, but never add them together, because the spans overlap.
MTTC is the only one of the five that aggregates. Sum detection, acknowledgment, and investigation and you get the entire pre-response workload in one figure, everything that has to happen before your team can act.
That aggregation is what makes it useful. You can post a sharp MTTD and still conclude slowly, because your alerts back up behind whoever is on shift or your investigations run long, and a single detection number will never show it.
MTTC does. When your conclusion time climbs, the breakdown tells you whether acknowledgment or investigation is the clock dragging it up.
Where the time actually goes
Put one alert on the timeline and the aggregation stops being abstract. The spans below are chosen to show how the clocks stack against the five timeline points above. They are not measured telemetry, not any environment's results, and not a claim about how long analysis typically takes.
An endpoint agent logs a suspicious PowerShell execution at 02:14. The event reaches the SIEM within a minute, but the rule that catches this pattern runs on a 15-minute schedule rather than evaluating events as they stream in, so the alert doesn't fire until 02:31. The overnight shift is working a higher-severity case and this one lands as medium severity, so it sits in the queue until the morning shift picks it up at 08:05.
From there the analyst works it in order:
- Read the command line, and decode it. The encoded command it was launched with turns out to pull a second-stage payload from an external host.
- Walk the process ancestry back to the parent. Does that parent have any business launching PowerShell, and is it running from its expected path?
- Confirm which account invoked it.
- Scope it. Which account, which host, what the payload did, and whether it ran anywhere else. This is where most of the hour goes.
They escalate a confirmed true positive with a containment plan at 09:20.
Detection took 17 minutes. The other seven hours went to waiting and to analysis.
Report MTTD alone and this looks like a well-instrumented SOC, which it is. The detection worked. MTTC is the number that shows you the alert still took seven hours to answer, and the breakdown tells you the queue, not the analyst, is where to look first.
Why MTTC is the clock to watch in 2026
MTTC is worth watching because it's the clock AI can still move. Detection already got faster. The time left inside MTTC sits in the human-bound middle, acknowledgment and investigation, and that's where agentic AI changes the math.
Detection got faster because it was always machine work
Signatures, anomaly models, and EDR (endpoint detection and response) analytics never needed a human in the loop, so detection rode every advance in automation.
Mandiant's frontline numbers show the arc. Global median dwell time, the gap between compromise and detection, ran at about 24 days in 2020. The M-Trends 2026 report, published March 2026 on 2025 investigations, has it rising to 14 days from 11 the year before, an increase the report attributes to attackers growing more sophisticated at evading defenses. So detection isn't finished, and the long-run gain is still real.
The middle never got that lift, because it runs on people
An alert waits for an analyst to free up, then waits again while that analyst pulls logs, chases the lateral movement, and builds a verdict that will hold. Add volume and both clocks stretch.
That's the five and a half hours of queue time in the example above, and it's why MTTC is where your remaining time lives.
What changes when agents work the middle
AI agents don't carry that constraint. Under an agentic SOC, a model where a collective of specialized AI agents runs investigation continuously instead of a queue of alerts waiting on analysts, acknowledgment happens in seconds and investigation runs at machine speed.
Dropzone AI implements that model. Its AI SOC Analyst investigates every alert end to end and returns a verdict with evidence and a response plan, while analysts direct the system and own every verdict. On threats the agents confirm, auto-containment blocks malicious IPs and disables compromised accounts.
You set where the agents stop, and the audit trail shows those limits held.
Across the clocks, that shows up as:
- Investigation. Across Dropzone AI deployments, manual alert investigation drops about 95% on average, because the agents work every alert instead of the fraction a team can reach.
- Response. Indiana Farm Bureau reports 5x faster response once verdicts arrive with a plan.
- Hunting. Indiana Farm Bureau reports proactive threat hunts that used to run up to 40 hours compressing to about one.
Detection was the machine-solvable clock, and it's the one the industry has moved furthest on. Conclusion is next, and it improves when the always-on middle stops waiting on human availability.
What a good MTTC looks like
A good MTTC has a real definition. You consistently conclude investigations in time to act before real damage is done. There's no universal target number, but there is a standard you can measure yourself against, and it belongs to the attacker.
CrowdStrike tracks breakout time, the gap between an intruder's initial access and their first lateral movement into the rest of your environment. Its 2026 Global Threat Report puts it at:
- 29 minutes average eCrime breakout time
- 27 seconds for the fastest recorded
That's the window on a hands-on intrusion. Conclude after an intruder has moved laterally and you're no longer investigating one compromised host, you're scoping a response across several.
Set the example above against that. Detection at 17 minutes was inside the window. The conclusion at seven hours was not, and the alert turned out to be a real intrusion with a second-stage payload.
That gap between a fast detection clock and a slow conclusion clock is the whole reason to measure the composite. It is also why segmentation matters more than a single headline number. Seven hours on a low-severity false positive costs you analyst time. Seven hours on hands-on-keyboard activity costs you the environment.
Then read your own number honestly:
- Segment it. One MTTC across every alert mixes commodity malware with hands-on-keyboard intrusions, so your average moves with your alert mix rather than your capability. Break it out by severity or attack type.
- Report the shape. Show the median and a high percentile alongside the mean, so a run of fast, low-severity conclusions can't bury the slow ones that matter.
MTTC speaks only to the alerts your tools generate. What your detection misses entirely is a separate question and a separate metric. It's worth tracking, but it isn't this clock.
How to instrument MTTC
You need three fields on every alert, which are the fire timestamp, the conclusion timestamp, and the verdict. Everything you'll want later, MTTC by analyst, by alert type, by shift, is a slice of those three.
What three fields do you need?
- Fire timestamp. Pull it from the SIEM (security information and event management) or whichever tool raised the alert. Pick one authoritative clock and reconcile tool skew before you measure, because a few minutes of drift between systems becomes noise in your average.
- Conclusion timestamp. Stamp it when the verdict is recorded, not when the ticket status flips to closed. This is the trap that quietly flatters the number. If an overnight job clears stale alerts, those closures masquerade as fast conclusions and pull your MTTC down for the wrong reason.
- Verdict and evidence link. True positive escalated, or false positive ruled out, with a pointer to what proved it. Without this field you're measuring ticket hygiene, not investigation.
Write the definition of a conclusion down once and hold every shift to it. If conclusion means one thing to the night shift and something looser to the day shift, your average blends two different measurements and the trend stops meaning anything.
How to report MTTC to leadership
For leadership, MTTC answers the question behind every board slide. Are we keeping up? Report it as a trend, not a snapshot, and pair it with MTTR, the once-we-know-how-fast-do-we-act clock.
Do not add MTTC and MTTR together. If your MTTR starts at the alert firing or at detection, which are the two common choices, it opens before the verdict that stops MTTC, so the two clocks share the stretch in between and summing them double-counts it. Report them side by side as two questions.
Which two numbers go up the chain?
- MTTC as a trend, segmented by severity. Whether you're concluding faster than the work arrives, which an "alerts handled" count can never answer.
- MTTR as a trend. Once a verdict lands, how fast the response completes. MTTR is the most overloaded acronym in the set, since respond, resolve, remediate, and recover put the endpoint anywhere from hours to weeks apart. Fix which one you measure, then track the direction rather than the absolute number.
Keep the component clocks, MTTD, MTTA, and MTTI, on the floor. They tell your team where an MTTC problem lives, but on their own they invite the wrong questions in a boardroom. Lead with the trend and the outcome, not the raw timers.
If you're rebuilding your metrics, MTTC is the one to build around. Stamp the three fields, hold the definition of a conclusion, and watch the direction against the window an attacker gives you. If you want to compare notes on where your conclusion time is going, we're glad to talk.
.png)