Alert Fatigue Is Killing Your Security Team, Here's the Fix

A mid-sized enterprise running a modern vulnerability scanner will generate somewhere between 5,000 and 50,000 findings per month. A security team of four analysts has the capacity to meaningfully investigate perhaps 200–400 of them. The rest go into a backlog that grows faster than it shrinks.

This is alert fatigue, and it's not a people problem. It's a systems design problem. The scanner is doing its job: finding everything. The problem is that "finding everything" and "telling you what to fix" are completely different tasks, and most tools conflate them.

The goal isn't zero findings. The goal is knowing which 40 of your 40,000 findings are actually going to get you breached this quarter.

How Alert Fatigue Actually Kills Teams

The damage isn't just missed vulnerabilities. It's deeper than that:

• Triage paralysis: When everything is CRITICAL, nothing is critical. Analysts start treating CVSS 9.8 the same as 7.5 because both are impossible to address in time.
• Metric gaming: Teams optimize for the metric they can hit. "Percentage of criticals remediated in SLA" gets gamed by deprioritizing lower-scoring but higher-risk findings, or by re-rating vulnerabilities downward.
• Analyst burnout: Repetitive, high-volume triage work that feels futile is a direct driver of security team turnover. The best analysts leave fastest because they know the system is broken.
• Wrong things get patched: Under pressure, teams default to patching whatever is easiest, not whatever is most dangerous. A Linux kernel CVE that requires a reboot gets deprioritized; a low-severity web app flaw that just needs a config change gets patched "to show progress."

The Signal vs. Noise Problem in CVE Data

FIRST's research on EPSS consistently shows the same pattern: roughly 4% of published CVEs are ever exploited in the wild. The other 96% are theoretical vulnerabilities that threat actors never bother with, either because exploitation is too complex, the attack surface is too small, or more productive targets exist.

Your scanner doesn't know this. It reports all 40,000 CVEs with equal urgency. Correlated intelligence knows it, and uses it to reorder your queue radically.

The Triage Workflow That Actually Works

Effective vulnerability triage isn't a single decision; it's a progression through stages, each adding information and accountability. The six-stage workflow we've found most effective:

1. New: CVE is ingested and scored. No human has touched it yet. TRIS™ score auto-prioritizes within this column.
2. Triaged: An analyst has reviewed the CVE, confirmed it applies to in-scope assets, and validated the risk score. Due date set.
3. Assigned: An owner is identified. This is the accountability gate, until something is assigned to a human, it tends not to move.
4. Mitigating: Active remediation work is underway. Workaround in place, patch being tested, or compensating control deployed.
5. Resolved: Patch applied and verified. CVE is closed.
6. Dismissed: Intentionally closed without full remediation, with documented reason (not applicable, accepted risk, compensating control sufficient).

The key insight is that dismissed is a valid state with documentation requirements. Without an explicit dismiss state, vulnerabilities either stay open forever (backlog debt) or get quietly dropped (unknown risk). Forcing a dismiss reason creates accountability and an audit trail.

The Three Metrics That Replace "Number of Criticals"

If you're still reporting patch SLA compliance as your primary VM metric, you're measuring the wrong thing. Three better metrics:

1. EPSS-Weighted Backlog Age

Instead of counting all open vulnerabilities equally, weight them by EPSS score. A backlog of 1,000 CVEs with average EPSS 0.002 is less concerning than a backlog of 20 CVEs with average EPSS 0.4. Track this trend weekly; it's a far better leading indicator of breach risk than raw count.

2. KEV Time-to-Triage

When a new CVE enters the CISA KEV catalog, how many hours until your team has triaged it and assigned an owner? This metric forces rapid response to confirmed active exploitation. A target of under 24 hours is achievable and meaningful.

3. TRIS™ score Reduction Rate

Track the sum of TRIS™ scores across your open vulnerability queue, and measure how fast that aggregate score is decreasing. This tells you whether you're actually reducing organizational risk, or just patching easy, low-risk findings to hit count-based targets.

What to Do This Week

If you're drowning in alerts right now, three immediate actions:

1. Pull your current open findings. Filter to EPSS > 0.5 or KEV = YES. That's your real queue. Everything else is background noise for now.
2. Establish a triage SLA for KEV entries specifically. 24-hour assignment, 72-hour mitigation plan. Everything else can follow your standard cycle.
3. Run a dismiss pass. Go through your 90-day-old backlog and explicitly dismiss things that are not applicable. Document why. Shrinking a backlog through honest dismissal is better than a growing backlog that nobody trusts.

Alert fatigue is a signal that your prioritization system is broken, not that your team is failing. Fix the system.