Why does sending every log to the SIEM create more risk and cost for security teams?

Why indiscriminate SIEM ingestion becomes a governance problem, not just a storage problem

Sending every log source into a SIEM is not only expensive; it also changes the security operating model. When teams ingest low-value, duplicate, or malformed events at scale, the platform becomes harder to tune, detections become less trustworthy, and analysts lose time to triage rather than investigation. The practical issue is not volume alone, but the collapse of signal quality and ownership discipline. Guidance from the NIST Cybersecurity Framework 2.0 is relevant here because collection choices should support useful detection and response outcomes, not simply maximise telemetry for its own sake.

In practice, many security teams only discover the cost of indiscriminate ingestion after the SIEM starts buffering noise faster than they can tune detections or prune sources.

How SIEM overload happens in day-to-day operations

A SIEM is most effective when it receives logs that are relevant, normalised, and tied to specific detection or investigation goals. Problems start when organisations treat ingestion as a blanket requirement rather than a governed decision. Not every system produces equally useful events, and not every log has the same value for alerting, hunting, or forensics. Some sources are essential because they capture authentication, administrative activity, cloud control-plane actions, or endpoint telemetry. Others mostly add duplicates, application chatter, or data that cannot be parsed consistently.

Once the ingestion pipeline is overloaded, several failure modes appear at once. Parsing errors reduce field quality, which weakens correlation and makes it harder to join events across identity, endpoint, network, and cloud layers. Duplicate events inflate storage and licensing costs without improving detection. Poorly curated sources also increase false positives, because rules fire on events that look suspicious but are actually routine noise. That creates analyst fatigue and can cause important alerts to be ignored or delayed.

Operationally, teams need to decide what the SIEM is for before deciding what to send into it. If the goal is detection, then the selected sources should support the attack paths and behaviours the team expects to detect. If the goal is investigation, the logs must preserve enough context to reconstruct timing, subject, action, and outcome. If the goal is compliance evidence, the team still needs to separate mandated retention from real-time analytics, because those are not always the same requirement.

Where this breaks down is when organisations use the SIEM as a default archive for everything, then expect it to function as a precise detection platform without any source prioritisation or data lifecycle control.

When “more logs” stops helping and starts distorting detection

Tighter ingestion control often improves detection quality, but it also creates a tradeoff: teams must accept that some data belongs in cheaper retention, a data lake, or a source-specific investigation workflow rather than in the SIEM itself.

One important edge case is compliance-driven logging. Some records must be retained even if they are not operationally useful for alerts. That does not mean they should be indexed, correlated, and alerted on in the same way as high-value security telemetry. Another edge case is temporary expansion during an investigation. In that situation, wider ingestion can be justified for a short period, but it should be treated as an exception with a defined end state. A third case is tool sprawl: when multiple platforms forward the same event stream, the apparent increase in visibility is often just duplication. That can make coverage look better on paper while actually worsening analyst confidence.

There is still some debate in the industry about how much telemetry should sit in the SIEM versus adjacent platforms. The consensus is not that every log belongs in the SIEM, but that the most security-relevant, actionable, and well-structured data should be prioritised there. The rest should be managed according to value, retention need, and retrieval method rather than forced into the same workflow.

The practical limit is reached when ingestion growth outpaces the team’s ability to normalise, tune, and review the resulting data, at which point the SIEM becomes a cost amplifier instead of a detection asset.

Practitioner Guidance

What to prioritise: Start with the log sources that directly support identity events, administrative actions, endpoint activity, cloud control-plane changes, and the attack paths your team actually investigates. If a source does not improve detection, triage, or reconstruction, it should not compete for premium SIEM storage and correlation capacity.

What to verify: Confirm whether each feed is unique, parseable, and actionable before expanding ingestion. Teams should be able to show which detections depend on a source, which fields are reliably extracted, and which logs are retained for evidence only. If that justification is missing, the feed is usually oversized for the SIEM role it is being asked to play.

Practitioner takeaway: The right question is not how many logs can be collected, but which logs deserve expensive, high-friction analytic treatment because they materially improve security decisions.

Related resources from NHI Mgmt Group

• Why do stripped audit-log fields create so much risk for IAM and cloud security teams?
• How should security teams balance SIEM cost reduction with log retention?
• Why does SIEM log reduction create security risk?
• Why does sending all telemetry into a legacy SIEM create cost and control risk for large enterprises?