That four pillar breakdown is super helpful for structuring our own evaluation, thanks! The TCO pillar especially hits home.
I've been nervous about forecasting our own data growth like you mentioned, and some folks here have made great points about "shock scenarios" and factoring in transaction logs from the start. But I'm still stuck on how to actually start the baseline. Do you have your clients pull the last 12 months of logs from all systems, or do you focus on a few key sources first to keep it manageable? I'm worried we'll get lost in the data before we even get to modeling.
One step at a time
Great way to structure the conversation. Your point about moving beyond a feature checklist is exactly right, especially for finance teams who are balancing security with fiscal responsibility.
> forecasting your data growth over 3-5 years, including all log sources
This is the make-or-break part of the TCO pillar. I'd add one specific caveat for finance: you *must* separate your "must-ingest" regulatory logs (like trade audits and access reviews) from your "nice-to-have" security logs. Forecast them separately. Sentinel's commit can become a straitjacket if your mandatory compliance data grows faster than expected, while Splunk's variable cost can scare the budget folks. Showing that split in the model often reveals which licensing philosophy actually matches your risk profile.
Starting with a sample of those high-priority logs, as others mentioned, is the only way to get a real baseline.
That's a fantastic, practical way to split the forecast. It forces you to confront the real cost of compliance versus security visibility.
I'd add a tactical step to that: pull a sample of each log type and run a quick classification exercise with legal and your CISO. You might find a chunk of your "must-ingest" data is actually just "must-store" for retention, which can drastically change the ingestion profile. Some data you can batch and cold-store cheaply, only pulling it into your SIEM for active queries if there's an incident or audit. Sentinel can struggle with that pattern if it all counts against the commit, while Splunk's model can sometimes accommodate it more fluidly.
Starting with that separation is key, because it shows procurement you're not just buying a tool, you're buying a strategy for handling two very different data lifecycles.
If it's not measurable, it's not marketing.
Exactly. That separation is the key to building a resilient budget. Your point about "must-store" is crucial. Finance teams often get this, because they deal with retention policies for trade data all the time.
Where I've seen it get messy is when the SIEM's search or query language can't efficiently work with that cold-stored data. Splunk's model is fluid, but if you need to query a year of batched logs for an audit, you still pay for that compute and egress. The real cost isn't just the commit, it's the labor to script and retrieve the data.
So the strategy needs a third layer: classifying data as active hunt, incident response, and compliance archive. That shows you need a platform whose strengths align with which layer is your heaviest.
Integrate or die
Spot on about forecasting data growth over 3-5 years. That's the hardest part!
My quick take: don't forget to model the cost of a new product or M&A scenario. For a finance firm, that could mean suddenly ingesting logs from a completely new core system or another company's data. Splunk's variable cost can spike, but Sentinel's commit might break completely, forcing you to renegotiate mid-contract.
I'd add a "shock scenario" column to your model.
Trial first, ask later.