A true positive goal is the target percentage of alerts that should represent real suspicious activity. Teams use it to measure detection quality, compare rules, and decide which alerts need tuning or removal. It provides a practical benchmark for balancing coverage, confidence, and analyst workload.
Expanded Definition
A true positive goal is a detection-quality target, not a raw alert count. It expresses the share of alerts that should represent real suspicious activity, giving teams a practical way to judge whether a rule is too noisy, too narrow, or reasonably tuned for its purpose.
In practice, the metric sits between ideal detection and analyst reality. A very high goal can reduce noise but may miss lower-confidence signals; a very low goal can flood queues with benign events and make every alert harder to trust. The useful boundary is that the goal should reflect the function of the rule, not a universal benchmark for all detections.
Usage varies across teams. Some use true positive goal as a tuning threshold, while others treat it as a review standard for deciding whether a detection deserves to stay in production. That makes it different from precision in a strictly statistical sense, because operational context and alert severity matter as much as the simple ratio.
Examples and Use Cases
- A rule that flags impossible travel may have a lower true positive goal than a rule for privileged actions, because the first is broader and the second should be more exact.
- A SIEM team can compare two versions of the same detection and retire the one that generates more benign alerts relative to confirmed incidents.
- A SOC analyst may use the goal to decide whether a high-volume alert source needs suppression, enrichment, or complete redesign.
- A detection engineer can use the metric during rule review to separate useful coverage from alerts that only look suspicious in theory.
One practical tradeoff is that a detection with modest true positive performance may still be worth keeping if it covers a critical attack path. The metric helps inform the decision, but it should not override business impact, severity, or coverage gaps.
Security Implications
When the true positive goal is set poorly, teams either drown in false alarms or become overly selective and miss meaningful activity. Both outcomes weaken the security function: one by exhausting analysts, the other by lowering confidence in detection coverage.
The most common failure mode is using the metric as a blunt rejection tool instead of a tuning aid. That can lead to removing detections that are strategically valuable but operationally messy, or keeping noisy rules because they appear to “catch something” without proving they are worth the workload.
Failure mechanism: weak calibration, incomplete enrichment, and inconsistent alert review cause the measured ratio to drift away from actual detection value, so the team optimises for queue hygiene rather than threat coverage.
Impact: alert fatigue rises, escalation quality drops, and security teams lose the ability to compare detections consistently across different log sources, environments, and analyst teams.
Security, Operational and Governance Implications
True positive goals matter because they turn detection quality into something governable. They help create a shared language between engineering, operations, and leadership about what “good enough” means for a detection rule in a real environment.
They also support lifecycle decisions. A rule that consistently fails its goal may need better context enrichment, tighter scoping, or retirement, while a rule that meets the goal but covers a high-value activity may deserve continued investment. The point is not perfection, but accountable tradeoff management.
For teams running a modern security stack, the metric is most useful when paired with analyst feedback, incident outcomes, and coverage goals rather than treated as a standalone score. A detection program becomes healthier when it can explain why a rule exists, what workload it creates, and what risk it is meant to absorb.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while 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 | DE.CM — Security Continuous Monitoring | True positive goal measures how effectively detections surface real suspicious activity. |
| Recommendation — Use DE.CM to review noisy detections and tune rules that create low-value alerts. | ||
| CIS Controls v8 | 8 — Audit Log Management | Alert quality depends on usable logging, correlation, and review of security events. |
| Recommendation — Apply Control 8 to improve event quality so alert outcomes can be validated and tuned. | ||
| MITRE ATT&CK | T1110 — Brute Force | Detection goals are often judged against specific attack techniques and observed activity. |
| Recommendation — Map detections to ATT&CK techniques to judge whether alerts reflect real technique execution. | ||
