There is a number most security teams can produce in about four seconds and would rather not say aloud: how many alerts fired last month, and how many a human actually looked at. The ratio is frequently ugly. It is not a sign of a lazy team. It is the predictable output of a model where alert volume goes up forever and analyst hours do not.

The instinct when a breach gets missed is to add coverage — more rules, more sources, more tooling. That instinct is usually wrong, and it is worth being precise about why.

The coverage illusion

More detections feel like more security because coverage is easy to count and quality is not. A dashboard showing 900 active rules looks better in a board pack than one showing 200. But detections are not free after you write them. Each one has an ongoing cost paid in analyst attention, and that budget is fixed.

When a rule fires 400 times a month and is right twice, it has not added 2 units of security. It has added 2 units of security and consumed 398 units of the scarcest resource you have — and, more damagingly, it has trained your analysts that alerts of that shape are noise. That training generalises. It is the mechanism behind nearly every "the alert fired and was closed as a false positive" post-incident finding, including the one we described in our comparison of red teaming, pen testing and scanning.

A noisy detection does not just fail to help. It actively degrades the detections around it, because it spends the attention they will need.

The unit of work is the detection, not the alert

Most SOCs are organised around processing alerts: they arrive, someone triages them, the queue goes down, repeat. That is operationally necessary and strategically insufficient, because it treats the alert stream as weather — something that happens to you.

The shift that changes outcomes is to treat each detection as an owned, versioned, measured asset with a lifecycle, the way you would treat a piece of production code. An alert is an event. A detection is a product that emits events, and it can be good or bad at its job.

A detection lifecycle that works

The specifics vary, but functioning programmes tend to share these stages:

  • Proposed with a hypothesis. Every detection should answer "what adversary behaviour does this catch, and how would we know it worked?" A rule that cannot state its hypothesis is a rule nobody can evaluate later.
  • Tuned before it is trusted. Run it in a non-paging mode against real traffic first. Baseline the volume. If it fires 300 times a week in your environment, that is a finding about the rule, not about your adversaries.
  • Given an owner. Unowned detections never get retired, because retiring one feels like reducing coverage and nobody wants to sign that.
  • Measured continuously. Precision (of the alerts this fired, how many were real?) and contribution (has this ever been the detection that caught something first?) both matter.
  • Retired deliberately. This is the stage almost everyone skips. A rule that has fired 2,000 times and never once been the first signal of a real incident is costing you more than it returns. Deleting it is a security improvement, and it should be recorded as one.

The cultural hurdle is real: deleting detections feels like going backwards. It helps to make the trade explicit — "this rule consumed 90 analyst-hours last year and contributed nothing; those hours are now available for the detections that do work."

The metrics that hide the problem

Two numbers dominate SOC reporting and both mislead when used alone.

Mean time to detect. Averages conceal exactly the cases you care about. A SOC that detects 500 commodity events in seconds and one targeted intrusion after six weeks has an excellent MTTD and a serious problem. Distribution beats mean every time — look at the worst decile, not the average.

Mean time to respond. This quietly rewards closing tickets fast, which is not the same as resolving incidents well. If closure speed is the metric, closure speed is what you will get, including by closing things that deserved another twenty minutes.

More honest instruments:

  • Alert precision per detection — the true-positive rate of each rule individually, not the aggregate. The aggregate is always dragged around by your three noisiest rules.
  • Detection contribution — for each real incident, which detection fired first? Rules that never appear on this list are candidates for retirement regardless of how sensible they look.
  • Behavioural coverage — which adversary techniques you can actually see, mapped honestly. Frameworks like MITRE ATT&CK are useful here provided coverage is claimed based on tested detections rather than on having the log source plugged in.
  • Time-to-tune — how long a newly noisy rule stays noisy before someone fixes it. This is the best single proxy for whether your lifecycle exists in practice or only on a slide.

Where automation helps, and where it just relocates the noise

Automation earns its place on the deterministic parts of triage: enriching an alert with asset owner, user context, and prior history before a human opens it; grouping related alerts into one incident; auto-closing a class of alert where the disposition is genuinely mechanical and the rule for closing it is written down.

It does not fix a bad detection. Automating the triage of a rule with 3% precision produces a faster path to the same 97% of wasted work, plus a new component to maintain. The sequence matters: fix the detection, then automate what remains. Doing it the other way round is how teams end up with an expensive pipeline whose main output is well-enriched noise.

What good actually looks like

A healthy SOC is often quieter than an unhealthy one, which makes it a difficult thing to sell. The observable signs:

  • Analysts can name the detections they trust, and the ones they do not are being actively fixed or removed rather than tolerated.
  • Coverage claims are backed by tests — someone has run the technique and confirmed the alert fires.
  • Every real incident produces a detection change, not only a remediation ticket.
  • Retirement happens on a schedule and is reported as progress.

None of this requires new tooling, which is the good news and the reason it often does not happen — there is no purchase order for it. It is process work, and it is what our SOC operations engagements are built around: baselining what your current detections actually deliver, then rebuilding the lifecycle so quality has somewhere to come from. It pairs directly with threat intelligence, which is what tells you which behaviours are worth detecting in the first place.

If you want an outside read on where your signal is going, talk to an engineer — or start with the five blind spots every vulnerability scanner shares, which covers the equivalent problem on the assessment side.

Defensive guidance for systems you own or operate under authorisation.