liveBook · Manning

Time to respond

As explained in Data-Driven Cybersecurity

Time to respond is the elapsed time between detecting a security incident and taking a response or mitigation action.

Time to respond (TTR) is the elapsed time from detecting an adverse event to initiating a response. A shorter TTR means the team acts sooner, helping limit an incident’s effects. It does not include the time spent detecting the event. section 8.6.1

Check what the clock measures before comparing reports. Mean time to respond (MTTR) averages the time to respond to and mitigate detected incidents; time to contain measures another interval. MTTR can also mean mean time to report, so label dashboards and executive reports explicitly. section 6.3.2

From delayed alerts to a response priority

A data-management company took six hours to detect an event and another four hours to initiate a response. Analysts also faced 200 events a day and a 60% false-positive rate. Improving alert filtering and incident classification gave the team a way to reduce irrelevant work and respond more promptly; the response delay alone would not explain the bottleneck. section 8.6.2

Figure 6.6 On the left, the TechMed risk assessment dashboard before the risk management program is implemented. In this figure, the bottom metrics are displayed as a percentage to indicate the percentage of incidents that were within the predefined target of hours. For example, 40% of the incidents were detected within the 12-hour target detection time. On the right, the risk assessment dashboard after implementing the risk management program.

Compare response performance before and after the risk-management program, but read the dashboard units carefully: its lower metrics show the percentage of incidents meeting a time target, not simply an average time. section 6.3.3

Set a response target, track both typical time and the share of incidents meeting the target, and investigate misses. In one risk dashboard, a two-hour mean response time improved but still prompted a recommendation to streamline response protocols. For leadership, pair the timing with detection, containment, incident severity, and a specific action rather than treating one faster number as proof of lower risk. section 6.3.3 section 4.3.1

Time to respond is a useful traditional metric, but it is measured after events occur. Use it alongside measures and controls that help identify and address risks earlier. section 1.3

How Data-Driven Cybersecurity covers it

How deep it goes
Defines detection-to-action timing and interprets dashboard targets, but does not specify a timestamp-collection procedure.
Examples
Uses a four-hour response delay amid alert fatigue and a before-and-after risk dashboard with a two-hour response target.
What it assumes
Defines the timing measure directly while assuming basic familiarity with security incidents and dashboard metrics.
What you can do after
Evaluate/understand it by checking response delays against targets and recommending protocol improvements where incidents remain slow to address.
How it connects
Links time to respond with time to detect, time to contain, false-positive rate, incident classification, and incident response.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Data-Driven Cybersecurity. The section links point to the parts of the book it draws on.