They should separate detection workloads from storage and routing decisions. If the SIEM is receiving everything and filtering later, the programme has collapsed two different jobs into one platform. Reintroduce an upstream governance layer so the SIEM sees only telemetry that has already been classified and enriched for value.
Why This Matters for Security Teams
When a SIEM starts behaving like a data warehouse, the security function usually loses clarity on what it is trying to detect versus what it is merely storing. That creates rising ingestion costs, slower investigations, noisier alerting, and a false sense of coverage. The real issue is architectural: telemetry routing, enrichment, retention, and detection logic have been blended into one pipeline, so teams cannot tell which controls are actually creating security value.
This is not just an efficiency problem. A warehouse-style SIEM often masks gaps in use-case design, especially when teams treat volume as a proxy for visibility. Good practice is to align collection to purpose and to define which events support prevention, detection, hunting, or compliance. NIST guidance on control families in NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it reinforces the need to govern logging, monitoring, and retention as distinct security outcomes, not as one undifferentiated feed.
In practice, many security teams encounter SIEM overload only after critical alerts are buried under years of low-value telemetry and expensive retention decisions have already been made.
How It Works in Practice
The practical fix is to move the SIEM back into its proper role as a detection and correlation layer. That means upstream systems should decide what gets collected, normalized, enriched, sampled, routed, or discarded before events reach the SIEM. Security teams usually need a policy-driven telemetry pipeline with clear criteria for source inclusion, event prioritization, and retention periods. High-value identity, endpoint, cloud control-plane, and privileged access events should be preserved at higher fidelity, while low-signal logs can be reduced or kept in cheaper storage.
A workable design usually has three stages:
- Classification at the source or collection layer, so telemetry is tagged by security value and business context.
- Enrichment before indexing, so the SIEM receives events with asset, identity, and risk context already attached.
- Routing rules that send investigative raw logs to a data lake or archive, while sending only actionable events to the SIEM.
This separation supports better detection engineering, cleaner query performance, and more defensible retention governance. It also helps teams align logging with operational resilience expectations in CISA Cybersecurity Performance Goals and incident handling practices in NIST incident response guidance. For environments with cloud, endpoint, and identity telemetry, this also improves how teams map detections to attack patterns in MITRE ATT&CK.
These controls tend to break down when teams centralise every log source into one platform without a telemetry policy, because then storage pressure and detection engineering compete for the same indexing budget.
Common Variations and Edge Cases
Tighter telemetry governance often increases upfront engineering effort, requiring organisations to balance cleaner detection against the convenience of “collect everything” defaults. That tradeoff is real, especially during mergers, cloud migrations, or regulatory programmes where teams fear losing evidence.
Current guidance suggests that not every environment should treat the SIEM the same way. In smaller estates, a SIEM may still ingest broader telemetry if the event rate is manageable and detection goals are narrow. In large or highly distributed environments, best practice is evolving toward tiered observability: SIEM for security-relevant detections, a data lake for deep retention, and a separate search layer for forensic analysis. There is no universal standard for exactly where the cutoff should sit, because the answer depends on threat model, licensing pressure, and investigative workload.
Identity and privileged-access telemetry deserves special handling. If authentication, admin actions, and API activity are flattened into generic logs, teams lose the ability to spot credential abuse, lateral movement, and overprivileged automation. That is where the SIEM-as-warehouse pattern becomes especially dangerous: the platform still looks “full,” but it is no longer discriminating. Teams should regularly ask whether each ingestion source supports a detection, a compliance need, or a retention obligation. If it does none of those, it probably belongs outside the SIEM.
For mixed cloud and enterprise estates, the strongest approach is a governance-led telemetry architecture with explicit routing rules, documented use cases, and periodic pruning of low-value sources.
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, NIST AI RMF 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-1 | Continuous monitoring depends on purposeful telemetry, not indiscriminate log retention. |
| NIST AI RMF | GOVERN | Telemetry governance is a lifecycle and accountability issue, not just an engineering choice. |
| MITRE ATT&CK | T1078 | Identity abuse is a common detection use case that benefits from curated SIEM telemetry. |
| NIST SP 800-53 Rev 5 | AU-2 | Audit event selection must be controlled so logging serves security outcomes. |
Specify which audit events are worth collecting and retire sources that add cost without detection value.
Related resources from NHI Mgmt Group
- How should security teams decide what identity data belongs in a hybrid SIEM?
- How should teams keep compliance data available while lowering SIEM spend?
- How should security teams think about a compromised integration like Drift?
- How should security teams unify identity across cloud and data center environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
