It's complicated: Why security teams love/hate their SIEM

Introduction

Security teams don’t hate SIEM. They hate what they have had to put up with to get value from it.

Pay more every time data grows. Send everything to one place before you can use it. Spend countless hours tuning detections, chasing false positives, maintaining brittle rules, and stitching together investigations across disconnected tools. Accept vendor lock-in because moving away can feel even more painful, disruptive, and expensive than staying. For CISOs, SOC Managers, and Detection Engineers alike, the relationship has become a familiar mix of dependence and frustration.

And yet, walking away from SIEM is not really the answer. Security teams still need the outcomes SIEM was built to deliver: visibility across the environment, effective detection, fast investigation, and confidence that the organization can identify and respond to threats. The problem is that too often, getting those outcomes requires accepting an architecture, operating model, and cost structure that were designed for a different era.

The frustrations also look different depending on where you sit. The CISO is trying to control costs, reduce risk, and avoid being trapped by a single vendor or architecture. The SOC Manager is focused on analyst productivity, alert overload, and getting investigations to move faster. The Detection Engineer is trying to answer an even more fundamental question: are we actually detecting the threats that matter, and can I trust the detections we already have?

Those tradeoffs are not inherent to SIEM. They are a product of the old way of doing it. As security data volumes explode, AI changes how attackers and defenders operate, and organizations demand more flexibility and control, it is worth asking a simple question: what if we could keep what security teams love about SIEM without putting up with everything they hate?

That is where a new way to SIEM begins.

01: CISO

My data. Their terms.

I'm the CISO. I sign the budget, answer to the Board, and spend more time in renewal conversations than I'd like to admit. I manage a team that's genuinely trying, a hefty SIEM contract, and a security posture I'm increasingly unable to explain in the language the CFO speaks.

What's bothering me:

The data lock-in. When I signed the SIEM contract, I didn't realize I was signing away three separate architectural decisions: what I collect, where I store it, and what I pay per gigabyte. They came bundled. They still do. Every renewal, that bundle gets more expensive.
Compliance is not security. My auditors are satisfied, but I know that my current SIEM only has detection coverage for 22% of known attacker techniques¹ These two facts coexist, but it bothers me to no end. In fact, 70% of security leaders invest primarily to satisfy compliance requirements according to ENISA, and only 35% report measurably faster threat detection as an outcome.²There needs to be a better way.
The update that ate my budget. A large cloud provider pushes a routine agent update to thousands of endpoints overnight. By 9am, our SIEM ingest has spiked 30 to 45%. A license sized for 400 GB/day is now processing 600 GB/day. I'm explaining to the CFO why security spend moved because of a software update we didn't request. This is a pricing model problem, not a planning problem.
No credible exit. I looked. Getting out of a SIEM contract means migrating data, rewriting detections, retraining analysts, rebuilding integrations. The migration is the punishment for choosing wrong. (The vendor designed it that way. Their renewals team is very relaxed.

What I’m actually trying to do

Answer the Board's questions. Right now I have ticket counts. That's not an answer.

Win the budget conversation. My vendor wants a 20% uplift. My CFO wants ROI data.

Show that the program is improving. (Not just "we're compliant˛, but that our defenses are more effective.

Get out from under proprietary storage. When everything is in a vendorˇs format, at their price, in their cloud, it's not my data.

Three decisions. Mine to control.

Same CISO. Different energy. The architecture changed, and with it, a conversation I'd been dreading since Q3 became a conversation I'm finally ready to have. I know what we cover. I know what it costs. I know what happens when we grow. For the first time in a while, I have answers before the questions arrive.

What changed:

I control the three decisions now. What I collect. Where I store it. What I analyze. Not bundled. Not the vendor's call. When my CFO asks why ingest spiked, I have an answer and a lever to pull.
My Board report changed. Not ticket counts. Not "we're compliant." For the first time, I can show coverage by adversary technique, mapped to our threat profile, trending in the right direction quarter over quarter. That's the question they were actually asking.
I maintain flexibility. My data is in open formats, in an infrastructure I control. KQL detections are portable. I can now make decisions that best fit my security program and goals, not just what any vendor is telling me to do.
Storage cost finally matched security value. (Full-fidelity data at predictable prices. Immediate analytics layer, right-sized. A software update no longer moves my security budget.

What I can finally do:

Answer "are we covered?" with a number, a trend line, and a plan to improve it.

Grow without fear. More cloud apps, more users, more devices. Cost scales linearly, not exponentially.

Show the program improving. Quarter over quarter. Coverage moving in the right direction. Sustainable, finally.

My AI works with the complete picture, not a fraction of it. The answers it surfaces are ones I can take to the Board.

What the Board conversation looks like now:

Detection posture management at the strategic level, not technical detail, just the output: an answer to "are we covered?"

02: SOC Manager

The SIEM became the workload.

I run the SOC. I own the queue, the team, the shift schedule, and every escalation that lands at 2am. The metrics I report to the CISO measure how busy we are, not how good we are. My team is excellent, but our tools eat their time. We spend more hours maintaining the SIEM than we spend on actual investigation or improvement. That is not sustainable. I know it. They know it.

What’s bothering me:

The queue is a vanity metric. 70% of SOC teams use "number of incidents handled" as their primary performance metric.⁴ A high queue could mean too many false positives. A low queue could mean broken rules not firing. The number tells me nothing about whether I'm actually catching threats.
Enabled is not the same as healthy. Enabled is not the same as healthy. My dashboard shows 600 rules active. What it doesn't show: how many have a stale telemetry source, a schema that drifted after the last update, or logic that's never been tested against real adversary behavior. 10% of rules in production SIEMs are probably broken, and that's the floor.¹
We spend more time on tools than on threats. Count the hours. Alert tuning. Parser rebuilds after log format changes. Integration fixes after vendor updates. SIEM upgrades that break half the connectors. My analysts are skilled investigators. Most of their day is system administration. The SIEM is supposed to be the instrument, instead it became the maintenance burden.
I can't see what I'm not covering. In 75% of breaches, initial intrusion evidence was present in logs, but not accessible or operationalised at the time.⁵ The data was there. The detection wasn't. I can't fix a gap I can't see.
Investigation eats my analysts' time. Pivoting across five disconnected tools to build a timeline is manual, slow, and entirely dependent on who's on shift.