The answer doesn’t have to be collecting less.
It can be building a smarter security data architecture around the technology you already use.
One that lets you capture and retain the evidence, control which events need to reach the SIEM, retrieve historical data when an investigation requires it and, increasingly, interrogate that data proactively to uncover anomalies and potential threats.
That’s where the security logging conversation is heading, and it’s no longer a fringe idea.
In its Hype Cycle for Security Operations, 2026, Gartner describes the SIEM market as splitting in two directions. Alongside the classic SIEM model, integrated SOC platforms are consolidating detection and response into a single vendor experience. A separate category, security data lakes, is emerging specifically to give security teams a more cost-effective way to store and retain data, without forcing a choice between ingesting everything and paying for it, or ingesting selectively and risking blind spots.
Forrester has been making a similar point directly to CISOs.In Top Recommendations For Your Security Program, 2025, Forrester’s guidance to security leaders managing platform costs is direct: adopt data pipeline management tools to reduce SIEM ingest costs and make it easier to migrate data between platforms down the track.
Neither firm is describing a workaround. They’re describing where the architecture is heading, and it’s the model Snare has been built around.
Traditional security architectures often follow a fairly direct path:
An endpoint generates an event. The event is collected. The SIEM ingests it. The organization pays to process and retain it.
Most SIEM platforms price on daily ingest volume (GB/day) or events per second (EPS), so cost scales directly with what gets sent, regardless of how much of it a detection rule ever actually touches.
Multiply that across thousands of endpoints, applications, cloud services and infrastructure platforms and the economics become significant very quickly. It’s also part of why SOC teams routinely report alert volumes that outpace what any analyst team can reasonably triage, Forrester Consulting’s research into security operations has long put the average above 11,000 alerts a day, and it remains one of the most cited benchmarks for just how saturated a SIEM-first model can become. Every one of those alerts traces back to an ingestion decision made somewhere upstream.
The two don’t have to be the same thing.
An organization may generate millions, or billions, of events that it wants to preserve for investigation, compliance or forensic purposes.
Only a proportion of those events may need immediate SIEM analysis.
Reducing SIEM ingestion has traditionally created an uncomfortable question:
What if the log we don’t send today is the log we need six months from now?
That concern is legitimate.
An event that appears routine in isolation may become significant when an analyst discovers that an attacker was present in the environment weeks or months earlier.
A successful investigation frequently expands backwards.
A suspicious login leads to an endpoint.
The endpoint leads to a process.
The process leads to a privilege change.
The privilege change leads to earlier activity.
Suddenly, yesterday’s investigation becomes a search across months of historical events.
This is why retaining security evidence remains important.
The goal shouldn’t be to throw data away simply because sending it all into the SIEM is expensive.
The better approach is to separate security-data retention from SIEM ingestion, which is precisely what Forrester is now recommending CISOs do directly: use dedicated data pipeline management to control what reaches the SIEM, rather than letting the SIEM’s price tag dictate what gets collected in the first place.
That means organizations can retain far greater volumes of security data economically while selectively routing the information that needs immediate analysis into their SIEM and other security platforms.
And when historical data becomes relevant?
Retrieve it.
Replay it.
Investigate it.
Instead of seeing logging simply as a pipeline into the SIEM, consider it as an independent security data layer:
Security investigations are only as good as the underlying data.
Windows Security Event Log activity (logon/logoff events, process creation, privilege use), Sysmon and EDR telemetry, Linux auditd and syslog output, identity provider sign-in and audit logs, cloud control-plane logs such as AWS CloudTrail, Azure Activity Log and GCP Audit Logs, and network telemetry including firewall, proxy, DNS and NetFlow data, each can become a critical piece of an investigation, often only in combination with the others.
Before every event is forwarded downstream, organizations should have control over it.
Logs can be normalized, aggregated, de-duplicated, filtered and transformed according to the organization’s requirements, parsing raw events into a consistent schema (increasingly OCSF or a comparable vendor-neutral model, rather than a proprietary format that locks data to one platform), collapsing duplicate events at the source, filtering out high-volume, low-signal event types, and enriching what remains with asset and identity context before it goes anywhere else.
This isn’t about blindly eliminating data.
It’s about managing security telemetry intelligently.
A security event doesn’t stop having value because it wasn’t immediately suspicious.
Historical evidence can become critical during incident response, forensic investigation, threat hunting, compliance reviews and audits, often long after the fact, given how long breaches typically go undetected.
Keeping that data outside premium SIEM storage allows organizations to retain substantially greater volumes for longer periods without carrying the equivalent SIEM storage cost.
The SIEM remains an important part of the security stack.
The objective isn’t to replace it.
It is to make better use of it.
High-value security telemetry can continue to be routed into platforms such as Microsoft Sentinel, Splunk, Google SecOps, Elastic, Securonix and other existing security tools, in the format and protocol each one expects, whether that’s syslog, CEF or a structured JSON feed.
The difference is that the organization controls what gets sent.
That can reduce unnecessary ingestion while preserving the underlying evidence elsewhere.
When an investigation expands, historical events can be brought back into the investigation.
Instead of discovering that the relevant logs have aged out of the SIEM or were never retained, security teams can return to the underlying evidence.
That changes the economics of long-term visibility.
Organizations no longer have to choose between keeping the logs and controlling the cost.
They can do both.
There is another important change happening.
Historically, retaining large volumes of security data was primarily about ensuring the evidence existed if somebody needed it.
But finding something inside years of security telemetry could still require considerable analyst time and specialist querying.
AI changes that equation, though it’s worth being precise about what kind of AI is actually doing the work.
Gartner’s 2026 Hype Cycle draws a useful distinction here. On one side sit “cybersecurity AI assistants”, generative AI features that let analysts query the tools they already use in natural language. On the other are “AI SOC agents,” a newer and largely unproven category of autonomous, cross-stack decision-makers that Gartner currently places at the Peak of Inflated Expectations, with explicit warnings for buyers to pilot rigorously and demand transparency, given how loosely the word “agent” is now being applied across the market.
AskSnare sits firmly in the first camp, by design. It gives security teams a natural-language way to interrogate their own retained security data and proactively search across the available evidence for anomalies, suspicious behaviors and indicators that warrant further investigation, grounded entirely in the evidence Snare has already captured, with a clear line between the question an analyst asks and the underlying logs behind the answer.
Which accounts showed unusual authentication activity this week?
Were there privilege changes associated with those users?
Show me unusual PowerShell activity across these endpoints.
Did this behavior occur anywhere else in the environment?
When did we first see activity associated with this account?
That creates a different relationship with retained security data.
Logs are no longer simply something you store in case you need them.
They become an intelligence resource that can be continuously questioned.
This is particularly important as cyberattacks become faster and increasingly automated.
Security teams need to be able to investigate an alert quickly, but there is also an opportunity to move beyond purely reactive investigation.
AskSnare can help security teams interrogate the underlying event data to look for activity that deserves attention before it becomes an obvious incident.
That means the security data layer can support both:
Something has happened. What happened, when did it start and what else was affected?
and
What looks unusual? What has changed? What activity doesn’t fit the expected pattern?
The underlying logs are the same.
What changes is the organization’s ability to extract intelligence from them.
One of the important aspects of this model is that it doesn’t require organizations to replace their existing security architecture.
Organizations can continue using their existing SIEM, SOC processes, security analytics and incident response tools.
Snare sits underneath that environment as the security-data layer.
Snare Agent captures forensic-grade event data at the source.
Snare Central provides centralized control, management and cost-effective retention, normalizing, aggregating and de-duplicating events before they reach downstream systems.
Snare Reflector provides additional flexibility over the transformation and routing of security data, regardless of the format or protocol each destination platform expects.
AskSnare provides the intelligence layer, allowing security teams to interrogate the underlying data and investigate potential anomalies and threats using natural language.
The result is not another technology stack that has to replace what is already there.
It is an additional layer that makes the existing stack work harder.
And because Snare can be implemented alongside existing environments, organizations can start improving the way they collect, retain and route security data without undertaking a major security-platform transformation.
The future of security logging isn’t necessarily about generating less data.
Organizations will almost certainly generate more.
More endpoints.
More cloud services.
More identities.
More applications.
More AI agents.
And inevitably, more logs.
The opportunity is to change what happens to that data.
Instead of forcing every event into the most expensive part of the security stack, organizations can retain their security evidence cost-effectively and control which events need immediate SIEM analysis.
Instead of losing historical visibility when SIEM retention periods expire, they can retrieve and replay the evidence when an investigation demands it.
And instead of treating retained logs as passive archives, they can use AskSnare to actively interrogate the data for answers, anomalies and potential threats.
How do we deal with all these logs?
How much more security value could we get from the logs we already have?
With the right security data architecture, organizations don’t have to compromise between visibility, retention, investigation and cost. And they’re not alone in reaching that conclusion, it’s where Gartner and Forrester both see the market heading next.
Keep the evidence.
Control the flow.
Reduce the cost.
Find the answers.
That’s the role Snare can play in the modern security stack.
Gartner, Hype Cycle for Security Operations, 2026, Darren Livingstone and Jonathan Nunez, 5 June 2026.
Forrester, Top Recommendations For Your Security Program, 2025, recommendation: “Reduce your SIEM bill with data pipeline management.”
Forrester Consulting, security operations research on SOC alert volumes (commissioned study; widely cited industry benchmark of 11,000+ alerts per day).
IBM, Cost of a Data Breach Report 2026, released 29 July 2026 (mean time to identify and contain a breach: 247 days).
ISO/IEC 27001:2022, Annex A Control 8.15 (Logging), and related controls 8.16 (Monitoring Activities), 8.17 (Clock Synchronization) and 5.33 (Protection of Records).
Gartner and Forrester do not endorse any vendor, product or service depicted in their research and do not advise technology users to select only those vendors with the highest ratings. References above reflect Snare’s interpretation of publicly available analyst and standards commentary and are not sponsored by or produced in partnership with Gartner, Forrester, IBM or ISO.
