False positive

A detection rule looks for a pattern. When the pattern matches activity that turns out to be harmless, the result is a false positive. The opposite mistake, real malicious activity that triggers no alert at all, is a false negative, and it is usually far more dangerous because nobody looks at it.

Many teams also distinguish a benign positive (sometimes called a benign true positive): the rule worked as intended and the activity really happened, but it was authorized. A penetration test that triggers your alerts, or an administrator running a scanning tool on purpose, are typical examples. Microsoft Sentinel and Defender XDR let you record this kind of classification when you close an incident.

Example

A rule alerts whenever PowerShell downloads a file from the internet. It fires every morning because a backup agent uses PowerShell to fetch its updates from the vendor's site. Each of those alerts is a false positive from the analyst's point of view, and the fix is to tune the rule, for example by excluding that signed script and that vendor domain.

Why it matters for a SOC analyst

False positives are the main cause of alert fatigue: when most alerts are noise, real ones get closed too quickly. Classify every alert honestly when you close it, and note why it was benign. That feedback is what detection engineers need to tune rules, and it is the difference between a SOC that drowns in alerts and one that improves every week.