Key Takeaways
- MTTD (Mean Time to Detect) measures how long a threat sits in your environment before your team notices it.
- MTTR (Mean Time to Respond) picks up right after detection and measures how long it takes to contain and fix the problem.
- Best-in-class SOCs detect critical threats in under an hour. Many teams without mature monitoring still take days or weeks.
- A cluttered SIEM and constant alert fatigue are two of the biggest reasons both numbers stay high.
- AI-powered triage can cut MTTD by 30 to 40% and MTTR by 45 to 55% works with your existing stack.
Introduction
It’s 2:00 AM. An attacker logs into a dormant service account. Nobody notices until a routine review flags it six hours later. That six-hour gap is MTTD. What happens next, containing the account and cleaning up the mess, is MTTR. Two numbers, two very different jobs, and most SOCs only ever talk about one of them.
What Is MTTD (Mean Time to Detect)?
MTTD is the average time between when a threat first shows up in your environment and when your team actually confirms it. It’s calculated by adding up detection time across every incident in a period, then dividing by the number of incidents. Five incidents that took a combined 50 hours to catch give you an MTTD of 10 hours per incident.
MTTD has two separate clocks running inside it. The first is the time your data sat there, unnoticed, before anyone looked at it. The second is the time between an alert firing and an analyst confirming it’s real. Most teams only measure the second clock, which quietly hides how much risk they’re actually carrying.
How Does a SOC Detect Threats?
A SOC pulls signals from a mix of sources: your SIEM, EDR, identity provider, cloud logs, and email security tools. Those signals get correlated, matched against threat intelligence, and scored for risk. When something crosses a threshold, it becomes an alert that lands in an analyst’s queue.
The catch is that most environments generate thousands of these alerts a day, and a large share are false positives. Detection isn’t really a technology problem anymore. It’s a filtering problem. The faster your team can separate real signal from noise, the lower your MTTD drops.
What’s a Good MTTD for a SOC?
There’s no single number that applies to every organization, since it depends on industry, tooling, and team size. That said, a few reference points are worth knowing:
- Well-tuned, managed SOCs aim for under an hour on critical priority threats.
- Best-in-class programs detect in minutes to a few hours across the board.
- Organizations without mature monitoring often average days, sometimes weeks.
- At the macro level, IBM’s Cost of a Data Breach research found the average time to identify a breach dropped to 207 days in 2024, the lowest mark in nine years, though that figure reflects slow, stealthy intrusions rather than SOC alert response.
The direction that matters isn’t hitting a magic number. It’s showing steady, measurable improvement quarter over quarter.
What Is MTTR (Mean Time to Respond)?
Two clocks start the moment an attacker gets in
MTTD measures how long a threat goes unnoticed. MTTR measures how long it takes to shut it down once it’s found.
Every hour inside the MTTD window is dwell time attackers use freely. Every hour inside the MTTR window is damage still being contained.
Every hour inside the MTTD window is dwell time attackers use freely. Every hour inside the MTTR window is damage still being contained.
MTTR measures the time from confirmed detection to full containment. It uses the same math as MTTD: total resolution time divided by the number of incidents. If your team resolved 10 incidents in a month with 200 combined hours of work, your MTTR comes out to 20 hours per incident.
This is the metric that decides how much damage an attacker gets to do. Ransomware crews have compressed their playbook to the point where some can go from initial access to full encryption in under five hours. A slow MTTR hands them all the time they need.
MTTD vs MTTR: The Key Differences
The simplest way to separate them: MTTD is about noticing. MTTR is about fixing. Here’s how that plays out in practice.
- What they measure. MTTD tracks the gap between compromise and confirmation. MTTR tracks the gap between confirmation and containment.
- What drives them up. A noisy SIEM and constant false positives drag out MTTD, because real threats get buried in the queue. Manual, disconnected response playbooks drag out MTTR, because analysts are stitching together context by hand.
- Who feels the pain first. A slow MTTD means attackers move laterally before anyone even knows they’re in. A slow MTTR means damage keeps compounding after you already know what’s happening.
- Why boards care about both. Neither number tells the full story alone. A one-hour MTTD paired with a three-day MTTR still leaves a huge exposure window, and vice versa.
SIEM limitations sit at the root of a lot of this. A SIEM is built to collect and correlate logs, not to make judgment calls or take action. Without an operations layer on top of it, both MTTD and MTTR end up bottlenecked by however many analysts you can afford to hire.
How to Improve MTTD and MTTR in Your SOC
Most of the gains here don’t come from buying a new SIEM. They come from fixing what’s already flowing through the one you have.
What automation actually buys back
Real deltas reported by teams that automated detection and response — swipe to see each metric.
How to Improve MTTD Without Changing Your SIEM
You don’t need a work with your existing stack project to move this number. A few things that actually work:
- Tune existing detection rules against your real environment instead of vendor defaults.
- Add automated enrichment so analysts see context (asset owner, criticality, recent changes) the moment an alert fires, instead of digging for it.
- Build a full asset inventory. An unmanaged device doesn’t disappear from your SIEM; it just shows up as unexplained noise instead of a clear signal.
- Layer an AI operations layer on top of your SIEM to correlate related alerts into single cases instead of leaving analysts to piece together the story themselves.
How to Track SIEM Value Using MTTR and MTTD Data
If leadership is asking whether your SIEM investment is paying off, MTTD and MTTR are the cleanest proof you have. Set a 30-day baseline before making any changes: daily alert volume, average minutes spent per alert, and total triage hours per analyst per week. After you tune rules or add automation, compare those same numbers.
Track these four together for a real picture of SIEM ROI:
- False positive rate. Falling numbers here directly free up analyst hours.
- Alert coverage. What percentage of alerts actually get a human review, versus sitting untouched.
- MTTD trend. Should shrink steadily as enrichment and correlation improve.
- MTTR trend. Should shrink as playbooks and automated containment mature.
If triage hours drop and both metrics trend down month over month, your SIEM spend is working. If they’re flat, the problem usually isn’t the SIEM itself. It’s everything built around it.
Closing the detection gap and the response gap — at the same time
Seven ways the SOC Teammate shortens both clocks, from first signal to full resolution.
Related reads
FAQs
Is MTTD or MTTR more important?
What’s a realistic MTTD improvement after adding automation?
Does reducing alert overload actually lower MTTR?
Can a small SOC team realistically improve both metrics?
Conclusion
MTTD and MTTR aren’t competing metrics. They’re two halves of the same clock, and a strong security operations program keeps both moving in the right direction at once. Start by measuring where you actually stand today, then fix the noise, tune what you already own, and add automation where it counts. The number that matters most isn’t a benchmark you copied from a report. It’s whether next quarter’s numbers beat this quarter’s.
