How Security Data Lakes Reduce SIEM Costs and Improve Investigations

‍

A 2026 report found that cyber espionage intrusions and North Korean IT worker operations stayed undetected for a median of 122 days in 2025, with some lasting more than a year. A security team keeping 90 days of searchable telemetry in its SIEM would, in a typical case from that group, open its investigation about a month after the logs showing initial access had aged out.

Most security teams know this tradeoff well. Every new endpoint agent, cloud account, and identity provider adds telemetry, and holding all of it in a SIEM's analytics tier costs money that grows with the data. So retention windows shrink, or noisy sources never get onboarded at all.

A security data lake changes the terms of that trade. It gives telemetry a lower-cost place to live while keeping historical data searchable for investigations, threat hunting, and analytics.

Why SIEM Costs Increase as Security Data Grows

SIEM cost tends to follow data. As organizations ingest and retain more security telemetry, the volume they send, the storage they hold, the compute they run, and the queries analysts execute all become part of the platform's total cost.

The growth comes from several directions at once. Endpoint detection agents record process, file, and network activity on every managed device. Cloud and SaaS platforms produce audit and control-plane logs for each new account and application, and identity providers log every authentication and privilege change. Network sensors add DNS, proxy, and flow records that run to high volumes on their own, while application logs grow with every service a development team ships. Retention requirements from regulators, cyber insurers, and internal policy also tend to lengthen over time, and investigations ask for more of that history when they happen.

Pricing models vary. Some SIEMs charge by volume ingested, others by compute consumed, by device or entity count, or through a committed capacity tier. Under most of those models, more telemetry held in the analytics tier means more cost somewhere.

The deeper problem is placement. Security teams need enough telemetry to see what is happening in their environment, but a DNS log kept for a future investigation does not need the same indexing, processing, and real-time availability as the authentication events feeding a live detection. Keeping every source in the same high-cost tier charges premium rates for data that is mostly waiting. Deciding where each kind of data lives has become one of the central design questions in a modern SIEM architecture.

How a Security Data Lake Changes SIEM Economics

A security data lake gives telemetry a storage layer that grows with the data, which gives organizations more choice over how that data is retained, searched, and analyzed.

The shift happens in the architecture rather than in the amount of data a team collects. A traditional SIEM couples storage and analytics: data that gets retained also gets indexed and held ready for queries, and it is priced accordingly. A security data lake separates the two where it makes sense. Telemetry sits in low-cost cloud object storage, and compute runs when someone actually queries it. That separation lets a team keep much larger volumes of telemetry, including years of history, without paying analytics-tier rates for data that is searched occasionally.

It also cuts duplication. Many organizations hold the same logs in a SIEM, in a compliance archive, and sometimes in a separate cluster built for threat hunting. One lake serving all of those purposes removes copies that add cost without adding analytical value.

The practical outcome is that processing can match operational value. Telemetry that drives real-time detection can stay in the SIEM. Telemetry that matters mainly for investigation, hunting, or compliance can live in the lake, where it stays available for analytics without occupying the SIEM's most expensive tier.

Anomali normalizes incoming telemetry to the Open Cybersecurity Schema Framework (OCSF), removes duplicate and low-value records, and fuses vetted threat intelligence into each event as it lands in Anomali's cloud-native security data lake. Cost is decoupled from data volume, so adding a source becomes a coverage decision instead of a budget negotiation. Teams can then search and analyze retained telemetry through security analytics that support both detection and investigation.

How much any organization saves depends on its data volume, retention requirements, architecture, and the pricing model of its current SIEM. Before making changes, it is worth modeling those factors against the team's real ingest and retention numbers.

Reducing SIEM Ingestion Without Creating Security Blind Spots

The fastest way to lower a SIEM bill is to stop sending it data, and that is also the method most likely to leave an analyst without evidence six months later. Managing security data well means deciding where each source should live so it stays available when someone needs it.

Identify High-Value Security Data

Start by sorting telemetry by how it gets used. Some sources feed detections that need to fire in seconds. Others matter mostly after the fact, during a historical investigation, a threat hunt, or a compliance review. Many teams skip this step: in the SANS 2025 SOC Survey, 42% of SOCs reported sending all incoming data into a SIEM, often without a plan for retrieving or managing it. That approach pays analytics-tier prices for data with no defined purpose, and it makes the data that does matter harder to find.

Route Data Based on How It Will Be Used

Different sources warrant different levels of processing, retention, and accessibility. Identity and endpoint events that drive active detections may belong in the SIEM. Verbose DNS logs, NetFlow, and cloud audit trails are often more useful as searchable history than as real-time alert inputs. Treating every event identically raises cost without necessarily improving security outcomes, because the premium tier fills with data that rarely triggers anything.

Preserve Useful Historical Telemetry

A cost reduction plan fails if investigators reach an incident discovered weeks or months later and find the evidence already deleted. Any change in routing should be checked against realistic lookback needs, which the next section covers in more detail.

Reduce Duplicate and Low-Value Processing

Look for places where the same telemetry is stored, parsed, or transformed more than once. A log parsed at a collector, parsed again in the SIEM, and then copied to an archive has been processed three times for a single analytical use. Consolidating those steps and filtering out records with no investigative value before storage, trims cost without removing anything an analyst would reach for.

Why Historical Security Data Matters for Investigations

Historical telemetry lets analysts look backward once a threat is discovered, so they can reconstruct activity, identify affected systems, and establish how long suspicious behavior was present. That lookback window matters because many organizations learn about an intrusion secondhand. Across Mandiant's 2025 investigations, organizations first detected malicious activity internally 52% of the time, which means that in nearly half of cases someone outside the security team raised the alarm, often well after the intrusion began.

The need shows up in specific moments. When a new IOC is published, the first question is whether it has already appeared in the environment. When researchers expose a previously unknown campaign, teams have to check past activity for its infrastructure and tooling. Determining initial access often means tracing an intrusion back months before the alert that surfaced it, and reconstructing lateral movement requires authentication and network records from every system the attacker touched. A newly documented attack technique has to be searched across past activity, and scoping an incident for legal, regulatory, or insurance purposes depends on knowing exactly which systems and data were involved.

Data that looked routine when it was collected can become important once new evidence or threat intelligence emerges. A DNS lookup to an unremarkable domain carries no weight until that domain shows up in a threat report. The same logic drives threat hunting where analysts search historical telemetry for indicators and patterns that nobody knew were suspicious when the activity first occurred.

How Security Data Lakes Improve Security Investigations

Security data lakes give analysts access to a wider span of historical telemetry, which lets them investigate across longer time periods and more security domains.

Broader Investigation Context

When endpoint, network, cloud, and identity telemetry sit in one place under one schema, an analyst can follow a compromised account from its first login through the hosts it reached and the cloud resources it touched. Normalization makes this practical, since fields that mean the same thing across different sources can be queried together.

Longer Investigation Lookback

Historical telemetry often reveals activity that predates the event that opened the investigation. The alert might flag a suspicious PowerShell execution on a server, while the lake shows the same account authenticating from an unusual location six weeks earlier.

Retrospective Threat Analysis

New indicators, attack techniques, and intelligence can be searched against previously collected telemetry to find out whether related activity already occurred. When threat intelligence is fused into events as they land, historical records also carry context that helps an analyst judge what a match means.

Fewer Investigation Silos

Centralizing telemetry reduces the manual pivoting between separate storage systems, consoles, and query languages that slows incident reconstruction. With relevant data and context in one searchable place, analysts can move from alert triage into investigation with fewer handoffs.

Security Data Lakes and SIEM Modernization

A security data lake supports SIEM modernization by changing how telemetry is stored, retained, searched, and made available to detection and investigation. For most organizations, it works alongside a SIEM, and whether it eventually takes over more of the SIEM's role is a decision teams can make on their own timeline.

Augment an Existing SIEM

Many teams keep their established SIEM processes and add a security data lake for selected storage, historical analysis, or investigation needs. That approach preserves the detections, dashboards, and runbooks analysts already depend on and avoids the disruption of a full migration. It also reduces reliance on higher-cost SIEM retention and extends how far back investigations can reach. Anomali is designed for this entry point: it sits underneath the stack a team already runs, and each source moved into the lake lowers SIEM spend while widening the dataset available for investigation.

Modernize the Broader Security Architecture

Organizations going through a larger transformation may rethink how storage, analytics, detection, intelligence, and investigation fit together. The question gets sharper as SOCs bring AI agents into triage and investigation, because an agent can only reason over the data it is given. Telemetry that is normalized, deduplicated, and enriched gives analysts and agents the same trustworthy foundation to work from.

What to Evaluate Before Changing Your SIEM Data Architecture

A SIEM cost reduction strategy should weigh investigation requirements, retention policies, analytics performance, integrations, and total operating cost together. Storage price alone makes a poor basis for the decision.

Data Volume and Growth

How much security telemetry does the organization generate today, and how quickly is that number rising? Growth rate matters as much as current volume, since it determines what the architecture will have to absorb two or three years from now.

Retention Requirements

Determine which data must remain accessible, and for how long, based on investigation, security, compliance, and business needs. Separate what must be retained from what must be instantly searchable, because the two requirements often differ.

Search and Investigation Performance

Evaluate how quickly analysts can query historical information during an active investigation. Archived data that takes hours to rehydrate may satisfy an auditor and still fail an incident responder working against the clock.

Detection Requirements

Identify which telemetry must stay available for real-time or near-real-time detection, and confirm those sources remain where the relevant detections can reach them.

Security Integrations

Check whether the architecture works with the organization's existing SIEM, SOAR, XDR, EDR, cloud, identity, and threat intelligence technologies. A lake that analysts cannot query from the tools they already use will see little investigative use.

Total Cost of Ownership

Account for ingestion, storage, compute, infrastructure, administration, data movement, and analyst time. A low price per gigabyte stored can be offset by query charges, egress fees, or the hours analysts spend waiting on slow searches.

Finding the Right Balance Between SIEM Cost and Investigation Readiness

SIEM cost optimization should aim to keep the right telemetry accessible in an architecture that supports investigations, without processing and storing every source the same way. An organization that simply retains less may lower its bill and lose the evidence it needs later. One that keeps everything in its most expensive tier pays premium rates for data that mostly sits idle. A security data lake lets each source live where its cost matches its use.

Frequently Asked Questions

What is a security data lake?

A security data lake is a centralized environment for storing large volumes of security telemetry from endpoints, networks, cloud environments, applications, identity systems, and other sources so it can be analyzed and investigated.

How can a security data lake reduce SIEM costs?

A security data lake can reduce reliance on higher-cost SIEM ingestion and retention tiers by providing another place to retain and analyze security telemetry. Actual savings depend on data volume, architecture, retention requirements, and the organization's SIEM pricing model.

Can a security data lake replace a SIEM?

A security data lake does not automatically replace a SIEM. Organizations may run one alongside an existing SIEM or as part of a broader security analytics architecture, depending on their detection, investigation, retention, and operational requirements.

Does reducing SIEM ingestion create security gaps?

It can, if useful telemetry is simply discarded. A stronger approach is to determine which data requires immediate SIEM analysis and which can be retained elsewhere while remaining accessible for investigations and threat hunting.

Why is historical telemetry important for security investigations?

Historical telemetry helps analysts reconstruct attacks, search for newly discovered indicators, determine when suspicious activity began, and identify affected systems after new evidence or threat intelligence becomes available.

Reduce SIEM Costs Without Sacrificing Investigation Visibility

Give your security team the telemetry and context it needs for investigations while keeping control of what that data costs to store. See how Anomali decouples cost from data volume, under the SIEM you already run.

Request a demo.

‍