MTTD and MTTR — why detection time determines incident impact
11 January 2026

MTTD and MTTR reveal a great deal about the work of security teams, but their relevance extends well beyond the SOC. The time taken to detect an incident, begin responding and restore normal operation affects finances, operational continuity and resilience. Cyberattacks cannot be eliminated entirely, but well-managed organisations know how to address these threats and limit their impact. Find out how MTTD and MTTR support these processes.
In this article, you will learn:
- What MTTD means and how it is calculated.
- What MTTR means and how it is calculated.
- Why MTTD and MTTR matter to the business.
- How do detection time, time to begin responding and recovery time affect an organisation’s security?
- What can cause high MTTD and MTTR.
- How to measure incident detection and response effectiveness in an organisation.
- How to prepare an organisation for effective threat monitoring.
Attack at 01:30, systems restored at 11:00. Why did it take so long?
At 01:30, long after everyone had left the office, a ransomware attack began. The attacker operated unnoticed for an extended period, encrypting valuable files containing user data and other sensitive information and moving freely to higher levels of the system. The administrator noticed the problem only on arriving at 08:00. Monitoring ran during office hours rather than 24/7. The administrator acted immediately, but faced considerable challenges. Servers were gradually isolated, yet the damage was extensive. Normal operation was not restored until 11:00.
Could the attack have been avoided? Probably not. Its impact could, however, have been reduced through timely detection. The attacker would not have gained access to so much data, and normal operation could have returned sooner. The problem was not the attack alone, but the long delay in detection and SOC response.
What is MTTD—Mean Time to Detect?
MTTD (Mean Time to Detect) is the average time needed to detect a threat. It is measured from the start of an incident to its detection by the security team. It is a technical metric, but it also supports business decisions.
Example:
A company has recently experienced several incidents:
- At 08:00, an employee clicked a malicious link, giving unauthorised people access to an account. The SIEM generated an alert at 08:25.
- At 14:00, an attempt was made to steal company data through an administrator account. A SOC analyst noticed the unusual transfer at 16:20.
- At 15:55, malware appeared on an employee’s computer. EDR detected it at 16:40.
The elapsed times between incident and detection were 25 minutes, 2 hours 20 minutes and 45 minutes respectively.
MTTD is then calculated as follows:
MTTD = (25 min + 140 min + 45 min) / 3 = 70 min
This means the organisation’s mean time to detect an incident was 70 minutes. Across these three cases, threats remained undetected for more than an hour on average.
It is important to know and regularly measure your organisation’s MTTD. This helps you understand:
- The potential impact of cyberattacks on company systems—the longer detection takes, the more severe it can be.
- Whether the security team is effective—a high MTTD signals the need to investigate and take corrective action, such as staff training.
- Where gaps exist—a high MTTD may indicate problems with monitoring, security tool configuration, detection processes or information flow between teams.
You can use this information to improve security monitoring and SOC operations. Measuring detection time alone will not eliminate threats. An attack may still occur, but its impact can be limited. The security team can learn about the incident sooner, before data theft, file encryption or other harmful activity occurs.
Also explore the business security requirements arising from the EU NIS2 Directive:
What is MTTR — Mean Time to Recover?
MTTR (Mean Time to Recover) in this article means the average time from incident detection to restoration of normal system operation. It covers the actions needed to contain the threat and recover the service. Time from detection to the first response action is measured separately. Beginning a response or isolating a threat does not, by itself, mean recovery is complete.
Mean Time to Recover, like Mean Time to Detect, is a technical metric that also serves as a business indicator.
Example:
A company has recently experienced several incidents:
- At 08:25, the SIEM generated an alert about a compromised employee account. The security team blocked unauthorised access and secured the account at 10:00.
- At 16:20, a SOC analyst detected an attempt to steal company data through an administrator account. The attacker’s access was blocked and the incident’s effects were addressed at 19:20.
- At 16:40, EDR detected malware on an employee’s computer. The device was isolated, the malware removed and the computer returned to service at 17:40.
The elapsed times from incident detection to restoration of normal operation were 1 hour 35 minutes, 3 hours and 1 hour respectively.
MTTR is then calculated as follows:
MTTR = (95 min + 180 min + 60 min) / 3 ≈ 111.67 min
The average time from incident detection to restoration of normal operation was approximately 111.67 minutes. This is an average across three cases, not the time to begin responding or the duration of a single shared outage.
Why should you know your organisation’s MTTR? This metric helps you:
- Measure the security team’s incident handling effectiveness, compare it over time and assess the effects of changes.
- Obtain data for further analysis and decision-making. Tracking MTTR helps managers and executives identify needs such as additional specialists, more effective 24/7 monitoring or cybersecurity training.
- Reduce the risk of downtime, penalties for unavailable IT services, data loss and additional costs from non-functioning systems.
- Improve risk and cybersecurity management.
Security of company resources is not an abstract concept. It can be measured using reliable indicators. Start measuring it today to gain greater control over security and limit the impact of cyberattacks.
| MTTD | MTTR | |
|---|---|---|
| Definition | Time to detect an incident, measured from its start until it is noticed by a security system or team | Recovery time, measured from incident detection to completion of recovery; time to begin responding is measured separately |
| The key differences | Measurement starts: when the incident begins. Purpose: detection speed. A high value means: attackers have more time to operate before detection. | Measurement starts: incident detection. Measurement ends: restoration of normal operation. Purpose: to assess recovery speed after an incident. A high value indicates a long interval between detection and return to normal operation. |
Read the article to learn what a 24/7 SOC is and how it supports detection and incident handling:
Why do MTTD and MTTR determine a cyberattack’s impact?
During every cyberattack, time works against your organisation. Malware can reach sensitive data, user accounts and other company assets in seconds. An undetected incident may last much longer—minutes or hours if company systems lack round-the-clock monitoring.
The longer an incident continues, the more room the attacker has to:
- Move laterally —move between systems and gain access to further accounts and other company assets.
- Escalate privileges —gain administrator-level access to systems and devices to steal data or disrupt IT operations.
- Prepare data exfiltration —locate, copy and send data outside the organisation.
- Launch further attacks, such as widespread ransomware.
The resulting damage can affect not just the organisation, but its customers and partners. Access to accounts can lead to user data breaches. If an attack interrupts customer services, the organisation may face contractual penalties.
Delayed detection can increase the extent of damage, while a high MTTR indicates that restoring normal operation takes a long time. Some consequences, such as data disclosure, cannot be reversed even after services have been recovered. MTTD and MTTR should not be considered in isolation. Rapid detection should lead to an effective response, threat containment and recovery. A low MTTR means a short time to restore operation, not simply a quick start to the response.
Also read our article on the first hour of a cyberattack:
Case study: how do detection and recovery times affect an organisation’s cybersecurity?
Consider two illustrative incidents: phishing gave unauthorised users access to an employee account in each organisation. Organisation X detected the threat after 10 minutes and restored normal operation one hour after detection. Organisation Y took 45 minutes to detect the incident and a further 3 hours to restore operation. These are individual incident durations; MTTD and MTTR are averages calculated across a defined set of incidents. What happened in each case?
- Company X: round-the-clock monitoring quickly detected suspicious activity. The alert reached the SOC, which analysed the situation and immediately blocked the compromised account. This limited the impact of the incident. Normal account operation was restored one hour after detection.
- Company Y: the monitoring system was incorrectly configured, so the event did not immediately trigger an alert and the security team detected the incident after 45 minutes. Standard incident response processes were also missing: clear roles and responsibilities, an agreed sequence of actions and escalation procedures. This caused confusion and delayed decisions. Three hours elapsed between detection and restoration of normal operation. The SOC had to block the attacker’s access, analyse logs, assess the extent of the breach and coordinate remediation.
These examples show that security incidents can happen even in a well-protected company with established procedures and effective systems. The difference lies in what happens after an attack: whether the threat is detected quickly and the team knows how to respond effectively.

What causes a high MTTD?
The most common causes of a high MTTD—a long detection time—are:
- No monitoring, or monitoring limited to office hours. If IT is not monitored continuously, incidents can remain unnoticed for a long time. This is particularly serious outside specialists’ working hours, when suspicious activity may go unseen and attackers have hours to operate without authorisation.
- Incorrectly configured alerts. Overly restrictive alert rules can miss events or respond late. Too many notifications, meanwhile, can cause alert fatigue, encouraging analysts to dismiss or overlook them.
- No SOC. Without a security team, detection is often a matter of chance, depending on individual awareness and availability.
- No SIEM. Without security event management, relationships between data from devices, servers and authentication systems are harder to identify. Detecting connected events can therefore take longer.
- No alert analysis —without prioritisation, important events are easily missed while less significant ones receive attention.
What causes a high MTTR?
Common causes of a high MTTR — a long interval between incident detection and restoration of normal operation — include:
- No incident response process —clearly defined procedures that tell the SOC how to respond. Incident response also establishes team roles and responsibilities. Without them, actions can be disorganised, slow and ineffective.
- No playbooks —prepared response scenarios. Without them, the security team must plan from scratch for every attack instead of using experience and proven approaches. Playbooks shorten response times particularly for common incidents such as phishing, malware and account compromise.
- No exercises —tests and attack simulations. Regular exercises let the organisation check that procedures and scenarios work in practice. Without exercises, knowledge remains theoretical: the team has to recall processes each time, making its response slow and uncertain.
Learn more about incident response procedures:
How can you reduce detection and response times?
Reducing detection and response times requires two elements: standardised procedures and effective systems.
The entire incident handling process needs improvement, not just individual stages. Every element, from detection to restoring normal operation, has an equally important role.
EDR (Endpoint Detection and Response)
Rapid endpoint threat detection—EDR monitors computers and servers, detects suspicious behaviour and enables prompt action such as isolating an infected device. This can shorten detection time and limit an incident’s spread.
SIEM (Security Information and Event Management)
Centralisation and correlation of security events—SIEM collects data from sources such as EDR, authentication systems, applications and infrastructure, identifies relationships and generates alerts. It helps identify attacks sooner and gives analysts information for decisions.
SOC (Security Operations Center)
Alert analysis and response coordination—the SOC analyses alerts, prioritises them and initiates remediation. An experienced team, clear procedures and automated analysis can shorten the time between detection and the start of response.
Incident Response
Standardised incident response—established procedures define who should do what and when. They help avoid confusion, isolate threats sooner, remove the cause and limit impact, reducing MTTR.
Recovery
Prompt restoration of normal operation—effective recovery from backups, service restoration and security verification help bring incident handling to a close sooner. A well-prepared recovery process reduces downtime and the time needed to resume normal operations.
These measures work best together. Procedures and playbooks alone are insufficient if the SOC does not regularly practise attack simulations. Combining procedures with practice produces the best results. Specialists also need preparation that builds commitment and accountability, as well as the right tools.
How do you measure incident detection and response effectiveness?
KPIs are useful for measuring incident detection and response effectiveness. They are clearly defined, measurable business indicators. MTTD and MTTR can be treated as cybersecurity KPIs. These metrics should do more than measure elapsed time. KPIs should support specific business objectives, such as limiting the impact of cyberattacks on operations. Define Mean Time to Detect and Mean Time to Recover, their target values, the reporting period and which incidents are included. Illustrative targets might be 15 minutes for MTTD and 2 hours for MTTR, but they must reflect the risks, systems and recovery capabilities involved. They are measurement targets, not guarantees for every incident or automatically applicable SLAs.
Other KPIs that help measure detection and response effectiveness include:
- incident count —recorded cyberattacks and other security threats;
- escalation time —time to hand the incident to the appropriate people or teams, usually with more specialised expertise;
- isolation time —time to block or separate affected components.
As with MTTD and MTTR, each metric needs a business objective and target values.
Is your organisation genuinely ready to respond promptly to incidents?
Shorter detection and response times require systematic organisational changes. Low MTTD and MTTR result from planned action, not luck. Even excellent procedures cannot replace committed team members who know what to do and take responsibility for their actions.
Our checklist can help. It is designed for organisations of different sizes and sectors and can also be used by your company’s security team.
| Question | Answer |
|---|---|
| Do you measure MTTD? | YES / NO |
| Do you measure MTTR? | YES / NO |
| Have you set targets for both metrics? | YES / NO |
| Does monitoring operate 24/7? | YES / NO |
| Are all critical systems monitored? | YES / NO |
| Are alerts appropriately prioritised? | YES / NO |
| Are response playbooks up to date? | YES / NO |
| Are incident roles and responsibilities clearly defined? | YES / NO |
| Does the team regularly practise incident response? | YES / NO |
| After incidents, do you analyse delays and implement improvements? | YES / NO |
More ‘YES’ answers mean shorter detection and response times and stronger organisational security.
How does VigilHorizon help companies build rapid detection and response capability?
We look at effective cybersecurity management beyond MTTD and MTTR alone. Deploying technology, including 24/7 SOC monitoring, may not be enough to protect systems effectively. We build processes alongside it to avoid a disorganised response, with operational accountability that engages every team member in resolving problems. This approach works best for our clients.
Does your company need more effective threat monitoring and faster incident response? We can help you implement the changes. Contact us to arrange a security monitoring consultation.
Summary
Reducing attacks on company assets is a worthwhile goal, but prevention has limits. Incidents cannot be eliminated entirely. Rapid detection and effective response therefore matter. Measuring MTTD and MTTR is only a starting point. Your organisation can influence what happens after an attack. Effective 24/7 security systems help detect threats before they affect IT operations, while a capable SOC equipped with procedures and playbooks knows how to minimise the impact.
Frequently asked questions (FAQ)
What does MTTD mean?
MTTD, or Mean Time to Detect, is the average time taken to detect an incident.
What does MTTR mean?
In this article, MTTR means Mean Time to Recover: the average time from incident detection to restoration of normal system operation. Time to begin responding is measured separately.
How do you calculate MTTD?
MTTD is an average: add the detection times for incidents in the period being measured, then divide by the number of incidents.
How do you calculate MTTR?
Calculate MTTR by adding the time from detection to restoration of normal operation for each incident, then dividing the total by the number of incidents included. Apply the same measurement start and end criteria throughout the dataset.
How can incident response time be reduced?
Clear procedures, roles and responsibilities support faster incident response. Playbooks with response scenarios, regular exercises and attack simulations also help.
Does faster detection and response reduce the number of incidents?
Faster detection and response does not reduce incident numbers. It does, however, help limit their scope and impact.
How should detection and response effectiveness be measured?
Compare MTTD and MTTR over time, alongside other metrics such as incident count, escalation time and time to isolate an affected component.
What can cause a high MTTD?
A high MTTD may result from a lack of 24/7 monitoring, incorrectly configured alerts, insufficient incident analysis, no SOC or no SIEM-based event management.
What can cause a high MTTR?
A high MTTR may result from missing incident procedures, unclear roles and responsibilities, insufficient exercises or difficulties restoring services. Starting the response quickly is not enough if restoring normal operation takes a long time.
What does low MTTD combined with high MTTR mean?
A low MTTD and high MTTR mean incidents are detected quickly but restoring normal operation takes a long time. Review the full process, from response and threat containment through to service recovery.
Does a SOC affect MTTD?
Yes. SOC activities influence detection time, particularly monitoring quality, event analysis and accurate threat identification.
Can SIEM reduce MTTR?
A correctly configured SIEM can help reduce MTTR by providing logs, event correlations and information needed to investigate an incident. A SIEM does not itself restore services. Recovery time also depends on response procedures, technical teams, available backups and recovery infrastructure.
Learn more
- The first 60 minutes of a cyberattack: what really happens and why every minute counts
- Incident Response: responding to a cyberattack, step by step
- What is SOC 24/7, and why is monitoring not enough?
- Lateral movement: the attack stage most companies never notice
- EDR, XDR and MDR: how do they differ and when do they protect your company?
Related articles
Not sure which plan is right for your business?
Complete a short questionnaire
Complete the form and we will help you select monitoring, incident handling or availability support for your organisation. We will agree the scope and service conditions before work begins.


