Why Your Siem Cannot Answer Simple Questions

Every enterprise has automation it is afraid to turn on. The SOAR playbook that could disable a compromised account runs in 'create a ticket' mode, because the one time it ran for real it locked out a departmental VP during quarter close. The lesson organisations draw — automation is dangerous — is the wrong lesson. The right one is that automation without graduated governance is dangerous.

The change board's questions are legitimate: What exactly will this action touch? What happens if the verdict is wrong? Who approved this scope, and how do we undo it? Most automation platforms answer none of these. They offer a run button and a log, which is why enterprise response automation stalls at sending notifications while actual containment still waits for a human with production access and a change ticket.

Closing the gap requires treating autonomy as something earned per action class, not granted globally: recommend-only until precision is proven, approval gates where blast radius warrants, dry-run previews before anything writes, rollback state recorded for everything reversible, and a kill switch that stops it all instantly. With those primitives, automation stops being a leap of faith and becomes a controlled delegation — which is the only form of delegation an enterprise should accept.

The average enterprise security stack now counts between forty-five and seventy-five tools. An analyst investigating a single suspicious login touches six of them: the SIEM for the alert, the identity provider for auth history, the EDR console for host state, the cloud console for API activity, the ticketing system for context, and a threat-intel portal for reputation. Each hop costs minutes, a login, and a mental context switch — and each tool speaks its own schema, so the analyst becomes a human ETL pipeline, joining datasets in their head at 2 a.m.

Vendors sell integration as the answer, but a webhook that copies an alert from one queue to another is not integration; it is duplication with extra latency. The join the analyst actually needs — this identity, across these five systems, over the last ninety days, compared against its own baseline — does not exist in any single console. It has to be rebuilt by hand for every investigation, which is why an investigation that should take ten minutes takes four hours.

The strategic cost is worse than the operational one. Because context lives in fragments, every conclusion is provisional. Analysts hedge, escalate, and re-investigate, and CISOs discover during incidents that their seventy tools produce seventy partial stories and no authoritative one.

Ninety-plus percent of alerts in a typical enterprise queue are false positives, and every one of them costs the same analyst minutes as a real one. But the deeper damage is psychological: after the four-hundredth benign impossible-travel alert, an analyst's prior flips. The default assumption becomes 'this is noise', and the one alert in a thousand that is real gets pattern-matched into the same dismissal. Alert fatigue is not laziness; it is Bayesian reasoning applied to a broken signal.

So teams tune. Detection engineers spend their weeks adding exceptions — this service account, that IP range, this VP who travels. Each exception fixes today's noise and silently narrows tomorrow's coverage, and nobody re-reviews the pile because there is no time. Tuning debt accumulates exactly like technical debt, invisible until an attacker walks through a hole that was carved out to silence a false positive in 2024.

The root cause is that static rules cannot encode context. Whether a login from Lisbon is suspicious depends entirely on who the identity is and what it usually does. Without a behavioural baseline per identity and per asset, every threshold is wrong for someone — too loud for the traveller, too quiet for the service account that should never leave the building.

Enterprises that give up on in-house coverage buy MDR, and most discover the same frustration within a year: the service is a black box. Alerts go in, closed tickets come out, and the reasoning in between is invisible. When the quarterly report says '14,000 alerts triaged, 12 escalated', there is no way to verify that the 13,988 closures were sound. You are asked to trust, without evidence, the same category of overloaded human analyst you were trying to escape — just employed by someone else.

The contract structure makes it worse. Response actions require a phone call and a change window. Data lives in the provider's tenant, so leaving means losing history. And when an incident does slip through, the post-mortem devolves into a liability negotiation between your counsel and theirs about what 'detected' means in schedule 3 of the SLA.

None of this means managed outcomes are the wrong goal — 24/7 coverage without building a night shift is exactly what most enterprises need. The failure is opacity. A managed detection function is only trustworthy if every verdict it renders arrives with its evidence attached: the questions asked, the answers found, the weights applied. Transparency is not a nice-to-have in MDR; it is the entire difference between a service and a liability shield.

Walk into any enterprise SOC at 9 a.m. and look at the queue. There will be somewhere between four hundred and four thousand alerts that arrived overnight, and a rota of tier-1 analysts expected to clear them before the next wave lands. The mathematics has not worked for years. A mid-size enterprise generates tens of millions of security events a day; even after correlation and suppression, the alert volume that survives is an order of magnitude beyond what a human team can investigate properly. So teams do what any rational actor does under impossible load: they sample. They work the highs, skim the mediums, and let the lows age out.

The uncomfortable truth is that attackers know this. Post-incident reviews keep finding the same pattern — the intrusion was detected, an alert did fire, and it sat unworked in the queue for eleven days because it was a medium riding behind three hundred other mediums. The detection stack did its job. The operating model around it failed. Detection coverage without triage capacity is not coverage at all; it is a compliance artefact that produces evidence of negligence after the breach.

Enterprises have tried to buy their way out with headcount, offshore tiers, and suppression rules. Each fix decays. Headcount churns, offshore tiers escalate anything ambiguous, and every suppression rule is a small bet that the suppressed pattern will never matter. The queue always wins — unless something other than a human works it.

The average tenure of a tier-1 SOC analyst in a large enterprise is under two years, and exit interviews are monotonous in their consistency: the work is repetitive, the false-positive rate is demoralising, and the path to interesting work is blocked by the queue itself. Organisations respond with wellness programmes and retention bonuses, treating an architectural problem as an HR problem. No bonus makes it fulfilling to close the same impossible-travel false positive forty times a week.

The cost compounds quietly. Every departure takes environment-specific knowledge that never made it into a runbook — which service accounts behave strangely at month-end, which subnet the scanner lives on, which VP travels constantly and trips geo-velocity rules. The replacement starts from zero, triages worse for six months, escalates more noise to tier 2, and the seniors who should be hunting spend their days re-answering questions the departed analyst had already answered.

This is the hidden tax of the human-queue model: the institution never accumulates judgment. Knowledge lives in people, people leave, and the SOC's effective experience level stays permanently junior no matter how long the SOC has existed. Any serious fix has to move that judgment into a system that does not resign.