The Alert Tax: Why Your SOC is Burning Out Your Best People

Your best Tier 1 analyst just gave notice.

She’s been with you 18 months. She didn’t quit because of the hours. She didn’t quit because of the pay. She quit because for 18 months she has triaged the same five false-positive alerts, in the same five tools that don’t talk to each other, against the same three-paragraph playbook PDFs that nobody has updated since 2022. She quit because the work had stopped meaning anything.

You will replace her. The replacement will quit too, in roughly 14 months, for roughly the same reasons. And while you cycle through analysts, the real attacks — the ones that don’t look like the 47,000 noisy alerts your SIEM produced this week — will continue to land.

This is the Alert Tax.

It is the hidden cost your organisation pays — in analyst time, in burnout, in missed real attacks, in cyber insurance premiums, in board credibility — when your SOC has been built for coverage rather than outcomes. It is the gap between "we have 8,000 detections deployed" and "we stop attacks."

After a decade of designing, deploying, and rescuing SOCs for clients across critical infrastructure, energy, ports, manufacturing, and financial services in Asia-Pacific, we’ve come to recognise seven patterns that every overwhelmed SOC has in common. This is the field guide.

The Alert Tax, defined

A healthy SOC is a closed feedback loop: detections fire, analysts triage with context, response runs to plan, learnings flow back into detection engineering. The loop tightens over time. False positives go down. Real attacks get caught earlier. Analysts grow.

An unhealthy SOC is a leaky pipe. The loop breaks at every joint. The Alert Tax is what you pay at every leak.

flowchart LR
    A["Detection<br/>Coverage by technique?"] --> B["Triage<br/>Context in one place?"]
    B --> C["Response<br/>Playbook as code?"]
    C --> D["Learning<br/>Feedback to engineering?"]
    D -.->|"Improves detections"| A
    A -.->|"Alert Tax"| TAX["Burnout<br/>Missed attacks<br/>Retention churn"]
    B -.->|"Alert Tax"| TAX
    C -.->|"Alert Tax"| TAX
    D -.->|"Alert Tax"| TAX

The seven patterns below are the seven most common places the loop breaks. If your SOC is bleeding people and missing attacks, you are paying the Alert Tax at one or more of these joints.

Pattern 1: Coverage measured by alert count, not adversary technique

What goes wrong: The vendor sold you on 8,000 out-of-the-box detections. Your dashboard proudly shows "47,000 alerts last month." Nobody can answer the question "are we covered against the 14 MITRE ATT&CK techniques most relevant to our industry?"

Symptom: When the board asks "are we secure?", the team answers with alert volume. The CISO walks out of that meeting feeling somehow less confident than before.

Fix: Map every detection to a MITRE ATT&CK technique. Score coverage by technique, not by alert volume. Run Atomic Red Team or similar to actually test that your detections fire on the techniques you claim to cover. Most SOCs we audit discover that they have hundreds of detections for half a dozen techniques and zero detections for techniques the industry threat reports flag as most common against them. You can be drowning in alerts and still uncovered.

Pattern 2: Detection rules are unversioned, untested, unaccountable

What goes wrong: Detection rules live in the SIEM UI. Changes are made by clicking buttons. No git. No code review. No rollback. No testing before production. The senior detection engineer who built half the rules left two years ago and nobody else fully understands the regex.

Symptom: Someone edits a rule at 4pm Friday. Tier 1 is buried in 18,000 false positives all weekend. Nobody can roll it back because nobody knows what it looked like before.

Fix: Detection-as-code. Wazuh rules, Elastic detections, Sigma — whatever your platform, every rule lives in git, with PR review, with automated testing against historical data. We deploy our Wazuh clients this way: every custom rule is a YAML file in git, with paired test cases proving it fires on known-bad events and is silent on known-good events. Detections are software. Treat them like software.

Pattern 3: Playbooks are PDFs, not code

What goes wrong: "When alert X fires, do steps 1–7 from this Confluence page." Tier 1 has to read, interpret, switch between four tools, copy-paste IoCs, remember context across seven steps, and decide what to do at the end of it. The playbook was written in 2022 by someone who has since left.

Symptom: The same kind of alert takes longer to triage than it did six months ago. Analysts cherry-pick the easy alerts. The hard ones age in the queue.

Fix: Playbooks are SOAR workflows. Shuffle, Tines, n8n, XSOAR — whichever fits your budget and skill profile. The analyst clicks one button; the SOAR gathers context, enriches IoCs, opens a ticket with the relevant evidence pre-populated, and presents a decision. The analyst makes decisions. The machine does data-gathering. This is the single biggest leverage point in any overwhelmed SOC. Our open-source default — Wazuh → soc-integrator → Shuffle SOAR → DFIR-IRIS — gets a typical Tier 1 from 45-minute triage to 5-minute decision-making on the high-volume alert classes.

Pattern 4: Context scattered across 4–6 systems

What goes wrong: Alert in the SIEM. Asset details in the CMDB. User info in the IdP. Network data in the firewall console. Endpoint data in the EDR. Ticket in the ITSM. Tier 1 logs into 4–6 separate consoles to triage one alert.

Symptom: Mean time to triage is measured in hours, not minutes. Analysts complain about "swivel-chair triage." Context lost between tools is the most common cause of missed escalations.

Fix: A single triage view that aggregates context. This is what we built soc-integrator for — a thin FastAPI middleware that queries Wazuh, OpenSearch, the CMDB, the user directory, and the threat intel platform; normalises the data; and presents the analyst (or Shuffle SOAR for automated enrichment) with a single object per alert. One alert. One screen. One decision. Whatever tooling you’re on, the principle is the same: aggregate at the seam, not at the eyeball.

Pattern 5: No measurement per detection

What goes wrong: You know your SIEM has 8,000 detections enabled. You don’t know:

• Which detections have ever caught a real incident
• Which have a false positive rate above 95%
• Which have a mean time to triage above 30 minutes
• Which haven’t fired in 12 months and are silently consuming licence costs

Symptom: Detection backlog grows indefinitely. Nobody is willing to retire detections because nobody knows which are load-bearing. New detections pile on top of old ones.

Fix: Per-detection metrics, owned. Every detection has a named owner, a documented MITRE mapping, a measured precision/recall, a TTD/TTR target, and a review date. Retire detections that haven’t fired in 90 days or run an FP rate above 95%, unless there’s a documented compliance reason to keep them. A detection without metrics is a guess wearing a uniform.

Pattern 6: Threat intel is consumed, not contextualised

What goes wrong: You buy a threat intel feed. You import indicators. They sit in the SIEM. An alert fires that matches an IoC from the feed — and the only context attached is "this IP appeared in some research blog eight months ago." The analyst shrugs and closes it.

Symptom: Threat intel hits are routinely ignored. Analysts have learned that the cost of acting on them (digging for context) exceeds the value.

Fix: Enrich at ingestion, not at alert time. When an IoC arrives in your platform, enrich it with structured context: who published it, what campaign, what TTPs, what industry was targeted, when it was last seen. When the IoC then matches in your environment, the analyst sees not just "match!" but "match against APT group X, currently targeting your industry, here are their three most common follow-on techniques — pivot to those telemetry sources first." Threat intel pays for itself only when context arrives before the alert does.

Pattern 7: No feedback loop from incident to detection

What goes wrong: An incident happens. The IR team investigates. They figure out what happened, what was missed, what would have caught it earlier. That knowledge stays with the IR team — in the post-incident report PDF that nobody outside IR reads. The detection engineering team isn’t in the retrospective. The SOC keeps generating the same kind of noise that missed this incident.

Symptom: Same classes of incidents recur. Detection coverage doesn’t improve from real-world learning. Each incident is treated as a one-off rather than a lesson.

Fix: Every incident retrospective produces at least one detection engineering action item — a new detection, a tuning, an enrichment improvement, a playbook update — with a named owner and a deadline. Track it in your IR case management (DFIR-IRIS works well for this) so it’s auditable. An incident that didn’t change your detection logic is an incident your SOC didn’t actually learn from.

The pattern behind the patterns

Notice what is not on this list: which SIEM you bought, which EDR you bought, how much you spend on threat intel feeds, whether you have an MSSP. These are the questions vendors want you to argue about. The seven patterns above are the ones that decide whether your SOC actually stops attacks — and they are mostly free to fix, in the sense that they require process and architecture changes rather than new licences.

This is the same lesson we keep relearning. In AI systems, the model is the cheap part — the integration with enterprise data is the system. In ERP integrations, the connector is the cheap part — the seam between systems is the system. In SOCs, the SIEM is the cheap part — the detection economics and the closed feedback loop are the system.

New technology, same physics. Software value lives in the loops.

What we’d do if it were our problem

A pragmatic 90-day path from drowning SOC to healthy detection economics:

Weeks	Focus
1–2	SOC tune-up audit. Map current detections to MITRE ATT&CK. Identify the worst FP offenders. Inventory the playbook PDFs.
3–6	Detection-as-code rollout for the top 50 detections. Retire the worst FP generators. Move the three highest-volume playbooks into SOAR.
7–10	Single triage view: stitch SIEM, asset, identity, and threat intel context into one screen via soc-integrator or equivalent.
11–12	Feedback loop in place. Per-detection metrics dashboard. IR retrospectives produce detection action items. Burnout indicators start moving the right way.

It is not glamorous. It is what works.

Where Simplico fits

We’ve spent the last decade designing and operating SOCs for clients across critical infrastructure, ports, manufacturing, and financial services. Our default open-source stack — Wazuh, OpenSearch, Shuffle SOAR, DFIR-IRIS, glued together with our own soc-integrator middleware — is built specifically to fix the seven patterns in this post. We also work inside Splunk, QRadar, Sentinel, and Elastic stacks when that’s what the client already runs.

If your SOC is paying the Alert Tax — losing people, missing real attacks, drowning in noise — we’d be happy to take a look.

Book a free SOC tune-up →

A 90-minute call with one of our detection engineers. We’ll review your current detection economics, name which of the seven patterns is bleeding you, and leave you with a one-page tune-up plan. No slideware.

---

Simplico is a Bangkok-based engineering studio specialising in AI/RAG, cybersecurity, ERP integrations, ecommerce, and mobile delivery. We work with enterprise teams across Thai, Japanese, Chinese, and English-speaking markets.