Ask a security team what they would change about their SIEM and cost is usually near the top of the list. Splunk, Microsoft Sentinel, Google SecOps, Sumo Logic and most other platforms charge by ingestion volume, or by a licence sized on it. Log volume grows every year as you add cloud services, endpoints and SaaS apps, so the bill grows too, whether or not your detection gets any better.
The usual response is blunt: switch off a noisy source, shorten retention, or ask for more budget. There is a better order of work, and it starts with a question most teams can’t answer today: which of the data we pay for is actually used by a detection?
Why SIEM costs keep growing
Three things push the bill up. The first is more sources: every new firewall, SaaS app and cloud account adds a feed. The second is verbose defaults: many sources ship with debug, informational and health-check events switched on, and collectors forward everything they receive. The third is that nobody owns removing data. Adding a source is a project with a sponsor. Removing one is a risk nobody wants to sign off.
The result is a SIEM full of data that no rule reads. CardinalOps’ analysis of production SIEMs found the average enterprise ingests around 259 log types from nearly 24,000 log sources, enough telemetry to cover more than 90% of MITRE ATT&CK techniques, yet its rules cover only 21% of them. [1] Organisations are paying to collect far more than they use.
Step 1: measure what each source costs you
Start with volume by source and by event type, not just by index or table. A Windows Security feed is not one thing. Logons (4624), process creation (4688), filtering-platform connections (5156) and object access (4663) have very different volumes and very different detection value. In many estates a handful of event types make up most of the gigabytes.
Use your platform’s own counts where you can, such as licence usage in Splunk or the Usage table in Sentinel, so the numbers match the invoice. Then rank sources by daily volume. That list is your cost map.
Step 2: map every event type to the detections that use it
This is the step most cost projects skip, and the one that makes the rest safe. For each high-volume event type, list the detection rules, dashboards and investigation runbooks that depend on it. You will end up with four groups:
- Used by detections. Keep it in the SIEM’s analytics tier.
- Needed for investigations or compliance, but rarely searched. Keep it, somewhere cheaper.
- Used by nothing. Debug output, health checks, the same event arriving twice through two collectors.
- Useful, but far too noisy. A source where one event ID or one field carries the value and the rest is chatter.
Doing this by hand means cross-checking every rule’s query against every source, which is why it rarely gets done. It is also why “drop the noisy stuff” so often goes wrong: the noisy source is sometimes the only place a critical detection gets its data.
Know which logs your detections actually read
LogLens checks every event type in your SIEM against every detection that could use it, then tells you what to keep, route, drop or tune, with the reason for each. It runs on your own network and sends your logs nowhere.
See how LogLens finds the logs you can cut →Step 3: route, tune or drop
Once each event type has a verdict, there are three levers. Use them in order of safety:
| Action | What it means | Typical candidates |
|---|---|---|
| Route | Keep the data, but in a cheaper tier or storage | Firewall allow logs, DNS queries, flow logs, verbose cloud audit data kept for investigations |
| Tune | Filter at the source so only the valuable events or fields are sent | Windows events no rule uses, chatty application logs, health checks and keep-alives |
| Drop | Stop collecting data nothing uses | Debug output, duplicate feeds, test systems, events already summarised elsewhere |
Routing is the safest lever because nothing is lost. Most platforms now offer a cheaper tier for high-volume, low-value data. Microsoft Sentinel’s Basic and Auxiliary logs, for example, are charged at a much lower rate per gigabyte than analytics logs, in exchange for fewer query features. [2] A pipeline tool such as Cribl, or ingestion-time transformations in Sentinel’s data collection rules, can split one feed so the events your detections need go to the analytics tier and the rest goes to cheap storage. [3]
Tuning at the source is usually where the biggest savings are, because the data never travels. Filter Windows events with audit policy and agent configuration, filter syslog in rsyslog or your collector, and trim firewall logging profiles. Public case studies show what is possible: Yale New Haven Health reported cutting its Palo Alto firewall log volume by around 40% with a pipeline in front of its SIEM. [4] Vendors often quote 30–60% on noisy sources. Treat that as what is achievable on the worst offenders, not a promise for every estate.
Dropping is final, so it comes last and needs the clearest evidence: no detection, no investigation runbook and no compliance requirement uses the event type.
Logs you should never cut to save money
Some data is cheap insurance. Authentication logs (Windows 4624 and 4625, Entra ID sign-ins, Okta, VPN), privilege changes (group membership, role assignments, new MFA methods) and audit trails (the Microsoft 365 unified audit log, AWS CloudTrail management events, the SIEM’s own audit log) are what investigators need after an incident, and what most account-takeover and privilege-escalation detections rely on. At most, route them to a cheaper tier with the retention your regulators expect. Never drop them.
The same goes for the sources behind your most valuable detections, even when they are noisy. Sysmon and process-creation logs are large, but they are how you see ransomware operators and hands-on-keyboard attackers. Tune them. Don’t remove them.
Step 4: make it stick
Log volume drifts back up. New sources arrive with default verbosity, a collector is reinstalled with its original configuration, an application team turns on debug logging and forgets about it. Re-measure monthly, alert on sudden volume jumps per source, and revisit the route, tune and drop decisions whenever you add or retire detections. Detection changes and cost changes are the same conversation.
Cost reduction is also a coverage project
The mapping you do to cut costs is the same mapping that shows your detection gaps. Once you know which events each detection reads, you can also see the detections you could run but haven’t built, and which missing source would add the most coverage. CardinalOps found that 13% of existing SIEM rules are broken and will never fire, often because the data they expect changed or never arrived. [1] A cost review that finds those is worth doing for that alone.
The goal is not the smallest possible SIEM. It is a SIEM where every gigabyte you pay for is doing a job.