By Tom Hofmann, VP Solutions, Ocient National Security Solutions
In conversations with security teams at large financial institutions this year, one theme keeps coming up: investigations that end early because the relevant telemetry aged out before anyone knew to look at it. We wanted to test whether the public data supports what we keep hearing. It does, and the numbers are worth laying side by side.
How long attackers operate
Mandiant’s M-Trends 2025 report puts global median dwell time, or the time an attacker remains undetected inside a compromised network before being discovered, at 11 days for the calendar year 2024 which is up from 10 the year before, and 26 days when the organization typically learned of the compromise from an external party (M-Trends 2025). The following year’s report, M-Trends 2026, shows the metric worsening again, to 14 days. That is two consecutive years moving in the wrong direction, which Mandiant’s own data had not previously shown back to back (M-Trends 2026). CrowdStrike’s 2025 and 2026 Global Threat Reports track a related but distinct metric at the other end of the timeline, breakout time: how long it takes an attacker to move laterally once they have a foothold. That number fell to 48 minutes in the 2025 report and 29 minutes in the 2026 report (CrowdStrike). Read together, the two data points describe the same widening problem from opposite ends: attackers are moving inside the network faster than ever, while the industry’s median time to notice them is getting slower, not faster.
Median dwell also understates the investigation problem. IBM’s Cost of a Data Breach 2025 puts the average full breach lifecycle, from identification through containment, at 241 days (IBM). The question an IR (Incident Response) team asks is rarely “what happened this week”; it is “when did this start, and what else did they touch.”
How long the telemetry survives
Against those timelines, the compliance baseline adopted by most regulated institutions is instructive: PCI DSS v4.0 requires at least 12 months of audit log retention, with only the most recent three months required to be immediately available for analysis (PCI Security Standards Council). That is a regulatory minimum, not a best practice, and it draws the same line the industry draws in practice: a short hot window, with everything older treated as a different, less accessible tier. Moving data out of that hot window and back into it, when an investigation needs it, is itself a cost and a delay. Archive-tier retrieval is a well-known operational pain point for security teams, one of the reasons “keep everything searchable” and “keep costs under control” have historically been treated as opposing goals rather than a solvable engineering problem.
The arithmetic
Put the two clocks on one axis and the gap stops being abstract. The hot window that regulation treats as immediately available runs out at roughly 90 days. The average breach is not identified and contained until day 241. The stretch in between is the evidence an investigation most needs, and the evidence it is least likely to still have. The teams we talk to do not need convincing that this is a gap; several described exactly this arithmetic to us, unprompted. The industry data simply confirms the conversations.
And that is only the data that was kept. A 2026 Dynatrace survey of 450 senior IT and security leaders at large enterprises found that organizations exclude an average of 86% of their log data from ingestion, storage, or analysis to manage cost and system limits, and that existing log tooling now consumes 45% of the average observability budget (Dynatrace, via Help Net Security).
There’s an analogy one CISO used in a conversation with us that has stuck: it’s like TSA screening one in every five, or one in every ten, passengers boarding a flight. Everyone else walks through. Most of them are exactly who they say they are. But the airport isn’t actually screening its passengers, it’s screening a sample of them, and calling it security. That is close to the arithmetic a lot of security teams are running today, whether they’d put it in those terms or not. Full-fidelity telemetry gets filtered, sampled, or aged out before anyone knows which records will matter, and the gaps aren’t random with respect to what an investigator needs; they land on exactly the older, quieter activity that a patient attacker is counting on.
The two workarounds, and why the gap survives them
Framed at the level every security and infrastructure leader actually has to choose at, the decision has looked like this for years: retain everything, and watch storage and compute costs climb until performance degrades and the budget conversation eats the security conversation; or filter, sample, and pre-aggregate to control that cost, and accept that you have built holes into your own evidence before you ever needed it. Neither side of that trade-off is a strategy so much as a forced choice, and the industry has produced two categories of response that sit on either side of it.
The first filters events before they reach the analytics tier: in-stream tools determine which data warrants expensive analysis and route the rest to lower-cost object storage. This genuinely controls spend, but the full-fidelity copy lands in a tier with no indexes, where every historical question becomes a scan job. The vendors in this category are candid that the cold tier suits audits and after-the-fact forensics, not live investigation. The second response stores everything cheaply in cloud analytics platforms, but these are typically consumption-priced (often per query or per GB scanned), which quietly penalizes the exact behavior an investigation requires: iterating on questions against large histories. In both cases the evidence is technically retained and practically out of reach.
The gap that survives both workarounds is specific: full-resolution telemetry that is simultaneously years deep, indexed, and interactively queryable, at network-telemetry volumes. That combination is the hard engineering problem, and it is the one the OcientAIQ Unified Data Platform was built to solve: analysis across trillions of rows returning in seconds, at data rates large network operators generate, on infrastructure you control, at a fixed cost that does not meter curiosity.
What makes that solvable rather than just a better trade-off is that the three things a growing telemetry problem actually strains, namely the rate data can be loaded, the amount of history that can be stored, and the amount of query workload the system can serve at once, do not have to compete for the same resources. OcientAIQ solutions scale each of them independently and linearly: add nodes for more ingest throughput, add storage for more retained history, add SQL compute nodes for more concurrent analytic workload, in whatever combination the environment actually needs. That is a different proposition than the traditional choice between “retain it all and let costs and performance both suffer” and “filter aggressively and accept the holes,” and it is the reason organizations running OcientAIQ at petabyte and exabyte scale often find their total cost of ownership lower than what they were already paying for a smaller, gappier version of the same visibility.
What changes when the window exceeds the dwell
This is where we think the discussion should focus: not on the gap, but on the capability that appears when retention finally exceeds attacker timelines.
With multi-year, full-resolution telemetry that stays interactively queryable, three questions change from unanswerable to routine. “When did this actually start?” becomes a query over the complete timeline rather than an extrapolation from the surviving window. “Has this new indicator ever appeared here?” becomes a retrospective sweep instead of a forward-only watch. And “what does normal look like for this host?” gets a baseline with real history behind it, including the monthly and quarterly rhythms that a four-week window cannot capture.
OcientAIQ solutions are built for exactly this: full-resolution retention measured in years, with interactive query against it. Multi-year retention only solves half the problem, though. The other half is what happens when someone actually runs the query. A platform that lets you keep everything but takes hours to search across it just moves the bottleneck downstream. The reason full retention stays interactive at petabyte scale, rather than degrading into the kind of scan job that makes analysts avoid asking the question in the first place, comes down to indexing: the OcientAIQ platform builds multiple indexes across the columns in a table at load time, not just one, so a query doesn’t have to fall back to scanning raw rows once the data outgrows a single index’s usefulness. That is a meaningfully different architecture from the pipeline-plus-cold-tier pattern described above, and it is one of the reasons some of the customers we work with tell us they can’t find another platform that does what we do at this scale.
Contact us to learn more.