When I worked SOC shifts, I knew every extra minute an alert sat untriaged was another minute an attacker had to move deeper into the network.
Getting from "alert fired" to "threat actually contained" took anywhere from twenty minutes to several hours, depending on the day.
Of course, severity mattered. But the moment a sensor flagged the anomaly and the first analyst opened the ticket, the clock was already running.
Now I sit on the other side of that conversation. Every week I talk with SOC leads across finance, telecom, and healthcare, and after the initial call I usually ask to go one layer deeper. Not into tooling. Into time.
Because there is a window in every incident that almost nobody measures. It starts when an alert fires and it closes when the threat is actually, verifiably contained.
The detection-to-containment gap is the time between an alert firing and a confirmed containment action. It costs security teams twice — once in the dwell time that lets an attacker do more damage, and once in analyst hours spent chasing context that should have been attached to the alert from the start.
Most teams I talk to have never measured either half.
Why the Clock Starts at the Alert, Not the Ticket
An alert does something to an environment. Somewhere, a process is running, a connection is open, a device is behaving abnormally. That is the high-water mark of exposure.
Everything after the alert fires is a race against decay — not of urgency like a sales deal, but of blast radius.
Every extra minute created an opening for:
- Lateral movement to a second host
- Data staging or early exfiltration
- Persistence mechanisms to get more deeply embedded
So analysts were constantly racing the clock. Not because anyone was slow — because the process put a context-gathering step between the alert and the response.
The Work That Never Makes It Onto the Dashboard
Here is what a "twenty-minute" incident actually looked like.
The analyst pulled the alert, then had to pivot across three or four different tools to get flow context, check whether the source IP had history, correlate against other sensors, and confirm scope before touching anything.
None of that showed up on the mean-time-to-detect chart. It showed up as time spent open in a browser tab, invisible to the SOC metrics dashboard.
When I ask SOC leads how long triage actually takes end to end, the first answer is usually a guess based on the SLA target, not reality. The second answer, after pulling ticket timestamps, is almost always higher.
The Questions I Ask Security Leaders
If we cannot speak in time and dollars, we are only having half the conversation. So these are the questions I bring to the second call:
- From alert fired to first human eyes on it, what is the average time?
- From first eyes to a documented, verified root cause, how long does that take?
- How much of that time is spent gathering context versus actually deciding?
- What percentage of alerts get escalated and then de-escalated as false positives, after consuming analyst time?
- How many incidents required a second pass because context was incomplete the first time?
Here is what I have realized. Most teams do not actually track this end to end.
And honestly, I get it.
Why Dwell Time Never Shows Up on the Board Report
There is no clean line item that says, "this incident was worse because of an eighteen-minute context-gathering step." But it is there.
It shows up in wider blast radius. It shows up in analyst burnout from chasing the same five systems for context on every ticket. It shows up when leadership asks how long an attacker was actually in the network, and the honest answer stings.
Over time, it becomes one of the quietest ways a security program's real-world effectiveness diverges from what the dashboard reports.
Two Costs, One Root Cause
For a long time, I thought of speed and accuracy as separate problems. Speed was a tooling problem. Accuracy was a training problem.
They are the same problem, measured from opposite ends.
When flow context, threat history, and device behavior live in three different tools, an analyst cannot act until it is manually reconstructed. Reconstruction takes minutes — sometimes many — and that is exactly the time an attacker gets to keep moving.
The delay and the missed context come from the same source: data that requires manual correlation instead of arriving pre-joined to the alert.
The Quiet Math on Your Own Gap
You do not need perfect data. You need a number that makes the tradeoff visible. Pull your last ten material alerts and fill this in.
Step one: measure the gap.
- Average minutes from alert fired to verified containment = 47
Step two: the response-speed side.
- Material alerts per month = 640
- Escalations resolved within 5 minutes, automated = 82%
- Escalations resolved in over 30 minutes, manual = 18%
The spread between those two response times, applied to your monthly alert volume, is your exposure window. Most teams have never split their response time this way, and the first look is uncomfortable.
Step three: the analyst-time side.
- Analysts on shift = 6
- Hours lost per week, per analyst, to manual context-gathering = 9
- Blended fully-loaded hourly rate = $85
Multiply those three. Then add the cost of any incident that required a second, deeper investigation because scope was misjudged the first time.
Two numbers. One is the exposure window you are carrying every day. One is the analyst capacity you are burning on work a machine could do. Neither one appears on a single report today.
Try This With Your Team This Week
Pick one recent alert that felt normal but took longer to close than it should have. Then answer three questions together.
- What was the very first piece of context someone had to go find manually?
- Where did that information live, and why wasn't it already attached to the alert?
- How many minutes passed between the alert firing and containment, and what filled them?
That last question is the one that tends to change the room.
Where NGNTA Fits
NGNTA was built to shorten that gap.
Because flow data, threat scoring, and packet-level context are captured continuously and tied to the same alert automatically, analysts spend far less time reconstructing what happened after the fact. The evidence is already attached when the alert fires.
Real-time automated mitigation means many alerts never reach a human queue at all — they are contained the moment risk crosses a defined threshold, and logged for review afterward instead of before.
Speed to containment is not just an efficiency metric. It shrinks blast radius. It reduces analyst burnout. And it gives your leadership team a straight answer when they ask how long an attacker was actually in the environment.
The SOCs that are going to keep pace with this threat landscape are not just the ones buying more tools. They are the ones who understand exactly where their time goes between alert and containment — and close the gap.
Because more alerts is not the goal. Faster, cleaner containment is the goal.
Are you measuring your detection-to-containment gap today, or is it still hidden inside your ticket queue?
FAQs
It is the time between when a sensor or analyst first flags a threat and when that threat is confirmed contained. For teams relying on manual correlation across multiple tools, that gap commonly runs from thirty minutes to several hours per incident.
Start with material alerts per month, multiplied by the average minutes of manual context-gathering per alert, multiplied by your blended analyst hourly rate. Then factor in the increased likelihood of lateral movement or data staging for every additional minute of dwell time.
Attacker access compounds. Every additional minute increases the chance of lateral movement, privilege escalation, or exfiltration — and gives the incident more time to become a headline instead of a footnote.
Most delay traces back to context that has to be manually gathered after an alert fires rather than being attached to it automatically — flow history, device behavior, and threat intelligence spread across disconnected tools.
Usually not on its own. Delay and missed context share the same root cause: fragmented, manually-correlated data. Adding analysts increases capacity to manually reconstruct that context, but it does not remove the reconstruction step itself.
Marcus Webb Marcus is a Senior Threat Analyst at NGNTA, focused on detection engineering and SOC workflow design. He spent six years running incident response for mid-market enterprises before joining NGNTA.