Skip to content
Back to the learning center

4 min read 8 November 2026

The hidden cost of false positives

Alerts that turn out to be nothing still cost time and attention, and they make real attacks easier to miss. Here is where the cost hides and how to measure it in your own team.

Traditional SOCOne analyst, in arrival orderLooked atPort scan from a printerHarmlessLocal accounts listedSuspiciousBackup copied filesNewArchive made by handNewAdmin logon at 02:10NewScript fetched a fileNewFiles staged in /tmpNewUpdate agent beaconNewNew cron entryNewDNS to new domainNewOutbound to rare hostNewFailed logons, then oneNew+ 6 more waiting10 waitingWith armor360Each one looked into as it landsSorted for your teamProcessNetworkUserIntelPort scan from a printerHarmlessLocal accounts listedSuspiciousBackup copied filesAuthorisedArchive made by handReal attackAdmin logon at 02:10AuthorisedScript fetched a fileSuspiciousFiles staged in /tmpReal attackUpdate agent beaconHarmlessNew cron entrySuspiciousDNS to new domainHarmlessOutbound to rare hostReal attackFailed logons, then oneHarmless+ 7 more, all looked into0 waiting
Illustrated example: the same twelve overnight alerts, read by one analyst, and looked into by armor360. People still decide what to do.

What counts as a false positive

A false positive is an alert that fires when nothing bad has happened. The rule matched, but the activity was harmless: a developer’s script that looks like scanning, a password manager that looks like credential theft, a backup that looks like data being copied out.

It helps to separate two kinds. In the first, the rule is simply wrong for your environment and the alert should never have fired. In the second, the rule did exactly what it should, but the activity was authorised: an administrator really did run a remote command, and was allowed to. Both end with nothing to do, but they need different fixes. The first calls for tuning the rule. The second calls for recording what is expected, so the next look is quicker.

Either way, someone had to look to find out. That look is where the cost begins.

The time it takes to prove nothing happened

Proving that something is harmless often takes as long as proving that it is real. The analyst still has to find the machine, check the user, look at what happened before and after, and look up anything unfamiliar. A false positive is only a quick close when the answer is already known.

The cost adds up quietly because each alert looks small. A few minutes here and there does not feel like a problem on any single alert. Across a day, a week and a team, it can add up to a large share of the hours you pay for, and it is rarely tracked as such.

There is also the time no one counts: the switch between tasks. An analyst pulled off a hunt or a detection project to check an alert loses more than the minutes the alert takes. Getting back into the earlier work takes time too.

What it does to attention

Repetition changes how people look. When the same kind of alert has been harmless every time someone checked, the next one gets a lighter look. This is not carelessness; it is how people learn. The trouble is that attackers know it too, and choose techniques that look like everyday administration.

Over months, a steady flow of false positives also affects morale. Skilled people join a SOC to find attackers, and a job that is mostly confirming nothing is hard to stay in. That cost shows up in hiring and training, not in the alert queue.

Attention also runs down within a single day. An analyst who has cleared a long run of harmless alerts brings less care to the next one, whatever it turns out to be. The alert that matters does not announce itself, and it often arrives in the middle of that run.

How real attacks get missed in the noise

The most serious cost is the alert that was real but was treated as noise. It can happen in several ways. A real alert from a rule known to be noisy is closed on sight. A real alert waits behind dozens of harmless ones and is looked at hours later, after the attacker has moved on. Or a quiet alert that would have connected the dots is never looked at because the queue was full.

None of these failures shows up in a count of alerts closed. The queue looks healthy because it was cleared. The only way to find them is to look back after an incident and ask which alerts fired and what happened to each one.

This is why reducing false positives is a security improvement, not only an efficiency one. Every harmless alert taken out of the queue is attention given back to the alerts that matter.

Tuning a rule or investigating the alert

When a rule produces a lot of false positives, the instinct is to tune it: add exceptions for known-good accounts, raise thresholds, or narrow what it looks at. Tuning is often right, but it has a cost. Each exception is a place an attacker could hide, and a rule tuned too far no longer catches what it was written for.

Investigating each alert in full has the opposite trade-off. Nothing is excluded, but the team pays the time cost each time. The practical answer is a mix. Tune the rule where the harmless cause is well understood and unlikely to change. Keep investigating where the same pattern could be either harmless or an attack, and make each investigation as cheap as possible with good context and an automated first look.

Before you change a rule, test the change against stored past alerts. Seeing how often the new version would have fired, and whether it would still have caught the attacks it was written for, takes the guesswork out of tuning.

Two draft rules, tested on the last 30 daysIllustrated example
Any archive created in /tmpToo noisy

Would have fired 473 times

Archive created, then copied to a staging folderReady to approve

Would have fired 3 times

Before a rule goes live, armor360 shows how often it would have fired on alerts you already store. The noisy one goes back for narrowing; the quiet one goes to a person to approve.

Measuring it in your own team

You do not need an industry benchmark to know your own cost. Your alert history and your team’s time are enough.

Multiply the harmless closes by the average time each took to get the hours spent proving nothing happened. Put that next to the hours spent on real alerts and on hunting or improving detection. The balance tells you more than any single number, and repeating the count each quarter shows whether your changes are working.

Share the result with the people who hold the budget. False positives are invisible from outside the SOC, and a count of hours makes the problem concrete.

Start with a month of alerts and gather these figures:

  • How many alerts reached a person, and how many were closed as harmless or authorised.
  • The average time to close a harmless alert, compared with a real one.
  • The rules that produce the most harmless closes.
  • How long real alerts waited for a first look.
  • Any real alerts that were first closed as harmless.

Questions people ask

Is a false positive the same as a harmless alert?

Not quite. A false positive is a rule firing on something it was not meant to catch. A harmless alert can also be a true positive that turned out to be fine: the rule caught exactly what it was looking for, but the activity was authorised, such as an administrator doing their job.

The difference matters for the fix. False positives point at the rule. Authorised activity points at what you know about your own environment, which is worth recording so the next look is quicker.

Should we aim for zero false positives?

No. A rule set with no false positives is almost certainly missing real attacks, because the only way to get there is to make every rule so narrow that it fires only on what you have already seen.

A better aim is false positives that are cheap to clear. That means good context on each alert, verdicts with reasons that can be reused, and a first look that does not depend on a person repeating the same lookups every time.

How do we know if tuning has gone too far?

Test it. Replay the tuned rule against stored past alerts and events, including any known attacks or adversary-simulation runs, and check it still fires on them. If it does not, the tuning has removed the reason the rule exists.

Also review exceptions on a schedule. An exception added for an account or machine that has since changed role can become exactly the gap an attacker uses.

Can AI reduce the cost of false positives?

It can reduce the cost of each one. An AI first look does the repetitive checks on each alert and hands a person a verdict and its evidence, so confirming a harmless alert takes a quick review rather than a fresh investigation.

It does not remove the need for people to check its work. A sensible practice is to review every verdict the agent calls a real attack or suspicious, and a regular sample of those it calls harmless, correcting it where it is wrong.

More guides

See where your team’s time goes. Then decide.

Start a free pilot on your own alerts, or put in your own numbers first.

Start a free pilotRun your numbers