How should security teams decide which logs belong in a SIEM analytics tier?

Teams should reserve analytics-tier ingestion for telemetry that can drive detections, alerts, or interactive investigation. Sources that mainly provide historical context, compliance evidence, or low-frequency correlation should usually go to cheaper long-retention storage. The decision should be based on security value, not on which team owns the system or how easy the connector is to build.

Why This Matters for Security Teams

Analytics-tier SIEM storage is expensive because it is designed for active search, correlation, and alerting. When teams ingest everything by default, high-value signals get buried under noise, detection logic becomes harder to maintain, and investigation workflows slow down. The real question is not whether a log source is “important,” but whether it supports a specific security use case such as detection, triage, or incident reconstruction.

That distinction maps well to the control intent in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where logging, monitoring, and auditability support continuous oversight rather than passive retention. Security teams often overvalue ownership and convenience instead of analytical utility, which leads to bloated pipelines and weak detection coverage. In practice, many security teams discover the true value of a log source only after an incident has already exposed a coverage gap, rather than through intentional tiering decisions.

How It Works in Practice

A practical SIEM tiering model starts by asking what a log source can actually do for the SOC. If the source can confirm malicious behavior, enrich an alert, or support interactive investigation, it belongs in the analytics tier. If it mainly proves that an event happened, helps with compliance evidence, or is only useful during rare forensic work, it is usually better placed in lower-cost retention storage.

Security teams should evaluate each source against a small set of questions:

• Does it support a detection rule, correlation query, or investigation playbook?
• Is the event frequency high enough to justify cost, but not so noisy that it overwhelms analysts?
• Can the source be normalized into fields that support hunting and enrichment?
• Would delayed access still preserve the source’s value, or is near-real-time analysis essential?

This approach aligns with the broader logging and monitoring expectations in CIS Controls, where visibility should be prioritized around high-value assets and likely attack paths. It also helps teams avoid the common trap of ingesting broad administrative logs that rarely drive decisions but consume large portions of the analytics budget. A source such as authentication, privilege escalation, cloud control plane activity, or endpoint telemetry usually has clear investigative value. By contrast, routine business application transaction logs often belong in archive or search-optimized storage unless there is a specific abuse case tied to them.

Operationally, the best results come from treating analytics-tier onboarding as a use-case review, not a connector request. Teams should document the expected detection use cases, the investigation questions the source answers, and the retention period needed for both alerting and post-incident analysis. These controls tend to break down when cloud, SaaS, and legacy systems emit inconsistent fields because correlation quality drops and the source’s analytical value becomes hard to sustain.

Common Variations and Edge Cases

Tighter analytics-tier selection often increases upfront analysis work, requiring organisations to balance detection quality against operational convenience. That tradeoff matters because some sources are only valuable in combination, even if they seem weak on their own.

For example, a low-signal source may still belong in the analytics tier if it becomes decisive when joined with identity, endpoint, or network telemetry. Current guidance suggests prioritizing sources that enrich higher-confidence detections rather than assigning equal treatment to every record type. There is no universal standard for this yet, so teams should be explicit about their threshold for “analytic usefulness” and revisit it as the environment changes.

Edge cases often include compliance-heavy logs, executive communications systems, developer platforms, and rare-but-critical control plane events. Some of these should remain searchable for incident response even if they are not continuously analyzed. Others may be better routed to longer-term storage with on-demand indexing. The key is to avoid confusing retention requirements with analytics requirements. A log can be legally or operationally important without being worth premium SIEM ingestion.

Where identity and privilege are involved, the bar should be higher, because authentication, session, and administrative activity often reveal the earliest signs of compromise. Where that same data is already centralized in a separate investigation platform, the SIEM should ingest the minimum fields needed to trigger detections and pivot into the source of truth. Current guidance suggests that this balance works best when tiering decisions are reviewed alongside detection engineering, not as a one-time logging project.

Related resources from NHI Mgmt Group

• How should security teams decide what identity data belongs in a hybrid SIEM?
• How should security teams decide where SIEM ends and ITDR begins?
• How should security teams decide what goes to the SIEM versus cold storage?
• How should security teams implement SIEM correlation across identity and cloud logs?