MTTD, MTTA and MTTR: The Metrics to Evaluate Your SOC

MTTD, MTTA and MTTR are the three metrics that measure how fast a company deals with a cybersecurity incident. MTTD (mean time to detect) measures how much time passes between the start of an incident and the moment it is detected; MTTA (mean time to acknowledge) measures how long it takes a person to pick up the alert and start reviewing it; and MTTR (mean time to respond) measures how long it takes until the incident is contained or resolved. The lower they are, the less time an attacker has to move around inside your systems.

Together they answer the question any executive eventually asks about their monitoring: if something happened today, how long would it take us to find out and stop it? That is also why they are the most objective way to compare SOC (security operations center) providers and to check whether yours delivers what it promises.

What MTTD, MTTA and MTTR measure

In a hospital emergency room, care happens in three stages: first someone has to notice that the patient is unwell; then a doctor has to see them at triage; and finally the patient has to be stabilized and discharged. A good hospital measures each stage separately, because each one breaks down for different reasons. Cybersecurity incidents work the same way:

Take a typical case: an accounts payable clerk opens a fake email and hands over her password. The attacker gets into her account that same morning, and the monitoring tool flags it as a suspicious sign-in four hours later (detection). An analyst picks up the alert 20 minutes after that (acknowledgment), and within another 40 minutes the account is locked and the session terminated (response). The attacker had five hours inside, and almost all of them went to detection.

The R in MTTR causes the most confusion. Depending on who reports it, it can mean respond (contain the threat: isolate the device, lock the account), resolve (remove the root cause and close the case) or recover (get back to normal operations). Containing a compromised account can take minutes; recovering a server can take hours. Before comparing numbers, always ask which of the three is being measured.

It also shouldn't be confused with RTO (recovery time objective), which is the maximum time your business can tolerate without a system. RTO is a target you set in your disaster recovery plan (DRP); MTTR is how long it actually takes you.

How to calculate MTTD, MTTA and MTTR

All three are averages: you add up the times for every incident in a period and divide by the number of incidents. With four incidents in one month, the math looks like this:

Averages have a blind spot: they can hide the very case that matters. If nine incidents are resolved in 10 minutes and one takes two days, MTTR looks acceptable and the serious incident gets diluted. That is why it pays to also ask for the median (the middle value), the worst case of the month and the metrics broken down by severity: critical, high, medium and low.

What counts as a good detection and response time

There is no single standard, because it depends on what you monitor and on the severity of each incident. There is, however, a public benchmark that shows how much time matters. According to IBM's Cost of a Data Breach Report 2026, data breaches took an average of 247 days to identify and contain: 183 to identify them and 64 to contain them. Breaches closed in under 200 days cost an average of USD 4.32 million, compared with USD 5.65 million for those that took longer.

That figure is about breaches that already happened, not everyday alerts. For your own operation, the practical move is to set targets by severity and measure against them. A reasonable starting point, which each company adjusts to its own reality:

MTTD is the hardest one to set a target for, because you don't know when an incident started until you investigate it. What helps is tracking its trend: if you detect earlier every quarter, your monitoring is improving.

What to ask your SOC provider

In the ER, a good hospital can tell you how long each patient waited. Your provider should be able to do the same for every alert. These five questions separate the providers that measure from the ones that only make promises:

1. How do you define each metric? In writing: when each clock starts and what the R in their MTTR stands for.
2. What targets are committed in the contract? The SLA (service level agreement) should include times for each severity level. A line that only says "24/7 response" is too thin.
3. What does the monthly report include? MTTD, MTTA and MTTR by severity, with the median and the worst case for each month.
4. Which actions do you take without waiting for my approval? If the provider can isolate a device or lock an account using containment actions agreed in advance, MTTR drops from hours to minutes.
5. How do the times change at night and on weekends? That is where MTTA tends to grow if the on-call coverage isn't real.

If your current provider can't tell you how long it took to pick up each alert last month, that alone tells you something. We cover what else to evaluate before signing in our guide on what a SOC is and when to hire one as a service.

How to reduce each time

Each metric moves with different levers. In the ER, shorter waits come from better triage far more than from extra beds, and your operation works in a similar way:

The tool that gathers those logs and generates the alerts is the SIEM (security information and event management). We compare the options on the market in our article on the best SIEM solutions.

Automation affects all three times. In the same IBM report, organizations that make extensive use of AI and automation in security closed the identification and containment cycle 65 days sooner: 215 days versus 280 for those that don't use them.

Write those procedures before you need them: agreeing on who can isolate a laptop or disable an account is far easier on a quiet afternoon than in the middle of an incident.

Frequently asked questions about MTTD, MTTA and MTTR

What does MTTR mean?

In cybersecurity, MTTR usually means mean time to respond: how long it takes for an incident to be contained. Some providers use it for mean time to resolve or mean time to recover. In industrial maintenance it means mean time to repair, the average time it takes to fix a piece of equipment, which is a different metric.

What is MTBF and why isn't it used for security incidents?

MTBF (mean time between failures) measures how often a piece of equipment breaks down. It helps plan maintenance and availability for machinery or servers, but it says nothing about how quickly you detect or stop an attack.

What is MTTC?

It is mean time to contain: how much time passes from detection until the threat stops spreading. Some reports separate it from MTTR to distinguish between stopping an incident and fully resolving it.

How often should these metrics be measured?

Every month, broken down by severity, with a review of the trend every quarter. A single month can be misleading because of one long incident; the trend shows whether your monitoring is improving.

What is a false positive and how does it affect MTTA?

It is an alert that looks like an attack but isn't one. When there are too many, analysts lose time reviewing noise and real alerts wait longer, so MTTA goes up. Tuning detection rules and using automated triage fixes it.

Can a company without a SOC measure MTTD, MTTA and MTTR?

Yes, though with less precision. To calculate MTTD, MTTA and MTTR, all you need is to record in each security ticket the time the incident started, the time of the alert, the time someone picked it up and the time it was contained.

How does SOC as a service improve these metrics?

A SOC as a service provides the visibility, triage and 24/7 on-call coverage that bring all three times down without you having to build your own team. That is how TecnetSOC, our managed SOC service, works.