The first detection engineering maturity assessment we ran in 2026 produced a result that surprised the CISO and ultimately reshaped the program. The SOC had 4,712 detection rules in production. Of those, 312 had fired in the previous twelve months. Of those 312, only 47 had produced a confirmed incident. The remaining rules existed because a vendor recommended them, a previous engineer wrote them, or an auditor expected them. The SOC was paying analyst attention on every alert, but the program had no mechanism for asking which detections were earning their keep. The mature programs we now work with have inverted the question. They do not ask how many rules they have. They ask which rules they would write again today.
This is the central tension of modern detection engineering. The catalog of possible detections has grown faster than any team’s capacity to maintain them. The MITRE ATT&CK framework now enumerates hundreds of techniques across dozens of tactics, and every detection vendor markets coverage of that matrix as a primary feature. Coverage, however, is not the same as quality. A SOC with broad coverage and shallow tuning produces a higher alert volume, a lower investigation depth, and an analyst team that learns to ignore the signal that matters. The Verizon DBIR has, for three years running, observed that the median dwell time of a successful intrusion is no longer constrained by the attacker’s stealth but by the defender’s alert fatigue.
Why Detection Engineering Has Become Its Own Discipline in 2026
For most of the SIEM era, detections were a side project for whichever analyst had the bandwidth to write one. The result was a body of content that nobody owned, nobody tested, and nobody retired. The mature programs we work with have professionalized the function. Detection engineering is a named role with a defined backlog, a release cycle, a peer-review process, and a measurable output. The output is not the count of rules deployed. The output is the count of incidents detected, with mean time to detection, false positive rate, and rule lifecycle metrics treated as first-class measures.
“The best detection engineering programs we see have stopped treating rules as artifacts and started treating them as software. They have a backlog, a release process, a test suite, and a deprecation policy. They write rules the way good teams write code, and the result is a body of content that gets sharper over time instead of broader.”
Senior detection engineer, iSECTECH engagement notes
The shift is visible in hiring patterns, in vendor positioning, and in budget allocation. The CISA guidance on operational technology and enterprise detection has, for the past two years, explicitly called for engineering rigor in detection content rather than coverage breadth. The mature programs treat this as a basic competency. The immature ones treat it as a future ambition.
Three Engagements That Defined Our Detection Engineering Playbook
Engagement One: The SOC With Four Thousand Unused Rules
A regional bank engaged us to review a SOC that was producing 230 alerts per analyst per shift. The analysts were exhausted, the false positive rate exceeded ninety-two percent, and a recent red team had moved from initial access to domain admin in seventeen minutes without producing a single ticket. The assessment showed that 4,712 detections existed in the platform but only 312 had fired in a year. The remediation was not to write more detections. The remediation was to retire 4,108 of them, keep the 312 that had produced any output, and rebuild the alert pipeline around the 47 that had produced a real incident. Alert volume fell ninety-three percent in eight weeks. Confirmed incident detection rose.
Engagement Two: The Detection That Caught the Wrong Thing for Two Years
A technology company asked us to investigate why a long-standing detection had never produced a high-fidelity incident. The rule, written in 2024, had been intended to flag suspicious PowerShell execution. It had fired roughly four hundred times per month and consumed an estimated thousand hours of analyst time over its lifetime. On review, the rule was matching a developer toolchain that had been deployed shortly after the rule was written. The rule had been correct the day it shipped and obsolete the next day. No one had reviewed it. No one owned it. The retirement of that single rule recovered a quarter of an analyst’s annual capacity.
Engagement Three: The Hunt That Became a Detection That Became an Incident
A manufacturing client asked us to help operationalize a threat hunt that had identified an unusual lateral movement pattern. The hunt was good. The conversion to a production detection was where the program had previously broken down. We worked through the lifecycle: hypothesis, data confirmation, rule expression, test cases, false positive baseline, deployment, runbook, ownership, and review cadence. Three months later, the same detection caught a credential theft attempt in progress and triggered a containment that prevented a ransomware deployment. The detection paid for the entire engagement in a single incident.
Why Traditional SIEM Approaches Produce Worse Outcomes Over Time
The traditional SIEM model treats detection content as configuration. Configuration accumulates. Configuration is not retired. Configuration is owned, when it is owned at all, by whoever happens to remember writing it. Detection engineering, treated as software, has version control, code review, unit tests, performance benchmarks, and a deprecation policy. The first model produces an ever-larger rule catalog with declining incident output. The second model produces a stable or shrinking rule catalog with rising incident output.
“You cannot tune your way out of a four-thousand-rule SIEM. The only way out is to delete. Most teams are afraid to delete because they are afraid of the rule they delete being the one that would have caught the next breach. The truth is the rules they have not retired are the ones quietly hiding the breach already.”
Anton Chuvakin, public commentary on SIEM operations
The Detection Engineering Playbook We Run With Every Client
The playbook rests on four practices, executed in sequence. The first is inventory. Every detection in production must have an identified owner, a documented hypothesis, a test suite, a known false positive baseline, and a last-fired date. Rules without owners are deprecated within a quarter. The second is release discipline. New detections enter through a peer-reviewed pipeline with required test cases and a documented runbook. No rule reaches production without ownership and a hypothesis. The third is retirement cadence. Quarterly review of every rule against a deletion bar: did it fire, did its firings produce decisions, would we write it again today. The fourth is measurement. The program reports on mean time to detection, true positive rate by detection family, and the ratio of detections that produced an incident to detections that produced an alert.
What Boards Should Demand This Quarter
The board questions that produce real change in detection engineering are not about rule count. They are about retirement rate, ownership coverage, and the ratio of detections that have produced an incident in the past year. A SOC that cannot answer those questions does not have a detection engineering program. It has a rule catalog. The distinction is the difference between a SOC that detects breaches and one that documents them after the fact. The NIST Cybersecurity Framework calls this the Detect function, and the maturity that distinguishes the best programs is engineering rigor, not coverage breadth.
“The boards that ask ‘how many rules do we have?’ get programs that maximize rule count. The boards that ask ‘which rules produced the last three incidents?’ get programs that maximize incident detection. The question shapes the program more than any budget line ever will.”
iSECTECH SOC maturity review summary
How This Connects to the Rest of Your Security Program
Detection engineering does not stand alone. It connects to the alert fatigue conversation we have written about previously, to the insider threat program design we have documented, and to the backup recovery discipline that determines whether a detected incident becomes a contained incident. A SOC with mature detection engineering and poor response orchestration still loses. A SOC with mature response and immature detection never gets the chance to respond. The two disciplines have to mature together.
What to Do This Week
Three concrete actions, in order. Pull a report of every detection in your SIEM that has not fired in twelve months and propose half of them for retirement. Identify every detection in production without a documented owner and assign one. Build a single dashboard that shows, for every detection family, the count of detections, the count that fired, and the count that produced a confirmed incident in the past year. None of this requires a new tool. All of it requires the discipline to look.
Talk to a Senior Detection Engineering Practitioner
If your SOC is working through a detection content maturity review, a SIEM migration, or a coverage assessment, our senior practitioners can help. Talk to a senior iSECTECH practitioner about a confidential review of your detection portfolio and the three changes that would most improve incident detection this quarter. The World Economic Forum’s Global Cybersecurity Outlook continues to identify detection capacity as a defining capability for resilient organizations.
Why Retirement Is the Underrated Detection Engineering Skill
The conversation about detection engineering tends to focus on authorship. The mature programs treat retirement with equal seriousness. A rule that has not fired in a year is occupying compute, attention, and audit complexity. A rule that fires only false positives is actively training analysts to ignore the platform. The discipline of retirement is what allows the rest of the program to function. Without it, the catalog grows until the team drowns.
Continue Reading: Week 5 Field Notes
For the broader operational picture of how detection engineering interacts with SOC capacity and incident response, continue with our notes on alert fatigue and detection collapse, executive tabletop exercises, and the cyber risk appetite question. The thread connecting them is consistent: maturity in security is measured not by what an organization has deployed but by what it has chosen to deprecate.