Precision is a ratio of correct predictions to all predictions, so it does not map directly to the absolute number of false positives at scale. A change from 60 percent to 80 percent precision sounds modest, but it can cut false positives in half on the same volume of predictions. False discovery rate is often the clearer operational measure.
Why precision moves differently from false positives
Precision is a rate, not a count, so it changes the composition of predictions rather than the raw number of false positive on its own. If the prediction volume stays high, a small gain in precision can still leave a large absolute false-positive burden. The opposite is also true: a modest precision improvement can remove many false positives when the underlying volume is large.
That is why operational teams should read precision alongside alert volume, base rate, and the actual decision threshold. A model can look better on paper while still generating too many costly alerts for analysts, customers, or downstream automation.
When teams need a ratio that tracks practical noise more directly, false discovery rate is often the clearer companion measure because it expresses the share of positive predictions that turn out wrong.
Why the relationship is not linear in practice
The math is simple, but the operational effect is not. Precision moves with both true positives and false positives, so the same percentage change can mean very different things depending on how many positives you already produce. If a system makes 10,000 predictions, improving precision from 60 percent to 80 percent removes far more false positives than the same change on a system making 100 predictions.
Threshold tuning makes the effect even less linear. Raising the threshold can sharply reduce false positives for a while, then start removing true positives faster than false positives. In real security and detection workflows, score distributions are rarely stable, so the same tuning change can behave differently across teams, asset groups, or time periods.
A useful way to think about it is that precision is sensitive to prevalence and volume. If the underlying event rate shifts, or if the model is deployed against a broader population, the same score cutoff can produce a very different alert mix even when the headline precision number barely changes.
Risk and Threat Considerations
Noise is not just an analytics problem, it is an operational risk. When teams assume precision gains will reduce false positives in a neat one-for-one way, they can under-estimate analyst load, automation churn, and the chance that real alerts get buried in the queue.
Failure mechanism: A threshold or model update improves the rate metric without materially shrinking alert volume, or it shifts the balance between true and false positives in a way that is invisible if you only inspect precision.
Impact: Teams may over-trust the model, miss capacity planning problems, or accept an alerting policy that still overwhelms reviewers and weakens response quality.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.1 — Organizational Context | Precision must be judged against operational context and workload impact. |
| DE.AE — Anomalies and Events are Detected | False positives are a detection-quality issue that affects how events are triaged. | |
| Recommendation — Define the alerting context and use it to assess whether metric changes reduce real operational burden. Measure detection outputs against false-alert volume and triage load, not only score ratios. | ||
| CIS Controls v8 | 8.2 — Review Log Events | Alert noise changes the usefulness of review workflows and the signal-to-noise ratio. |
| Recommendation — Tune review workflows to reduce noisy events while preserving actionable detections. | ||
Practitioner Guidance
What to verify: Check precision together with absolute false-positive count, alert volume, and analyst capacity before approving a model change. If the use case feeds a queue, measure how many reviews are saved per day or per week, not just the percentage metric.
Common mistake: Treating an improved precision score as proof that the system is materially quieter. In practice, the right question is whether the change reduces meaningful work or just changes the ratio.
Decision rule: If the goal is operational burden reduction, prioritise the metric that reflects wrong positive decisions at scale, then confirm the threshold change still preserves acceptable recall for the cases you care about most.
Practitioner takeaway: Precision is a useful quality signal, but it is not a linear proxy for workload reduction, so always tie it back to volume, threshold behaviour, and the downstream cost of each false alert.
Related resources from NHI Mgmt Group
- How can organisations reduce false positives while improving fraud detection across the customer journey?
- What is the best way to reduce false positives and missed matches when writing Semgrep rules?
- How do organisations reduce false positives in secret detection pipelines?
- How can organisations reduce false positives without weakening identity controls?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
