Security Information and Event Management platforms remain one of the core layers of modern security operations. They help security teams collect events, detect suspicious behaviour, correlate activities across different systems, and support incident investigation. However, as infrastructures become more distributed, cloud-driven and data-heavy, many organisations face a growing challenge: their SIEM is no longer only an analytics platform; it has become a large-scale log collection point.

This shift creates both technical and operational pressure. The issue is not simply about licensing, pricing or procurement. In many cases, SIEM cost optimisation starts with a much more fundamental question: what data are we sending to the SIEM, in what format, and for what purpose?

The Cost Problem Is Often a Data Problem

Modern environments generate massive volumes of security and operational data. Cloud platforms, endpoints, identity providers, firewalls, EDR tools, proxies, DNS services, VPN gateways, SaaS applications and business-critical applications all produce logs continuously. Some sources can generate millions of events per day, especially in large or highly active environments.

When this raw data is forwarded directly to the SIEM without filtering, parsing or normalisation, ingestion volume can grow faster than the actual security value of the data. This creates unnecessary pressure on storage, indexing, query performance and analyst productivity.

There are several common technical causes behind this problem. Duplicate events are one of them. The same connection, authentication attempt or status message may be recorded repeatedly by different systems. Low-value logs are another issue. Repetitive “allow” traffic, heartbeat messages, informational events or routine system noise may have limited value for real-time detection but still consume SIEM resources.

Retention and indexing policies also play a key role. Not every log type needs to be indexed for the same duration, stored in the same tier or queried with the same urgency. Treating every log as equally critical increases operational complexity and reduces the efficiency of the SIEM architecture.

Why Normalisation Matters

One of the most underestimated challenges is the lack of normalisation. Different log sources often describe the same concept using different field names. For example, a username may appear as user, account_name, src_user, username or auth_user, depending on the source.

This inconsistency makes detection engineering, correlation and investigation more difficult. Analysts spend more time adjusting queries, mapping fields manually and validating whether two events are actually related. As a result, poor data quality can negatively affect operational metrics such as Mean Time to Detect and Mean Time to Respond.

In other words, SIEM optimisation is not only about reducing volume. It is also about improving the quality, consistency and context of the data that reaches the SIEM.

The Role of a Telemetry Pipeline Before the SIEM

A practical approach is to introduce a telemetry pipeline layer before the SIEM. This layer processes raw log data before it reaches the analytics platform. Instead of forwarding everything as-is, the pipeline can collect, parse, filter, normalise, enrich, mask, deduplicate, buffer and route data according to its value and purpose.

For example, high-value security events can be forwarded to the SIEM for real-time analysis, while lower-priority or compliance-driven logs can be sent to object storage, a data lake or an archive for long-term retention. This separation between “hot” analytics data and “cold” storage data is one of the most effective ways to create a more sustainable logging architecture.

A telemetry pipeline can also enrich events with asset information, user context, GeoIP data or threat intelligence matches. This additional context helps analysts understand not only what happened, but also where it happened, who was involved and whether the event is relevant to active threats.

Community and Commercial Tooling

There are several technologies that can support this architectural approach. Community and open-source tools such as NXLog Community Edition, Fluent Bit, OpenTelemetry Collector and Vector can be evaluated for log collection, parsing, filtering and forwarding scenarios.

Commercial or enterprise versions may provide additional advantages such as centralised management, large-scale agent control, advanced modules, lifecycle management, professional support and operational governance. The right choice depends on the organisation’s log sources, regulatory requirements, team capability, SIEM architecture and operational maturity.

The key point is not to select a tool first, but to define the data strategy first. Technology should support the architecture, not define it.

Real-World Use Cases

In Windows environments, organisations may choose to forward only security-relevant event IDs to the SIEM while filtering repetitive informational logs closer to the source.

For VPN and identity monitoring, failed login attempts can be normalised into a common user identity field, making it easier to correlate them with directory or identity provider logs.

In Kubernetes and container environments, raw container logs can be enriched with pod, namespace and service metadata before reaching the SIEM. This allows analysts to investigate events with much better operational context.

For DNS logs, instead of sending every raw query to the SIEM, organisations can prioritise suspicious domains, NXDOMAIN spikes or threat intelligence matches, while keeping the full dataset in a lower-cost archive for retrospective investigation.

Conclusion

Sending more data to a SIEM does not automatically create better visibility. In many cases, sending less but cleaner, normalised and context-rich data improves detection quality, analyst efficiency and architectural sustainability.

SIEM cost optimisation should therefore be approached as a data engineering, security operations and governance challenge. The first step is not to ask how much data the SIEM can ingest, but to ask which data truly deserves to reach the SIEM in the first place.