When should organisations send telemetry to cheaper storage instead of a SIEM?

When does cheaper storage make more sense than SIEM ingestion?

Cheaper storage is the right destination when telemetry is unlikely to drive immediate detection or response, but it still has investigative, compliance, or troubleshooting value later. That usually means separating high-value security events from high-volume noise, then tiering the rest by retention need, query frequency, and operational importance instead of sending everything to the SIEM by default.

The practical decision is rarely binary. A SIEM is best for signals you want to correlate, alert on, and monitor continuously, while cheaper object storage is better for logs that are retained for search, forensics, or reconstruction after an incident. The point is to preserve access to the data without paying SIEM indexing costs for telemetry that will not materially change live security decisions.

Which telemetry usually stays in the SIEM?

Security telemetry should stay in the SIEM when it supports active use cases such as alerting, correlation, enrichment, and hunting that depend on low-latency search. Authentication events, privilege changes, endpoint detections, cloud control-plane events, and other high-signal records usually justify SIEM cost because they support immediate triage or continuous monitoring.

It is also sensible to keep a subset of supporting context in the SIEM when analysts need it to interpret other alerts quickly. If a log source is essential for detecting a specific threat path, suppressing it to save money can create blind spots, especially when the source is sparse but operationally important. SIEM Guide

Which telemetry belongs in cheaper storage first?

Verbose application traces, debug output, routine health metrics, and low-value operational noise are common candidates for cheaper storage once they have been filtered, normalised, or indexed enough to remain usable. The key test is whether the data needs fast correlation in the SIEM or only occasional retrieval for incident review, compliance evidence, or root-cause analysis.

Teams should also consider volume and repetition. If a source produces a large amount of near-duplicate data, sending all of it into the SIEM can raise cost without improving detection quality. A better pattern is to keep the searchable summary, route the bulk payload to lower-cost storage, and preserve the path back to the raw data when deeper inspection is needed. SIEM Log Source Onboarding Checklist

Risk and Threat Considerations

Cost-driven telemetry tiering can create security exposure if teams move the wrong data out of the SIEM or fail to preserve enough context for detection. The risk is not just lost visibility, it is delayed investigation, weaker correlation, and a higher chance that important activity is only found after the fact.

Failure mechanism: Organisations overestimate how much raw telemetry they need in the SIEM, then either suppress important sources or keep high-volume noise in place because no one has defined which events are detection-critical versus archive-only.

Impact: Detection becomes less reliable, hunting becomes slower, and responders may lack the evidence needed to reconstruct an incident, confirm scope, or prove whether a suspicious sequence was benign or malicious.

Practitioner Guidance

What to verify: Classify each source by its real operational use, not by habit. If a log stream does not support an alert, correlation rule, or hunting workflow, it probably belongs outside the SIEM unless policy or investigation requirements say otherwise.

Decision rule: Keep telemetry in the SIEM when analysts need it within minutes to answer “is this happening now?” Send it to cheaper storage when the main question is “what happened later?” and when the data can still be retrieved quickly enough for investigation.

Common mistake: Teams often move data to cheaper storage without preserving field structure, timestamps, or indexing strategy. That saves money up front but makes the archive much less useful when an incident forces a retrospective search.

Practitioner takeaway: The goal is not to minimise SIEM volume at all costs, it is to reserve SIEM capacity for telemetry that changes live security decisions and place everything else where it remains searchable and recoverable at lower cost.

Related resources from NHI Mgmt Group

• How should security teams decide what telemetry to send into a cloud SIEM when ingest-based pricing is in place?
• What happens when low-priority logs are sent to cheaper storage instead of being ingested?
• Should organisations centralise all telemetry instead of using distributed storage?
• What breaks when a SIEM still owns telemetry ingestion and storage?