Prophet Security will be at RSA 2026. Stop by the booth or meet us 1:1.
.avif)
-min.webp)
Most SOC teams measure mean-time-to-respond (MTTR). The metric itself has become a fixture in board decks and vendor pitches alike, but the operational reality is more granular: MTTR is a trailing indicator shaped by decisions made long before an analyst opens a ticket. MTTR spans several phases — detection, triage, investigation, and response — and investigation is typically one of the larger addressable slices. In environments without significant automation, investigation alone accounts for the majority of the elapsed time between an alert firing and a decision being made. Getting that window under control is one of the most direct paths to moving MTTR below the “left of boom” threshold, where the response is still meaningful rather than retrospective.
Reducing it meaningfully, to the point where initial investigation consistently lands under two minutes, requires changes to how alerts are enriched, how context is assembled, and how much cognitive load falls on the human in the loop. The path is less about speed and more about eliminating the investigative steps that shouldn't require a human in the first place.
MTTR, as commonly reported, conflates several distinct phases: detection, triage, investigation, and response. A team can report a 15-minute MTTR while still spending 80% of that window on manual enrichment, pivoting between consoles, copying IOCs into search bars, and reading documentation to understand what a detection rule was even trying to catch. The number looks reasonable on a slide. It obscures the friction.
If we zoom in the triage and investigation phases, The more useful decomposition separates time-to-context from time-to-decision. Time-to-context is the interval between an alert firing and an analyst having enough enriched, correlated information to form a judgment. Time-to-decision is the interval between that point and a disposition or escalation. In most SOCs, time-to-context dominates. Analysts are not slow thinkers. They are fast thinkers trapped in slow toolchains.
.png)
When organizations set a target like sub-2-minute investigation, the question worth asking is: what has to be true about the environment, the data, and the workflow for that to be achievable without cutting corners?
Understanding where minutes go during triage is prerequisite to compressing them. Based on operational patterns across mid-to-large SOCs, the breakdown tends to follow a consistent shape:
Alert-to-context assembly accounts for the largest share. This includes pulling asset context (who owns this host, what business unit, is it a domain controller or a developer laptop), user-context (is this a service account, a privileged user, someone on PTO), and threat intelligence enrichment (has this hash, domain, or IP been observed elsewhere, and with what confidence). In environments relying on SIEM-centric workflows, this step alone can take five to ten minutes per alert because the analyst is the integration layer between systems that don't talk to each other natively.
Historical correlation is the second major consumer. An analyst looking at a suspicious login needs to understand whether this user has authenticated from this geography before, whether the source IP has appeared in other alerts, and whether the host has exhibited related telemetry in the preceding hours or days. Running these queries manually, often across multiple tools, adds minutes and introduces variability based on analyst experience.
{{ebook-cta}}
Documentation and decision framing rounds out the cycle. Even after context is assembled, the analyst needs to map what they see against a mental model of what's normal for this entity. Junior analysts spend more time here, not because they lack intelligence, but because they lack the accumulated pattern recognition that comes from years of exposure to a specific environment.
Compressing investigation time to under two minutes is an architectural problem, not a personnel problem. It requires pre-computation, not faster clicking.
The single highest-leverage change a SOC can make is shifting enrichment from query-time to ingest-time. Every alert that reaches a human should already carry asset context, identity metadata, threat intelligence verdicts, and historical behavioral baselines. This is conceptually straightforward but operationally demanding because it requires reliable integration with asset inventories, identity providers, TI platforms, and log repositories.
The enrichment should not be a flat dump of raw data. It should be structured around the specific detection logic that fired. If a rule triggers on a lateral movement pattern, the enrichment package should immediately show the analyst the source and destination host roles, the authentication method, and whether the credential used has been observed in recent password spray activity. Generic enrichment adds noise. Detection-aware enrichment adds signal.
An alert about a single event is rarely sufficient for disposition. Analysts need to see the event in the context of what else that user, host, or IP has done recently. Automating this correlation, so that related alerts, raw logs, and behavioral anomalies are grouped and presented alongside the primary alert, removes the most time-intensive manual step in triage.
The key design principle is entity-centric correlation: grouping activity by user, device, or network entity rather than by detection rule or data source. This mirrors how experienced analysts naturally think. They don't investigate a "brute force alert." They investigate what a particular account has been doing, and the brute force alert is one data point in that picture.
There is a meaningful difference between giving an analyst access to data and giving them an answer they can evaluate. Raw log output requires parsing. A timeline of entity activity, annotated with risk signals and historical baselines, requires judgment. The goal is to present information at the level of abstraction where a skilled analyst can confirm or challenge a hypothesis in seconds rather than constructing one from scratch.
This is where recent advances in large language models (LLMs) have introduced a practical capability shift. LLMs can synthesize enriched telemetry into natural-language investigation summaries that explain what happened, why it's anomalous, and what the likely risk is, in a format that reads like a senior analyst's case notes. The value is not in replacing analyst judgment but in compressing the time between "I see this alert" and "I understand what I'm looking at."
By segmenting the total Mean Time To Resolution (MTTR) into a diagnostic set of component metrics, you gain the necessary insight to strategically apply leverage for improvement.
Time-to-context (TTC): Measured from alert creation to the point where enrichment and analysis are complete and available to the analyst. In theory, this should be near-zero because the work is done at machine speed.
Analyst interaction time: The actual seconds an analyst spends actively working an alert before final disposition. This is distinct from queue wait time and measures the efficiency of the investigation interface itself and overall analyst confidence in the AI.
Escalation accuracy: The percentage of escalated or closed alerts where the disposition is later confirmed as correct. In tier-less or AI-assisted SOC models, this metric captures investigation quality directly: a low rate indicates analysts lacked sufficient confidence in the AI’s final judgement and output, leading to longer investigation cycles.
Automated disposition rate: The share of alerts that are resolved without human interaction. This metric should trend upward over time as the system learns which alert patterns consistently resolve as benign or simply as “no further action required”.
The progression from manual enrichment to pre-computed context to AI-generated investigation summaries follows a logical arc. Each layer removes a category of toil from the analyst's workflow. AI-driven investigation, when implemented well, serves as the final compression step: it takes enriched, correlated data and produces a structured assessment that an analyst can validate rather than build from scratch.
The risk, worth naming plainly, is that poorly implemented AI creates a false sense of coverage. If the model hallucinates context, misattributes activity, or generates confident-sounding summaries from incomplete data, it erodes trust faster than it builds efficiency. The implementation details matter enormously. The model needs access to the full enrichment pipeline, grounding in the organization's specific environment, and transparency in how it arrives at its conclusions so that analysts can spot errors quickly.
When those conditions are met, the operational impact is substantial. Investigation workflows that previously required five to fifteen minutes of manual assembly can be compressed to the time it takes an analyst to read a summary, check the supporting evidence, and render a verdict. That is how sub-2-minute investigation becomes repeatable rather than aspirational.
The investigation phase is a critical and sizable component of what constitutes MTTR. Compressing it to under two minutes — consistently, not occasionally — has a direct and material effect on the overall metric. Getting there. It requires shifting enrichment upstream, automating correlation at the entity level, and presenting analysts with structured assessments rather than raw data. The technology to do this exists today, and the organizations achieving these benchmarks are the ones treating investigation speed as an architectural outcome rather than an analyst performance metric.
Download the ebook: How Agentic SOC overcomes the limits of queue-bound security operations.
.svg)
-min.avif)
-min.avif)
