Reducing Storage Spend: The CISOs Guide to Efficient and Effective Security Operations

The security industry treats storage like weather: a large monthly bill you complain about and then pay, because the data feels necessary and the alternative feels harder. Matt, Lead Solutions Engineer at LimaCharlie, opened this session, part two of a four-part guide to efficient and effective security operations, by refusing that resignation. His argument is narrower and more uncomfortable than "storage is expensive." It is that most of what teams spend on storage is not buying them security at all. It is paying for a reflex, and the reflex is the thing worth examining.

The reflex is "everything forever everywhere"

The habit Matt keeps circling back to is the instinct to keep all data, indefinitely, on the theory that an investigation might one day need it. He calls this the legacy security mindset, and he attacks it on its own terms rather than on cost. A posture that depends on complete historical telemetry assumes the telemetry will still be there when you reach for it. Adversaries have a vote. They use evasion, data deletion, and destruction techniques, and a ransomware event can take the entire store with it. So the team that justifies its retention bill by saying "if we get breached we will go back and look at all the evidence" is not actually buying the safety it thinks it is. It is paying a premium for evidence an attacker can erase.

The better objective, in his framing, is to detect and operationalize faster so investigations do not rest on hoarding years of data in the first place. That reframing is what makes the cost conversation possible. Once you stop treating total retention as a proxy for diligence, you can ask the question that actually saves money: what does the organization need to keep, and why. Matt splits the answer into critical data, which drives a function like detection and response, security alerting, telemetry, IT operations, or network engineering, and non-critical data, the "just in case" sediment of custom application logs, leftover demo and POC environments, test data, training data, and legacy data with no retention requirement attached to it. His recommended exercise is deliberately mundane. Hold an audit day, buy the team lunch, and compare two numbers: the data the security team collects against the data it actually uses. Price the gap. The gap, he says, is almost always where the savings are sitting.

Compliance is the one place he will not negotiate. GDPR, HIPAA, financial regulators, e-discovery, court cases, and subpoenas impose real obligations, and those have to be honored in both the retention strategy and the budget. Drawing on time he spent in the early 2010s doing forensic acquisitions under seven to ten year legal holds, his point is that even mandatory retention can be optimized: deduplicate and rotate data, push older data to cold storage, and stop paying hot-storage prices for data nobody is querying.

The cloud-savings story has a scale problem

Matt is just as skeptical of the easy answer as he is of the expensive habit. Cloud-native storage gets sold on a familiar set of promises, cost savings, infinite scale, and no infrastructure to manage, and he picks the cost promise apart. The well-written engineering blog posts about a well-known video streaming company saving heavily by migrating from one cloud storage approach to another are real, but they describe organizations operating at a scale almost nobody reading actually occupies. Below that scale, the more common outcome is overpaying because a tier or a band locks you in, or because you had to commit to a certain storage level just to qualify for the benefits in the first place. He is equally blunt about the reverse move, pulling large footprints of data back out of the cloud to an on-prem store in the name of saving, which frequently is not a saving once you look at the full cost. He cites a 2023 State of the Cloud report finding that 89 percent of enterprises run a multi-cloud strategy, which he reads as proof that comfort with the cloud is not the obstacle. Pricing is.

LimaCharlie's model is his counterexample, and the design choices map directly onto the problems he just described. Storage is pay-as-you-go by the gigabyte uploaded, with no tiered bands: one gigabyte costs X, ten gigabytes cost ten times X, and it scales as far as the cloud does. Every data type sent in carries a full year of retention by default, whether that is LimaCharlie EDR sensor telemetry or a gigabyte of plain-text log files uploaded for analysis. If you need longer retention or need to route data to cold storage, output options move it elsewhere in about thirty seconds. And the security controls he treats as table stakes rather than upsells, ACLs, SSO, and granular access at both the API and UI level, exist so that giving incident response, the SOC, threat hunters, a CTI team, network engineers, and IT operations the right slice of data never requires standing up a separate storage system just to satisfy an access requirement. The data stays yours, not something mined for the platform's own purposes.

Most of the spend is movement, not analysis

The sharpest idea in the session is that teams are optimizing the wrong stage. The expensive part of a data architecture, Matt argues, is rarely the analysis. It is getting data into the position where analysts can use it. The common pattern has sources like EDR, SaaS platforms, third-party apps, and cloud feeding into storage, and analysts pulling from that storage into dashboards, SOAR, and ticketing. The "send everything everywhere every time" reflex means a team spends more preparing data than analyzing it, and the problem compounds when data lands in multiple buckets while analysts unknowingly pull from different ones, which loops straight back to the tool-sprawl theme from part one. He cites a 2022 Gartner report putting the cost of poor data quality at an average of 13 million dollars a year, money he would rather see funding a couple of analysts.

His fix treats the platform as a hub and storage as a throttle. Let sources feed into one place, optimize what goes in, then use customizable output to send each downstream tool only what it needs: fuller telemetry to a dashboard, alerts or system telemetry to a SOAR platform, succinct summaries with reference links to a ticketing system, and compliance-bound or long-term data out to retention, turned on and off as obligations require. When a dashboard's needs change, you raise or lower the throttle rather than re-architecting the pipe. He makes the absurdity of the alternative concrete with a team evaluating an AI XDR product that asked for all Windows event logs in order to read five event IDs, the firehose turned on to capture five drops of water. The payoff is not theoretical: he points to a US-based MDR that left its final-stage analyst workflows untouched, fixed only the data transition and infrastructure layer beneath them, and brought costs down by six figures.

That last example is the whole argument in miniature, and it is the one MSSPs and MDRs should sit with. The analyst tooling that works can stay. What multiplies across every tenant you run is the roughly 70 to 80 percent of data movement that happens before an analyst ever touches it, and that is the layer where, by Matt's account, six and seven figure reductions tend to hide. Storage spend is not a fixed cost of doing security. It is mostly a tax on a habit, and the habit is optional.