SOC Metrics & KPIs That Matter in 2026: MTTR, MTTD, MTTI

Security Operations Center (SOC) metrics provide quantifiable measures of your organization’s security posture and operational efficiency. They give SOC managers the visibility they need to pinpoint gaps, streamline workflows, and reduce risk. With dozens of dashboards, thousands of alerts, and a flood of telemetry, it can be hard to know which metrics to track and what insights they’ll reveal. We recommend focusing on three core areas of awareness:

1. Threat detection and response effectiveness
2. Analyst team cognitive load
3. Business growth preparedness

This blog provides a starting place for managers to build out metrics for these three areas to bolster decision-making. This article has been updated to include a short section at the end on how AI changes SOC metrics.

Threat detection and response effectiveness

When evaluating this area you’re really trying to understand if you have the appropriate visibility and response time to effectively contain threat actors before they achieve their objectives. That window is short and getting shorter: Secureworks’ State of the Threat report measured median ransomware dwell time at under 24 hours back in 2023, with lockers deployed within five hours of initial access in one case out of ten, and Mandiant’s M-Trends 2026 report found that in 2025 the median time between initial access and hand-off to a secondary operator was 22 seconds. That comes down to finding threats, investigating threats, and responding to threats.

What is Detection Coverage?

Detection coverage measures the percentage of detections your team has implemented and tested that align to a known framework, namely MITRE ATT&CK. The purpose of this measure is to illustrate the likelihood that your operations team would receive some form of signal in the event of an incident.

How do I measure detection coverage?

In ATT&CK’s case, there are 211 techniques in the enterprise matrix as of v17 (April 2025); the exact count moves with each release. You would simply divide the detections you have that uniquely cover a technique by the total number of techniques.

What does good detection coverage look like?

For most teams, striving for 100% coverage of something like MITRE ATT&CK is both unadvisable and unachievable. The operational energy to build, implement, and review the resulting detections would consume considerable team cycles and require a long tail of tuning and maintenance.

However, the probabilities suggest that teams don’t need perfect coverage to identify threats. Remember, a threat actor has a limited number of behaviors they perform and has to accomplish every step in the threat lifecycle to achieve their objectives. With the simplifying assumptions that:

• Every technique or behavior is equally likely by a threat actor (not true)
• Your current visibility would record some form of monitored telemetry for 7 of the 10 techniques that would occur prior to Impact (assuming a minimum of 1 per lifecycle stage)
• Your team wants to detect at least 3 of those behaviors for a threat actor without further investigation

That would require detections uniquely covering roughly 137 of the 211 techniques, or about 65% detection coverage, for those outcomes. Teams with less experienced investigators typically want to opt for higher coverage on the detection front to account for slower investigation times.

How should this metric direct action?

1. Justify and validate that the team has appropriate telemetry visibility into the organization
2. Direct what detections the team should focus on building. Remember, there isn’t an equal likelihood for every behavior. Make sure to invest in behaviors that are most common (as seen in threat intelligence, threat reports, or even social media).

Additional Notes: In the event your team is light on capacity and needs to suppress detections, the strong candidates will be ones with high false positive ratios that are already covered by another detection. Your effective coverage won’t decrease but your overall capacity will increase.

What is Mean Time to Detect (MTTD)?

Mean time to detect measures the average amount of time it takes for an organization to identify an incident from the point the activity started. This measure is evaluating both your detection coverage and alert ingestion pipeline.

How do I measure MTTD?

Mean Time to Detect is calculated by subtracting the “Alerted At” time from the “Activity Started At” time for the earliest event in an incident.

What is a good MTTD?

The closer to zero, the better. Generally high performing organizations will fall somewhere between 30 minutes and 4 hours. Latency tends to get added from events early in the attack lifecycle, like VPN authentications using compromised valid credentials, that may be harder to identify before more direct action on a managed device in the environment.

How should this metric direct action?

1. Validate that where you’re investing in detection coverage is paying off in incident identification
2. Necessitates post-incident detection reviews to validate earliest activity and glean any potential behaviors for detections

Additional Notes: For a deeper dive on MTTD, including where the metric falls short in practice, see our full guide to Mean Time to Detect (MTTD).

What is Mean Time To Respond (MTTR)?

Mean time to respond measures the average amount of time it takes for your security team to go from security event to containment or resolution. This measure encompasses your entire operational pipeline from ingesting security telemetry, acknowledging the alert, triage and investigation, and initial containment.

How do I measure MTTR?

Mean Time to Respond is calculating the total time it takes from activity occurrence to stopping the bleeding for each alert and averaging them. Typically this is measured across a 30 day period.

What is a good MTTR?

Two to four hours is a generally acceptable range across all alert severities. The lower the MTTR, the lower the risk of a significant security incident.

Organizations may also choose to split their MTTR by detection severity and assign different levels of priority. In that case, the following would be strong starting points:

• Critical: 1 hour
• High: 2 hours
• Medium: 4 hours
• Low: 8 hours

How should this metric direct action?

1. SOC managers should investigate if there are significant differences in MTTR between alert sources, alert types, and individuals to identify pain points or training opportunities
2. MTTR should force a SOC manager further into their investigative process. Is the majority of the time spent with alert ingestion, alerts waiting to be actioned, triage and investigation, or performing initial response actions? If most of the time is going to triage and investigation, our MTTR reduction guide covers practical steps to bring it down.

Additional Notes: I’m personally a bigger fan of Median Time to Respond over Mean Time to Respond. Medians will naturally have a greater resistance to outliers that may throw off your metrics.

{{ebook-cta}}

What is False Negative Rate / Investigation Error Rate?

Error rate or false negative rate measures how often an analyst or automation incorrectly dispositions true positive activity as a false positive. This informs security teams of poor documentation, lack of training, or alert fatigue that may result in missed critical detections.

How do I measure false negative rate?

False Negative rate is notoriously challenging to measure: after all, if you could calculate your errors you wouldn’t have them in the first place. Shameless plug: check out the quality control process laid out by Expel that uses sampling to simplify your false negative learnings.

What is a good false negative rate?

At or below 1% error.

How should this metric direct action?

• SOC managers should investigate if there are process improvements that need to be made or training opportunities to limit the number of false negatives.

What is SOC Capacity and Expected Work?

SOC Capacity measures how much total available time your team has to disposition security alerts.

Expected Work is the total amount of alert management work you expect in a given month.

How do I measure SOC capacity and expected work?

For a simple approach, we’re going to remove some real world components like arrival rates (how quickly do alerts come into the queue at once) and periodicity (what time of day do these alerts typically occur) and solve for a completely uniform distribution of events.

We’re assuming your analysts are working 8 hour days and that 70% of their time (5.6 hours) is available to do work outside of lunch, breaks, meetings, etc. Capacity is always measured in hours.

Total SOC Capacity (20 days / 1 month) =

[# of Security Analysts] * 5.6 hours * [% time spent triaging] * [# time in days]

Example:

• You have a team of 5 security analysts with 40% of their time spent triaging alerts

5 analysts * 5.6 hours * 0.40 * 20 = 224 hours

Expected Work is calculated as MTTR * Average Alert Volume. If it takes the team on average 1.1 hours to respond to an alert and you have 200 of them a month, ideally your team would have a SOC capacity around 250 hours (1.1 hours * 200 alerts * a 1.15 surge multiplier, which is the 15% buffer below).

What does good look like?

Good is a relative term here, but generally you want to have capacity available that exceeds your average work volume by 15% in a given month so that your team can handle alert surges.

How should this metric direct action?

• SOC managers should ensure that they have available capacity to manage their expected work in a given month and be able to account for future growth.
• Expected Work that’s exceeding capacity is ripe for support with automation or appropriate detection tuning.
• When SOC capacity is significantly below Expected Work, you run significant risk for burnout which cannot be sustained.
• If your Alert Latency / Alert Dwell time is high as a component of MTTR, take a hard look at capacity as a second order measure to suss out if resourcing is your constraint.

Additional notes: For a deeper understanding of capacity planning outside of the simplified model above, check out Jon Hencinski’s guide to SOC capacity modeling.

Analyst team cognitive load

Just like a well oiled machine, an efficient SOC isn’t “redlining” at all times. With the expanded responsibilities of SOC teams these days, pushing security teams too hard for too long can lead to attrition and burnout. SOC managers have to be mindful by talking to their directs during 1:1’s, but can also use the following SOC metrics as starting points to identify morale issues.

What is Mean Time to Investigate (MTTI)?

This is the average duration between acknowledging an alert, investigating the activity, and resolving the alert.

How do I measure MTTI?

Alert Resolved Time - Alert Acknowledged Time

Naming varies from team to team: some organizations track this same window as mean time to triage. For clarity on how the three time metrics relate, MTTD covers activity start to alert, MTTI covers acknowledgment to resolution, and MTTR covers the full window from activity start to containment.

What is a good MTTI?

Top organizations will be averaging between 10 minutes to an hour, depending on alert volume and automation. Keep in mind that for organizations with high amounts of false positive alerts, tuning those alerts may artificially raise your mean time to investigate. That’s not a bad thing.

How should this metric direct action?

1. Are there alert types with significantly higher MTTI? Is there an opportunity for automation or enrichment to support faster conclusions?
2. Are there any alert types with high MTTI that are also high volume? These can be mind numbing for analysts. Prioritize for tuning, training, or automation.

Additional note: Like MTTR, I’m a personal fan of using Median instead of Mean for this measure for some outlier resistance.

What is Alert Latency / Alert Wait Time / Alert Dwell Time?

This measure describes the amount of time between suspicious activity occurring that triggered an alert and when an analyst or engineer acknowledges that alert.

How do I measure alert latency?

Alert Acknowledged Time - Activity Start Time (take the absolute value)

What is good alert latency?

Similar to MTTR, Alert Latency is typically managed based on alert severity. The following would be in the range of the top 10% of security organizations:

• Critical: 20 minutes
• High: 1 hour
• Medium: 2 hours
• Low: 6 hours

How should this metric direct action?

1. Are there specific alerts or classes of technology that the team is consistently avoiding? Does it line up with an extended Mean Time to Investigate for those alerts? This might indicate a training or tuning opportunity.
2. Is your alert volume higher than average? Does the SOC have the capacity to take on the workload given? You’ll need to invest in people or automation. For more on cutting the queue wait itself, see removing alert wait time in the SOC.

What is False Positive Rate?

This is how accurate your detections are at finding threat activity.

How do I measure false positive rate?

Number of false positive alerts / total number alerts in a given period.

What is a good false positive rate?

Unfortunately, there’s a good bit of variation between organizations depending on risk tolerance to specific high false positive prone behaviors and overall alert volume.

False positive rates should be considered in the severity of alerts generated by your team, as high severity alerts demand urgent responses. If your team constantly needs to be high availability for low priority false positive alerts, you’ll start to see alert fatigue. Any security organization adhering to the following is operating well above average:

• Critical: under 25% false positive rate
• High: under 50% false positive rate
• Medium: under 75% false positive rate
• Low: under 90% false positive rate

How should this metric direct action?

Are there alerts that require tuning or downgrading for not meeting the severity threshold?

Business growth preparedness

Security operations is often a reactive function in an organization, but anticipating future business growth allows a SOC manager to effectively resource or prioritize spend to reach business objectives.

What are Alerts per Unit of Growth?

The intent of this measure is to have a rough proxy based on historical data to show how internal growth across a single axis (customers, employees, AWS workloads) impacts alert volume as a ratio. Tracking this measure over time can help account for work variability or underscore efficiency changes to detection engineering.

How do I measure alerts per unit of growth?

Total Monthly Alerts / Internal Growth Unit

As an example, your company has an OKR to grow to 1000 employees by the end of the year. Your historical trend for internal growth has been 1.15 alerts per user. If you currently have 500 employees you can anticipate your total monthly alert volume to move from 575 alerts to 1,150 alerts. You can then calculate Expected Work with your current MTTR and start capacity planning.

Additional note: This won’t accurately account for atypical growth like new product launches or new onboarded security products

What does good look like?

There’s no right answer here. Your goal should be to directionally forecast what the security team needs to deliver based on the business growth goals. You’ll normally come across these growth goals during Company All-Hands or OKR reviews.

How should this metric direct action?

1. How do internal growth projections impact our overall capacity modeling? When do we need to budget for additional automation or resources to accommodate?

Additional note: In a more self-serving vein, SOC managers have an incredible opportunity to showcase non-linear growth of their security organization if they can break the Alerts / Unit of Growth trend. This is typically through internal innovation or automation.

How AI changes SOC metrics

If an AI agent handles part of your triage and investigation work, the SOC metrics above still apply, but a few of them start to mean something different. Alert latency drops toward zero because investigations start immediately instead of waiting for a free analyst, so MTTI says more about investigation quality than about queue depth. The capacity math changes too: Expected Work assumes every alert costs analyst time, and that assumption breaks once benign alerts get investigated and closed autonomously. False negative sampling also gets easier, since every alert comes with a documented investigation trail you can review.

Some practitioners have started tracking mean time to contain alongside or instead of MTTR. One large-enterprise SOC director put it this way: “I stopped tracking MTTR and started tracking mean time to contain. That’s all me, that’s stopping the hacker in their path.” There are also new measures with no pre-AI equivalent, like investigation depth per alert and agreement rates between AI and human determinations. We cover those in 5 Things to Measure in an AI-Driven SOC.

Wrapping up

Effective SOC metrics cover three areas: detection and response effectiveness, analyst team cognitive load, and business growth preparedness. Establishing and maintaining them takes ongoing work, but it gives SOC managers a tangible way to measure performance and to guide decisions about staffing, tuning, and tooling. Review your definitions and targets quarterly so the numbers stay comparable over time, and when they point to an investment, use them to build a business case using these metrics.

At Prophet Security, we built Prophet AI, the agentic AI SOC platform whose specialist agents triage and investigate every alert with senior-analyst depth and a documented evidence trail. Request a demo of Prophet AI to learn how teams use it to improve MTTI, MTTR, and SOC capacity without adding headcount.

Further reading

• What is MFA fatigue attack?
• Investigating geo-impossible travel alert
• Top 3 scenarios for auto remediation
• Automated incident response: streamlining your SecOps
• Key SOC tools every security operations needs
• Demystifying SOC automation
• SOC challenges for analysts and managers
• Alert tuning best practices: keys to reducing false positives
• How to investigate Okta alerts
• AI SOC: Key to solving persistent challenges
• AI SOC Analyst: A comprehensive guide
• Will AI replace cybersecurity jobs?