Somewhere in every security team's history is the same conversation. A new SIEM bill arrives, noticeably larger than last quarter's, and someone asks: "what's actually in here?" The honest answer, more often than not, is "everything we could think to turn on, plus whatever the default template shipped with." Nobody chose that outcome. It just accumulated.
Log management has an unusual property among security controls: the cost is continuous and the benefit is conditional. You pay for every gigabyte ingested whether or not it ever matters. The payoff — catching the one event that mattered — only shows up during an incident, and only if you kept the right thing. That asymmetry is exactly why logging strategy drifts toward one of two failure modes, both of which feel reasonable in the moment.
Two ways to get this wrong
Under-logging looks like fiscal discipline. Fewer events, lower cost, less noise for analysts to wade through. The problem is that blind spots don't announce themselves. An intrusion that never generates a log is an intrusion that never gets detected — and dwell time, the gap between compromise and discovery, is one of the biggest drivers of breach cost. The average breach in 2025 took 241 days to identify and contain, and breaches caught within 200 days cost organizations roughly $1.1–1.9M less than ones that ran longer.[1] Organizations rarely discover their logging was insufficient during a calm Tuesday review. They find out mid-incident, when it's too late to go back and collect what wasn't there.
Over-logging looks like thoroughness, and it's the more common failure mode in practice, because "turn everything on and figure it out later" requires no upfront judgment calls. But flooding a SIEM with high-volume, low-value events doesn't just waste budget — it actively undermines detection. The events that matter get buried under the ones that don't, dashboards become unreadable, and analysts stop trusting alerts that are usually nothing. Volume was never the same thing as coverage. A logging strategy can be simultaneously the most expensive one you've ever run and still full of blind spots, because nobody was ever asking whether a given event earned its ingestion cost.
How the bill actually works
The economics vary more than people expect, and the differences matter for which mistakes are cheap versus expensive.
Ingest-based pricing — the model most people picture — charges by volume: per gigabyte, per event, per host. This is how Splunk's traditional model and Microsoft Sentinel's default Analytics tier both work.[2] Under this model, every unfiltered high-volume event is a direct, visible line item, and cutting one is a direct, visible saving.
Workload or compute-based pricing — an increasingly common alternative, including Splunk's own newer model — charges for search and processing capacity rather than raw ingestion.[2] Under this model, dropping a noisy event doesn't save you money the way it does under ingest-based pricing, because you were never billed for storing it in the first place. It still helps — less noise, faster searches, better analyst signal-to-noise — but the dollar signal is indirect.
Tiered ingestion is the newest wrinkle. Microsoft Sentinel now offers Basic and Auxiliary log tiers priced roughly 80% and 95%+ below the Analytics tier respectively, in exchange for giving up scheduled real-time correlation.[3] That changes the decision from a binary "keep or drop" into a third option: keep the data queryable for compliance and retroactive hunting, just stop paying full price to alert on it in real time.
Knowing which model you're on changes the right move. A team on ingest-based pricing gets a direct financial reward for aggressive filtering. A team on workload-based pricing gets a smaller, indirect one — and should weight the decision more toward detection value and less toward raw volume, since volume alone won't move the bill much.
A framework that isn't "turn more on" or "turn less on"
The actual skill here isn't a universal setting. It's matching monitoring effort to detection value, one event at a time, and being able to defend that match in a budget conversation. In practice that means every event a fleet can generate falls into roughly one of four buckets:
- Keep. Required for real detection value, and cheap enough that there's no meaningful tradeoff to make. Most of a well-tuned baseline lives here.
- Filter. Required, but high-volume enough that collecting it unscoped is wasteful. The fix usually isn't dropping the event — it's narrowing what triggers it. Logon Type filtering on 4624, command-line scoping on process creation, encryption-type filtering on Kerberos ticket requests — these routinely cut volume by 60–80% while keeping the detections that actually matter.
- Sample or route. Optional, noisy, with no clean scoping rule available. A statistical sample — or, where the platform supports it, a cheaper storage tier — keeps the pattern visible without paying full retention cost for every instance. This is a real tradeoff: sampling security data risks missing the specific event that would have mattered, so it's a fit for genuinely low-value telemetry, not a default.
- Drop. Low value regardless of volume. No realistic filtering or sampling makes the ingestion cost worth it. These are usually the easiest calls in the whole exercise once someone actually looks.
What makes this framework work is that it forces the question "why does this event earn its cost" to be answered explicitly, for each source, instead of assumed once at setup and never revisited. Most environments never had that conversation. They had a default template, an auditor's checklist, or a predecessor's configuration, and it calcified.
The part nobody wants to hear
There isn't a universal answer for what to keep. The right mix depends on your threat model, your regulatory obligations, your existing detection coverage, and your actual budget — not a generic best-practices list. Two organizations with identical Windows fleets can have entirely different correct answers if one is a highly regulated financial institution and the other is a five-person startup. What's constant isn't the specific configuration; it's the discipline of making the tradeoff on purpose, event by event, instead of by accident.
That's the gap GravityLog is built to close — not a generic "enable more logging" checklist, but sourced, specific reasoning for individual event codes, cross-referenced against what they actually evidence for NIST 800-53 and MITRE ATT&CK, with a live scanner that shows exactly what your own configuration buys you and what it costs. The tradeoffs were always there. The point is making them visible.