# Mean Time to Respond (MTTR)
Mean Time to Respond (MTTR) is the average elapsed time between the moment a security incident is detected and the moment it is contained or fully resolved. It exists because detection alone does not stop an attack. An adversary who has been detected but not yet contained continues to move through the environment, exfiltrate data, and cause damage. MTTR quantifies the execution speed of the incident response function, translating response quality into a measurable number that security leaders, operations teams, and executives can track, compare, and improve over time. Where detection metrics reveal how visible the environment is to defenders, MTTR reveals how effective those defenders are at acting on what they see.
MTTR is calculated by dividing the total cumulative response time across all incidents in a measurement period by the total number of incidents. Response time, for each incident, is the elapsed duration from alert creation or confirmed detection through to the defined endpoint of response, which is either containment or full resolution depending on the organization's chosen methodology.
The metric is distinct from several adjacent measurements. Mean Time to Detect (MTTD) measures how long an attacker was present before discovery; MTTR begins where MTTD ends. Mean Time to Recover (also abbreviated MTTR in some frameworks) measures restoration of normal operations after a disruption, which is an IT continuity concept broader than the security response window. When the two share an abbreviation, context determines meaning. Mean Time Between Failures (MTBF) is a reliability engineering concept with no direct equivalence in security operations.
MTTR is not a measure of investigation depth or remediation completeness. An incident that is contained quickly but incompletely does not represent a good MTTR outcome, because containment without eradication often leads to reinfection or adversary re-entry. MTTR should therefore always be read alongside recurrence rate and eradication confirmation metrics.
---
The basic formula is straightforward: sum the response time (in hours or minutes) for every incident in the measurement period, then divide by the count of incidents. If five incidents were detected and resolved in a month, with response times of 2, 4, 6, 3, and 5 hours respectively, the MTTR is 4 hours. Organizations typically calculate MTTR across rolling 30-day, 90-day, and annual windows to spot trends.
The precision of MTTR depends entirely on accurate timestamping. Alert creation timestamps must be recorded automatically by SIEM or SOAR platforms. Containment actions must be logged with timestamps at the moment they occur, not retrospectively when an analyst closes a ticket. Any gap between actual containment and ticket closure artificially inflates or deflates MTTR depending on analyst behavior. Automation reduces this variability significantly.
Several variants of MTTR exist in practice:
Containment MTTR: Clock stops when the threat is isolated and prevented from spreading further. This measurement focuses on stopping lateral movement and data exfiltration but does not account for the time required to remove the threat entirely.
Resolution MTTR: Clock stops when the threat is eradicated and affected systems are restored. This measurement captures the complete response cycle but may discourage fast containment if analysts know they will be measured on the longer resolution timeline.
Severity-stratified MTTR: Separate calculations for critical, high, medium, and low severity incidents. This approach prevents high-volume low-severity events from obscuring delays in critical response. A phishing attempt blocked at the email gateway should not mask a six-hour response to ransomware deployment in the same monthly calculation.
Organizations that report only a single aggregate MTTR typically have less operational insight than those who track it by severity, incident type, and attack vector. The most sophisticated security programs measure MTTR at the sub-phase level, breaking down triage time, investigation time, containment time, and eradication time separately to identify specific bottlenecks.
MTTR covers four active phases, each with distinct objectives and typical duration patterns:
Triage: The alert is reviewed, classified, and determined to be a true positive. This phase ends when a responder confirms the incident and assigns it a severity level. Triage time is largely driven by alert volume and analyst availability. Organizations with high false positive rates experience longer triage times as analysts spend more time distinguishing real threats from noise.
Investigation: The scope of the incident is determined. Which systems are affected, what access was obtained, and what the attacker's apparent objective is become clear during this phase. Investigation time correlates strongly with log availability, tool integration, and analyst skill. Environments with comprehensive logging and centralized log analysis platforms typically show faster investigation times than those requiring manual log collection from multiple systems.
Containment: The threat is isolated. This may include blocking network segments, disabling accounts, isolating endpoints, revoking credentials, or blackholing malicious IP addresses. Containment prevents further lateral movement or data exfiltration. Containment time is heavily influenced by approval processes and automation capabilities. Pre-authorized playbook actions execute in minutes; manual approval processes can extend containment by hours.
Eradication: Malicious artifacts are removed. Persistence mechanisms, malware, compromised accounts, and attacker-planted tools are eliminated from the environment. Eradication time depends on the sophistication of the attack and the thoroughness of the response. Simple malware infections may be eradicated in minutes through automated removal tools, while advanced persistent threats requiring forensic imaging and complete system rebuilds can extend eradication over days.
Consider an organization that detects suspicious PowerShell execution on a workstation at 14:22 via endpoint detection and response (EDR) tooling. The alert is ingested into the SIEM and creates a ticket at 14:22.
Triage completes at 14:37 (15 minutes): The analyst reviews the PowerShell command line, confirms it is attempting to download a payload from an external IP, and escalates to the incident response team with a preliminary assessment of "likely compromise."
Investigation completes at 16:15 (113 minutes from detection): The IR team identifies that the PowerShell execution successfully downloaded and executed a Cobalt Strike beacon, which established command-and-control communication to an external server. Analysis of proxy logs reveals the beacon has been active for 23 minutes. Network monitoring shows one lateral movement attempt to a file server using stolen credentials, and one successful authentication to a domain controller.
Containment completes at 16:41 (139 minutes from detection): The workstation is isolated from the network, the C2 IP is blocked at multiple perimeter points, the compromised user account is disabled, and the file server is isolated pending investigation. The domain controller shows no signs of persistence installation and remains online under enhanced monitoring.
Eradication completes at 18:20 (238 minutes from detection): The beacon and associated artifacts are removed from the workstation, persistence registry keys are deleted, the workstation is reimaged with a clean operating system, the compromised user account is reset with new credentials, and monitoring confirms no C2 communication attempts from any internal systems.
If resolution MTTR is the chosen metric, this incident contributes 238 minutes to the period's total. If containment MTTR is used, it contributes 139 minutes. Both are valid measurements serving different operational purposes.
Several operational variables determine whether MTTR improves or degrades over time:
Playbook maturity: Documented, tested response playbooks reduce the cognitive load on analysts during an incident. Teams with mature playbooks follow established procedures that have been validated under controlled conditions. Teams without playbooks improvise, which takes longer and produces inconsistent outcomes. The difference is often a 2x to 3x improvement in containment time.
Automation and orchestration: SOAR platforms can execute containment actions in seconds that would take an analyst 20 minutes to perform manually. Automatic endpoint isolation upon EDR alert confirmation is a common automation that compresses containment time dramatically. However, automation without proper testing can also create operational problems that extend MTTR.
Tool integration: Response speed depends heavily on whether security tools share data and interfaces. A team that must copy an IP address from a SIEM alert, open a separate firewall management console, navigate to the appropriate rule section, and manually create a block rule is significantly slower than one that can issue a block command from within the SIEM interface.
Decision authority and approval processes: If containment actions require manager approval, response time includes waiting time for human availability. Organizations with pre-authorized playbook actions for defined alert types eliminate approval latency for the most common scenarios. However, this requires trust in both the playbooks and the analysts executing them.
Staffing patterns and shift coverage: MTTR for incidents detected during off-hours is typically 50% to 200% longer than for incidents detected during business hours. This reflects both reduced staffing and the tendency for complex decisions to be deferred until senior personnel are available.
---
MTTR directly determines how much damage an attacker inflicts after being detected. This relationship is not abstract or theoretical. IBM's annual Cost of a Data Breach report has consistently shown that organizations with shorter incident lifecycles experience significantly lower breach costs. The 2023 report found that breaches contained and resolved in less than 200 days cost an average of $1.02 million less than those taking longer than 200 days. Response time is a financial variable, not just an operational metric.
The practical consequence of high MTTR is that adversaries complete their objectives before defenders stop them. Most sophisticated attack campaigns follow a predictable timeline. Ransomware operators typically spend 2 to 14 days in an environment conducting reconnaissance, elevating privileges, and identifying high-value targets before deploying encryption. Nation-state APT groups often establish persistence and begin data collection within hours of initial access, then maintain presence for months or years while continuously exfiltrating information.
A security team that detects early indicators of compromise but requires 72 hours to achieve containment gives ransomware attackers sufficient time to deploy encryption across the entire environment. Detection without response speed provides minimal protection against time-sensitive attacks. In these scenarios, slow response is only marginally better than no detection at all.
The NotPetya ransomware campaign demonstrated how response time affects damage scope in a real-world scenario. Organizations that detected the initial infection and immediately isolated affected systems limited damage to individual workstations. Organizations that detected the infection but delayed isolation by hours due to approval processes or manual containment procedures experienced full domain compromise as the malware spread laterally through SMB protocol exploitation.
Maersk, one of the most severely affected organizations, reported that the attack spread to over 4,000 servers and 45,000 workstations within hours of initial detection. Post-incident analysis indicated that faster network segmentation could have limited the spread significantly, but manual approval processes for network changes prevented rapid containment. The estimated cost to Maersk exceeded $300 million. FedEx subsidiary TNT Express experienced similar lateral spread and reported $400 million in costs.
Several misconceptions about MTTR persist in security operations:
Low incident volume equals good MTTR: Organizations sometimes interpret fewer incidents as evidence of effective response capabilities. These metrics are unrelated. Low incident volume may indicate poor detection capabilities rather than strong response performance. An organization that detects one incident per month and responds in 24 hours has worse security posture than one that detects 50 incidents per month and responds in 2 hours average.
Fast closure equals fast response: MTTR can be artificially compressed through premature incident closure. If analysts mark incidents as resolved before eradication is confirmed, the metric appears favorable while attacker persistence remains in the environment. This is a common problem in organizations where analysts are measured primarily on ticket closure speed rather than response quality.
MTTR is a SOC-only metric: Response time is affected by every team that participates in containment actions. Network engineering teams control firewall rule implementation. System administrators control account management. Legal teams control external communication and law enforcement notification. Executive teams control major business decisions like system shutdowns. MTTR improvement requires coordination across all these functions, not just SOC optimization.
---
CDA approaches MTTR through the Threat Intelligence and Defense (TID) domain of the Planetary Defense Model, with Predictive Defense Intelligence (PDI) as the guiding methodology. The PDI principle, "See the threat before it sees you," fundamentally reframes MTTR from a reactive measurement into a forward-planning discipline.
Rather than optimizing response time only after incidents occur, CDA's approach uses threat intelligence to pre-build response infrastructure aligned to the most probable attack paths. Before a ransomware group known to target the client's industry activates an intrusion, CDA analysts have already reviewed that group's tactics, techniques, and procedures (TTPs), mapped them to the client's environment, and confirmed that containment playbooks address every phase of that group's known methodology. When an incident matching those TTPs occurs, the response team is not learning in real time. They are executing a pre-validated playbook against a known adversary pattern.
This intelligence-driven preparation typically reduces MTTR by 40% to 60% for incidents that match known threat actor profiles. The time savings come from eliminating investigation steps that would otherwise be required to understand attacker objectives and likely next actions. If intelligence indicates that a detected lateral movement tool is typically followed by credential harvesting from domain controllers, the response team can immediately implement domain controller protection measures rather than waiting to observe the next phase of the attack.
CDA measures MTTR at the sub-metric level for all severity-one and severity-two incidents, tracking triage time, investigation time, containment time, and eradication time separately. This granularity allows identification of bottlenecks that aggregate MTTR conceals. If containment time increases across a quarter while other phases remain stable, the cause may be a change in approval authority structure, a new tool integration gap, or a staffing shift pattern rather than a degradation in analyst capability.
CDA also correlates MTTR trends with threat intelligence feeds to identify structural speed disadvantages. If external intelligence indicates that a specific threat actor typically moves from initial access to lateral movement within four hours, and the organization's current investigation MTTR is six hours, that gap represents a mission-critical risk. The organization is structurally slower than the adversary's operational tempo. Remediation of that gap becomes a prioritized recommendation with specific automation and process improvements.
Automation deployment in CDA's methodology is threat-aligned rather than generic. Automation is targeted at the containment and triage steps where threat intelligence indicates the greatest time pressure, ensuring that the seconds saved by automation are the seconds that matter most against the specific adversaries likely to target the client.
---
---
---