When to retire a detection rule

Every SOC I've looked at has rules nobody remembers writing. They fire, an analyst closes them, and the cycle repeats until someone finally asks what the rule was for.

A detection that never produces a decision is a cost. Not a small one: it takes analyst minutes, it trains people to close things without reading them, and it hides the rule next to it that matters.

A simple test

For each rule, I'd want to know three numbers over the last ninety days: how many times it fired, how many of those led to any action beyond closing the ticket, and how long the average investigation took. A rule with hundreds of fires and zero actions is either badly tuned or detecting something you've decided you don't care about. Either way, it shouldn't be running in its current form.

Three honest outcomes

• Tune it. The behaviour matters but the rule is too broad. Narrow it to the context where it's actually a problem.
• Demote it. It's useful as evidence during an investigation but not worth an alert. Keep it as a searchable event, stop paging on it.
• Retire it. Record why, keep the logic in version control, and move on. If the threat returns, so can the rule.

What usually blocks this

Fear. Nobody wants to be the person who turned off the rule that would have caught the breach. So rules accumulate. The way through is to make retirement a documented decision with an owner, the same way you'd treat any other control change, and to measure the queue afterwards. The SOC that retires rules on purpose has fewer alerts and catches more. That's not a paradox; it's attention.

If your queue is full of rules nobody can explain, that's a conversation worth having before the next real alert gets lost in it.

Explore: More on security operations · Work with me