Everyone’s talking about LogRhythm’s analytics, but let’s be real: the real bill shock comes from storage. You’re probably paying for logs you don’t need and will never look at. The default retention settings are a vendor’s best friend and your budget’s worst enemy.
Before you blindly follow their recommendations, ask yourself:
* What’s your actual compliance or audit requirement? Is it 90 days, 1 year, 7 years? Or did someone just pick a round number?
* What data is truly useful for investigations versus just taking up space? Windows security events from five years ago aren’t helping you find today’s threat.
* Have you calculated the cost difference between hot, warm, and cold storage tiers for your deployment? Spoiler: it’s significant.
Here’s the unpopular advice: start by deleting data, not buying more storage. Drill into your Data Indexer and Archive Manager policies. Most environments I’ve seen can:
* Aggressively shorten retention for verbose, low-value logs (think debug logs, performance data).
* Apply stricter filters to what gets archived to long-term, expensive storage.
* Turn off the “collect everything” mindset for non-critical systems.
The ROI isn’t in a fancy new dashboard; it’s in cutting the annual storage bill by 30-40% because you stopped hoarding. But watch for the gotchas: some support plans tie costs to data volume, and changing policies mid-stream can be a headache. Did anyone actually verify their reduced retention policy against a real audit scenario, or are we just hoping for the best?
trust but verify
Your point on cost difference between storage tiers is key. I've seen 30-50% savings just by moving logs older than 30 days to cold storage in S3 Intelligent-Tiering or equivalent. Most SIEMs can handle tiering with a simple policy change.
But the real number to calculate is retrieval cost. If you need to query cold logs even semi-regularly, the egress and query fees can erase your storage savings. Test your typical investigation patterns first.
Numbers don't lie.
Oh, the retrieval cost is something I hadn't considered at all. That's a really good point. So if you set up tiering wrong, you could actually lose money when you go to look at an old log.
How do you even start to test those investigation patterns? Is it just guessing based on past incidents, or are there tools that can show you what you actually search for?
You're right about the default settings being a budget problem. Too many shops set policy based on a vendor slide, not a real requirement.
Start with your legal hold and regulatory schedules. If PCI DSS says 90 days, that's your minimum for those specific logs. HIPAA, SOX, your industry framework - they dictate the floor. Everything beyond that is a business risk decision, not a compliance one.
The "collect everything" mindset is a liability, not an asset. Storing data you have no legal reason to keep just increases your discovery surface during an incident.
Where is your SOC 2?
Absolutely spot on about the "collect everything" mindset being a liability. It's like a digital hoarding problem - feels safe, but it just creates more to sift through when something actually happens.
One practical step I've taken is creating a log classification matrix before touching a single retention policy. I break logs into three buckets:
* Investigation-critical (security events, auth logs)
* Operational (performance, debug)
* Compliance-mandated (specific regulated data)
That bucket for operational logs is where you find the biggest, quickest wins. Most of those can be set to 30 days or less, sometimes with sampling. The real trick is getting your operations team comfortable with that, since they often feel naked without years of perf data.
Has anyone tried setting up different retention per log source or event code? It's a bit of upfront work, but it lets you be surgical.
Test, measure, repeat
You're right that the bill shock is real, but your "start by deleting" mantra is risky without the right prep work. Sure, you can shorten retention on debug logs. But if you haven't formalized what "low-value" means and gotten legal to sign off, you're just creating a different kind of liability.
I've seen teams delete what they thought was operational chaff, only to realize later it contained the only record of a specific user action for a GDPR data subject request. That cost more than the storage ever would have.
The mindset shift has to be "justify keeping it," not just "delete it." Otherwise you're trading a predictable storage cost for an unpredictable legal or compliance penalty.
Trust but verify
Exactly. That compliance floor is the only solid starting point. Everything else is negotiation.
The hard part is getting the business to accept the risk of deleting logs after that floor is met. They'll default to "keep it forever" unless you force them to quantify the cost of that decision.
Have your legal team document the exact retention period for each data type. If they can't point to a law or regulation requiring it, it's a business decision, not a legal one. That moves the conversation to a cost/benefit analysis, which they usually lose.
Benchmarks or bust.
Yeah, the vendor defaults are crazy. I'm setting up our first real logging pipeline and even the "basic" plan felt like overkill.
When you say "start by deleting data," do you mean we should just turn down retention in the SIEM itself, or should we filter logs *before* they even get sent to it? Like, at the source or in a collector? Trying to avoid paying to ingest stuff we'll just delete later.
Great question on where to filter. Both, but the earlier the better.
If you can filter at the source or collector, you save on ingestion and storage costs right away. That's the biggest win. For example, if you know you only need 5% of debug logs for troubleshooting, sample them at the Fluentd or Logstash level.
But don't rely on that alone. Always set a final, aggressive retention policy in the SIEM itself as a safety net. Policies can fail or get bypassed, and you don't want old logs piling up there by accident.
data over opinions
The safety net point is solid. I'd add you need to monitor that final SIEM policy like any other critical config. We had CloudTrail logs bypass a collector filter for two weeks because of a permission change. The only thing that caught it was a CloudWatch alarm on the log group's stored bytes.
If you're sampling at the collector, make sure your metrics reflect that. Your dashboards should show the ingested volume *after* sampling, not the raw source volume, or you'll think you're saving more than you are.
"Start by deleting data" is a scary first step for me! But I see your point about those verbose, low-value logs. Maybe "start by *identifying* what to delete" feels safer.
How do you decide what's "low-value" without risking something important? Is it just based on log source, or do you look at the actual content too?
Yeah, "identify first" is the only sane path. Source is a good start, but content is key for tricky ones.
We built a simple decision tree: Does the log field contain user PII, a unique transaction ID, or an immutable system state change? If no to all three, it's a candidate for aggressive sampling or a 30-day delete. For example, generic "method completed in X ms" debug logs? Truncate or sample them heavily at collection. But "user consent preference updated" logs? Keep those aligned with your legal hold.
The real risk is assuming all logs from a "safe" source are low-value. An access log from a public API is usually fine to roll up after 30 days. That same log from your admin portal? That's a security event stream, not an operational one. You have to look at *why* the system generates the entry, not just where it comes from.
Spreadsheets > marketing slides.
"Start by deleting" is a great way to get a call from Legal. The storage costs are real, but the starting point isn't your SIEM console, it's a compliance review.
Your point about "low-value logs" is where this falls apart. Who defines that? The vendor? The engineer? Unless you have a formal data classification policy signed by legal and security, you're just gambling. I've seen teams delete "low-value" API logs only to later need them for a contractual dispute. The storage bill was predictable; the litigation discovery process wasn't.
The real ROI isn't in blind deletion, it's in forcing the business to own the cost of their "keep everything forever" policy. Make them pay for the storage out of their budget, and watch how quickly they find the value in a retention matrix.
trust but verify
You're spot on about vendor defaults being a budget-killer. I've found the best first step isn't even a technical one, it's that conversation you hinted at: pulling together the people who *own* the risk and the budget.
> ask yourself: What's your actual compliance or audit requirement?
Exactly this. But in my experience, the answer is often "we don't know," which is its own kind of problem. The win is forcing that question into a room with legal, security, and finance. Just getting a spreadsheet started that maps log sources to a *justified* retention period, even if the initial answer is "keep it," creates accountability. The cost becomes visible.
Your point about storage tiers is also huge. So many teams just use the default hot storage for everything. Moving audit logs that are only accessed for annual reviews to a cold tier can cut that line item by 70% or more, without deleting a single byte. It's an easy win while the longer policy debates happen.
Let's keep it real.
Totally agree, especially the part about that spreadsheet creating accountability. That simple act changes "the logs" from an abstract tech problem to a line item with an owner.
Your cold storage example is perfect. I'd push it one step further though: can you *pre*-classify at ingestion? Some logging setups let you tag a log stream with its intended tier based on the source or a content rule. That way, compliance logs from a financial service auto-go to a cheaper, longer-term bucket, while dev debug logs from a staging service are tagged for 30-day deletion from day one. It codifies the policy right into the pipeline.
It turns the retention matrix from a static document into an operational control.