Every security incident runs on two clocks. One measures how long an attacker operates before anyone notices. The other measures how long it takes to stop them once they are noticed. The longer either clock runs, the more room an attacker has to move between systems, steal credentials, or encrypt data.
Mean Time to Detect (MTTD) and Mean Time to Respond (MTTR) are the metrics most organisations use to track those clocks. They appear in board reports, vendor proposals, and service agreements. Yet many leaders struggle to say whether their own numbers are good, bad, or even accurate.
This guide explains what realistic MTTD MTTR mid enterprise benchmarks look like, how to measure them consistently, and how to use them for better risk decisions rather than an impressive-looking figure.
Mean Time to Detect (MTTD) is the average time between the start of malicious activity and the moment the security team identifies it as a genuine incident. If an attacker signs in with stolen credentials at 9:00 and an analyst confirms the compromise at 15:00, detection took six hours.
Mean Time to Respond or Remediate (MTTR) is less consistent. Some organisations use it for the time to begin responding. Others mean the time to contain the threat, remove it fully, or restore normal operations. These are very different numbers. Isolating a compromised laptop may take minutes, while rebuilding it and confirming the attacker is gone may take days.
For mid-sized enterprises, these metrics carry particular weight. Security teams are often small, analysts may also run IT infrastructure, and monitoring may cover some systems well and others barely at all. MTTD and MTTR show where those constraints slow things down.
There is one condition: everyone must agree on the event that starts the clock and the event that stops it. Without that agreement, two teams can report the same incident with completely different times, and both will be technically correct.
Vendor reports regularly publish average detection and response times. These figures can be interesting, but they are rarely a fair benchmark for a mid-sized enterprise, because the organisations behind them differ in important ways:
Comparing your numbers against a published average can therefore create false reassurance or unnecessary alarm. A short MTTD may simply mean that only easy-to-spot incidents are being counted.
The better starting point is an internal baseline built from your own incident records. Once you know where you stand, external figures can add context, but they should not set your targets on their own.
There is no single target that suits every mid-sized enterprise. Good performance depends on the conditions your team works under, and improving those conditions is usually what moves the numbers.
Consider a hypothetical retailer. It detects most endpoint malware within an hour because its endpoint tooling is well tuned. A compromised supplier account, however, goes unnoticed for nine days because the supplier portal is not monitored. The average MTTD hides the real problem: a coverage gap.
Good performance is therefore not the lowest possible number. It is a target the organisation can explain, sustain, and improve as capabilities grow. Targets chosen only to look impressive tend to encourage teams to exclude awkward incidents rather than fix the conditions behind them.
Metrics only become useful when they are measured the same way every time. Before comparing one quarter with the next, document exactly where each clock starts and stops.
| Metric | Clock starts | Clock stops |
|---|---|---|
| Time to detect | Earliest reliably observable malicious activity, or another defined event | Security team identifies and validates the incident |
| Time to acknowledge | Alert is raised | An analyst starts working on it |
| Time to contain | Incident is confirmed and response begins | The threat can no longer spread or cause further harm |
| Time to remediate | Incident is confirmed and response begins | Root cause is removed and affected systems are cleaned |
| Time to recover | Incident is confirmed and response begins | Affected business services return to normal operation |
Each measure tells you something different. Time to acknowledge reflects staffing and alert queues. Time to contain reflects authority and tooling. Time to recover reflects backups and continuity planning. Rolling them into one “MTTR” figure hides which part of the process needs attention.
The start of the detection clock needs particular care. Measuring from the first alert is easy, but it ignores how long the attacker was active before anything fired. Where an investigation reveals earlier activity, record that timestamp too, with a note on how it was established.
Once the rules are agreed, write them down and apply them to every incident, including the inconvenient ones.
MTTD and MTTR describe how well the security function operates. They do not, on their own, describe what an incident cost the business. Leadership needs both views.
Security operations metrics show how the team performs:
Business impact metrics show what incidents did to the organisation:
Better operations metrics are valuable, but they do not guarantee lower business impact. A team might contain most incidents faster while a flat, poorly segmented network still lets one ransomware event halt operations for a week. Equally, a team with modest response times may limit damage well because critical systems are isolated and backups are tested.
Reporting both groups side by side shows leaders whether faster operations are actually reducing risk, and where spending on resilience would achieve more than spending on detection.
An average makes a convenient headline, but it can conceal the incidents that matter most.
Hypothetical example (illustrative, not industry data): A company records 20 confirmed incidents in a quarter. Eighteen are contained within one hour. Two, both involving compromised privileged accounts, take 30 hours each. The mean time to contain is 3.9 hours, which sounds reasonable. Yet the median is one hour, and the slowest 10% of incidents took more than a day. The average describes neither the typical incident nor the serious ones.
The pattern is common because severe, complex incidents tend to take longer, and they usually carry the greatest business impact. To get a truer picture:
These eight steps give mid-sized enterprises a workable route to meaningful measurement:
The table below shows how a mid-sized enterprise might frame its core metrics. The targets are illustrative examples only, not universal recommendations, and should be set against your own baseline and risk profile.
| Metric | What it measures | Why it matters | Illustrative target |
|---|---|---|---|
| Time to acknowledge (critical) | Alert raised to analyst engagement | Shows whether critical alerts are seen promptly, including out of hours | Within 15 minutes, 24/7 |
| Time to detect (critical) | Earliest observable activity to validated incident | Shows how long attackers operate unseen | Steady reduction against baseline |
| Time to contain (critical) | Confirmed incident to threat contained | Limits spread and damage | Within 4 hours |
| Critical asset coverage | Share of critical systems sending usable logs | Defines what can be detected at all | All systems rated critical |
| Incidents within target | Share of incidents meeting agreed times | Tests whether targets are realistic and met | Tracked by severity, reviewed quarterly |
Leaders do not need to calculate MTTD and MTTR themselves, but they should be confident the figures are measured rather than estimated. These questions help:
Security reporting shapes decisions about budget, staffing, and risk acceptance. A figure built on unclear rules or selective data can make an organisation look better protected than it is. Clear answers to these questions give leaders confidence that the numbers reflect reality and that trends over time are genuine.
MTTD and MTTR work best as governance tools, not as scoreboards for individual analysts. When teams are judged only on speed, they may close incidents too early or classify difficult cases in ways that flatter the numbers.
Used well, these metrics support practical leadership discussions:
Organisations without the in-house capacity to address these questions often work with a managed security partner. Sattrix, for example, provides security monitoring and incident response services that can help mid-sized enterprises extend coverage and build a reliable measurement baseline. Whatever the delivery model, the aim is the same: metrics that drive continuous improvement and stronger business resilience.
Good detection and response performance is not about matching a number in a vendor report. It is about knowing exactly what you measure, measuring it consistently, and using the results to fix the conditions that slow your team down.
Start with clear clock rules, build a baseline from real incident records, separate results by severity, and look beyond averages to the incidents that take longest. Pair operational metrics with business impact measures so leadership can see whether faster response is reducing real risk.
Approached this way, MTTD MTTR mid enterprise reporting becomes a reliable guide for investment and improvement. Sattrix supports organisations in strengthening monitoring and incident response, but the most valuable first step is one every organisation can take internally: agreeing how the clocks are measured.
There is no universal figure. A good MTTD depends on log coverage, alert quality, and analyst availability. Measure your current baseline for each severity level, then set targets that improve on it in steps your team can sustain.
It can mean either, and some organisations use it for containment or recovery. What matters is that your organisation defines it clearly, documents the definition, and applies it consistently.
Use them for context only. Differences in company size, threat exposure, monitoring maturity, and methodology make direct comparison unreliable. Your own historical data is a better benchmark.
The median shows the typical incident and is not distorted by a few very slow cases. Reporting it alongside the mean reveals whether a small number of incidents are pulling the average up.
Many organisations review them monthly at an operational level and quarterly with leadership. Targets should also be reassessed whenever monitoring coverage, staffing, or processes change significantly.
It can, particularly where out-of-hours coverage or analyst capacity is the main constraint. Results still depend on log coverage, clear containment authority, and agreed escalation procedures inside your organisation.
