Teams should treat ingestion as a governance problem, not just a pipeline problem. Enrich and classify data before forwarding it, then apply filtering and deduplication so only high-value events reach the SIEM. The goal is to preserve investigative context while controlling cost, reducing noise, and keeping enough raw detail in the pipeline for later pivots.
Why This Matters for Security Teams
Ingest-based pricing turns telemetry selection into a control decision because every source added to a cloud SIEM changes cost, signal quality, and investigation depth. The hard part is not collecting more data, but deciding which events are essential for detection, incident response, compliance, and forensics. A sound approach starts with security outcomes, then maps telemetry to those outcomes using controls such as NIST SP 800-53 Rev 5 Security and Privacy Controls.
Teams often get this wrong by forwarding broad logs first and asking cost optimisation questions later. That usually creates three problems: noisy detections, expensive retention, and blind spots when the most useful context was filtered out upstream. The right question is not whether to ingest everything, but which telemetry is necessary to support alerting, hunting, compliance evidence, and post-incident reconstruction.
In practice, many security teams discover their SIEM is overfed only after a major investigation exposes missing context, duplicated events, or unaffordable retention pressure.
How It Works in Practice
A practical telemetry strategy begins with a use-case inventory. Security teams should identify the detections, hunts, and investigations the SIEM must support, then map each use case to the minimum event types needed. This usually includes authentication events, privilege changes, endpoint detections, cloud control plane activity, network egress signals, and a smaller set of high-value application logs. The goal is to preserve decision-making value, not to mirror every source in the environment.
Before events reach the SIEM, classification should separate high-fidelity security telemetry from operational noise. Enrichment at the collector or forwarder layer is often more valuable than raw volume because it adds asset identity, user context, workload tags, and environment metadata. Filtering should remove low-value repeats, but not at the expense of losing correlation fields needed later. Where possible, teams should retain raw logs in lower-cost storage for replay and forensic pivots, while sending normalized, enriched events into the SIEM.
- Prioritise identity, privilege, and control-plane events when they directly support threat detection.
- Keep full fidelity for sources used in incident response, legal hold, or regulated audit evidence.
- Deduplicate repetitive telemetry only after confirming it does not break correlation rules.
- Route high-volume debug or application traces to cheaper storage unless a live detection depends on them.
- Review ingestion regularly against alert quality, dwell time, and investigation outcomes.
For cloud and hybrid environments, this should align with the detection strategy in MITRE ATT&CK so telemetry is chosen for known attacker behaviors rather than source availability. It also helps to use NIST guidance on event logging, monitoring, and incident handling as the baseline for retention and evidence quality. These controls tend to break down when log ownership is fragmented across platform, app, and security teams because no one can prove which signals are essential versus merely convenient.
Common Variations and Edge Cases
Tighter ingestion controls often reduce SIEM cost, but they also increase the risk of under-collection, so organisations must balance financial discipline against investigative completeness. Current guidance suggests there is no universal telemetry set that fits every cloud estate, especially where SaaS, container platforms, or highly ephemeral workloads are involved.
Some environments need exceptions. A payment environment may retain more transaction and access telemetry to support PCI DSS evidence, while a regulated financial firm may keep expanded audit trails for operational resilience and supervisory review. In container and serverless platforms, short-lived identities and high churn make deduplication harder, so teams may need to preserve more control-plane events than they would in a traditional server estate. There is also a tradeoff between normalising logs early and preserving source-specific detail for deep forensics; best practice is evolving here, and the right balance depends on the maturity of detection engineering and the stability of the environment.
For cloud-native stacks, a useful pattern is to send security-relevant summaries into the SIEM and keep raw records in object storage with clear retention and retrieval processes. That creates room for hunting without paying SIEM prices for every event. Where the business relies heavily on managed services or third-party platforms, telemetry decisions should include contractual access to logs and evidence, not only technical forwarding paths. In highly dynamic environments, this guidance breaks down when workloads change faster than the filtering rules can be validated, because stale allowlists and suppression logic can hide real attacks.
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 surface, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, and PCI DSS v4.0 and NIS2 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-1 | Telemetry selection supports continuous monitoring coverage and signal quality. |
| MITRE ATT&CK | T1078 | Identity and access telemetry helps detect valid-account abuse patterns. |
| NIST SP 800-53 Rev 5 | AU-2 | Audit event selection is the core control behind cost-aware SIEM ingestion. |
| PCI DSS v4.0 | 10.2 | Cardholder environments need retained audit trails and log review evidence. |
| NIS2 | Article 21 | NIS2 resilience expectations reinforce selective logging tied to incident handling. |
Map SIEM inputs to continuous monitoring needs and confirm each source supports a defined detection or response use case.
Related resources from NHI Mgmt Group
- What do security teams get wrong about cloud-based SIEM and EDR?
- How should security teams decide which telemetry belongs in the SIEM?
- How do security teams decide whether to trust a cloud SIEM's native pipeline?
- How should security teams ingest AI agent telemetry into a SIEM without creating more noise?
