Start with investigative value, not source count. High-fidelity SIEM retention should be reserved for telemetry that materially improves detection, forensics, or compliance. Lower-value data can be enriched first, routed to cheaper storage, or dropped if it adds cost without operational benefit. The decision should be policy-driven, measurable, and reviewed against detection outcomes.
Why This Matters for Security Teams
SIEM scope is one of the most expensive judgment calls in security operations because it affects detection quality, analyst workload, retention cost, and audit readiness at the same time. The right answer is not “ingest everything” or “keep only alerts.” Security teams need telemetry that helps answer who did what, from where, and with what impact. That is why control-based thinking matters more than tool-centric thinking, as reflected in NIST SP 800-53 Rev 5 Security and Privacy Controls.
Teams often overestimate the value of noisy logs from every application and underestimate the operational value of a smaller set of identity, endpoint, cloud control plane, and admin activity sources. The real risk is not just storage cost. Over-collection can hide important signals in volume, while under-collection can leave incident responders unable to reconstruct a session, privilege escalation, or lateral movement path. The right balance depends on your threat model, regulatory obligations, and the response questions your SOC actually has to answer.
In practice, many security teams discover they selected telemetry by convenience or vendor defaults only after an investigation stalls because the one missing log source was never retained.
How It Works in Practice
A practical SIEM selection process starts with use cases, not data feeds. For each detection or investigation scenario, define the minimum telemetry needed to support it, then test whether a source contributes unique investigative value. Identity events, privileged actions, authentication failures, cloud control-plane changes, endpoint process activity, and critical application audit logs usually earn priority because they support triage and reconstruction.
A useful decision model is to score each source across four questions:
- Does it enable a detection rule, correlation, or threat hunt that cannot be done elsewhere?
- Does it support forensic reconstruction of a high-impact event?
- Is it required for a regulatory, contractual, or internal retention obligation?
- Can the same value be achieved by enrichment, summarisation, or another control plane source?
If a source fails those tests, it may still belong in lower-cost storage, a data lake, or a specialized platform rather than the SIEM. That aligns with the broader control philosophy in CISA guidance on operationally prioritised defensive action, where coverage should concentrate on risk-relevant events instead of raw volume. For cloud environments, the strongest telemetry usually comes from identity providers, admin audit trails, network flow summaries, EDR, and configuration change logs, with application logs added where they expose business-critical transactions or abuse paths.
Operationally, the selection should be reviewed against measured outcomes: false positive reduction, mean time to investigate, incident reconstruction success, and whether recent detections depended on the sources retained. These controls tend to break down in SaaS-heavy environments where vendors expose inconsistent audit fields because correlation and normalization become unreliable.
Common Variations and Edge Cases
Tighter SIEM inclusion often increases cost and normalization effort, requiring organisations to balance richer visibility against storage, parsing, and analyst overhead. That tradeoff becomes especially sharp in distributed, cloud-native, and high-volume environments where the same event may be emitted in several places.
There is no universal standard for exactly which logs must sit in the SIEM. Current guidance suggests treating the SIEM as the system of record for high-value security telemetry, not as a universal archive. That means some data belongs in adjacent systems first: long-term object storage for cold retention, a data lake for large-scale analytics, or an EDR platform for deep endpoint forensics. The best practice is evolving further in environments that use automation or AI-driven operations, where machine-generated actions can create new audit requirements and identity questions around which actor initiated a change.
Identity and privileged access logs are often non-negotiable because they establish accountability across users, service accounts, and NIST SP 800-63 Digital Identity Guidelines aligned systems. Where business or regulatory drivers demand deep traceability, teams may also need to retain specific evidence for incident response and governance mapped to OWASP guidance on AI-adjacent application risk only if AI systems are part of the monitored environment. In mature programs, the final question is simple: if this log disappeared tomorrow, would a real investigation or compliance review lose something material?
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01 | Telemetry selection directly shapes continuous monitoring coverage and visibility. |
| NIST SP 800-53 Rev 5 | AU-2 | Audit event selection is the control basis for deciding what enters the SIEM. |
| MITRE ATT&CK | T1078 | Valid account abuse is best detected with identity and authentication telemetry. |
Keep only telemetry that improves monitoring outcomes and incident detection quality.
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 remote browser isolation belongs in their stack?
- How should teams decide whether AI procurement belongs in security governance review?
- How do security teams decide whether telemetry is good enough for enforcement?
