Newsletter Article
THE SIEM COST PARADOX, WHEN MORE VISIBILITY CREATES MORE EXPENSE
Snare Insider Newsletter Series Article
Make sure you Subscribe
Security teams are being told to collect more telemetry. Capture more endpoint activity. Monitor more identities. Add cloud, SaaS, application, network, API, database and AI system logs. Retain evidence for longer. Make it searchable. Keep it ready for audit. Use it to detect threats in real time.
Every requirement is understandable in isolation. Combined, they create a significant technical and financial challenge.
Many SIEM platforms base at least part of their pricing on the volume of data ingested, processed or retained. Published and vendor-reported list pricing sampled through Q1–Q2 2026 illustrates the spread:
- Splunk’s traditional ingestion licensing runs roughly USD $2,000–$3,500 per GB per year,
- Microsoft Sentinel’s pay-as-you-go rate sits around USD $2.96–$5.59 per GB depending on commitment tier and region, and
- Elastic Security ranges from roughly USD $0.55–$1.10 per GB.
Whatever the model, industry benchmarking through 2026 puts enterprise telemetry growth at roughly 20–30% a year, driven by cloud migration, containerisation, SaaS adoption and identity proliferation.
That growth rate matters because it compounds against whichever pricing model is in place.
A SIEM bill that is manageable today can become unsustainable within a few renewal cycles, even when the organisation hasn’t added analysts, improved detection coverage, or reduced risk. And the cost of getting visibility wrong is not abstract: IBM’s Cost of a Data Breach Report 2025 put the average cost of a US data breach at USD $10.22 million, with time-to-identify and time-to-contain, both directly dependent on log availability, as leading cost drivers.
Why log volume continues to increase
Modern organisations are generating more logs because they are operating more:
- Endpoints and remote devices
- Cloud platforms and workloads
- SaaS applications
- Digital identities and service accounts
- APIs and machine-to-machine connections
- Containers and microservices
- Operational technology and connected devices
- Security controls and detection tools
- AI models, agents and automated workflows
Each new system may generate multiple event types. The same event may also be collected, copied, transformed and forwarded to several destinations. The result is not only more data, it is more duplication, noise and complexity.
The hidden consequences of uncontrolled ingestion
When SIEM costs escalate, organisations may respond by disabling high-volume log sources, reducing retention periods, collecting only a narrow subset of events, dropping records before their future value is understood, retaining data in inaccessible archives, delaying the onboarding of new systems, or forcing analysts to work across disconnected data stores.
These decisions may reduce immediate expenditure, but they can also create blind spots. The log that appears low-value today may become critical when an incident is discovered several months later.
The problem is not log volume. The problem is uncontrolled log volume.
Not every log requires the same level of real-time analytics, search performance or retention. A mature security data architecture distinguishes between:
- Events needed immediately for detection and alerting
- Evidence needed for threat hunting and investigation
- Records retained primarily for audit or compliance
- High-volume operational data with limited security value
- Duplicate or repetitive events that can be safely aggregated
The market has taken notice: the past two years have seen a wave of data-pipeline and observability tools built specifically to filter and route telemetry before it reaches a SIEM.
Gartner’s own Market Guide for Log Monitoring and Analysis Solutions (Gregg Siegfried and Pankaj Prasad, April 2025) makes the same point independently, noting that “nearly every element” of a modern technology stack now generates log telemetry, and recommending that organisations evaluate whether a telemetry pipeline will be impactful as a first step in vendor selection, before choosing an analytics platform, not after. That validates the direction, but a filter bolted on after collection is not the same as control designed in at the point of collection, on the agent itself.
