True positives are correct security detections or classifications, where the system says an event, alert, or record is present and it really is. In detection and testing, they measure how well a rule, model, or analyst judgement identifies actual cases without missing them or confusing them with false positives.
What true positives mean in detection work
true positive are the cases your detection actually got right, which makes them the clearest signal that a rule, model, or analyst decision is finding real events rather than noise. In security operations, they are the foundation for measuring detection quality and operational usefulness.
A true positive can be an alert that correctly identifies malicious activity, a classification that correctly labels a suspicious record, or a triage decision that correctly confirms an issue. The label matters because it separates useful detection from false positives, which are correct rejections of benign activity, and false negatives, which are missed real events.
Why true positives matter to alert quality
True positives are not just a counting metric, they shape how teams judge whether a control is worth keeping, tuning, or retiring. A rule that produces many alerts but few true positives may still be noisy, while a rule with a strong true positive rate is more likely to support faster, more confident response.
They also affect how analysts interpret volume. If a queue contains a high share of true positives, triage work is more likely to lead to actionable investigation and containment. If true positives are rare, the same queue can become expensive to review and easier to dismiss too quickly.
For a practical view of how detection quality connects to operations, Security Operations Metrics Guide covers how teams track alert quality, detection coverage, and related SOC performance measures.
How true positives are measured and validated
True positives are usually understood through a validation set, a replay, or analyst-confirmed outcomes, where the question is simple: did the detection call the event correctly, and was the event truly present? That makes them a core input to precision, recall, and rule quality review.
In real operations, validation is rarely just a math exercise. A detection may be technically correct yet still unhelpful if it identifies events too late, too broadly, or without enough context to support triage. That is why teams often pair true positive analysis with enrichment, ownership, and disposition review.
Detection Rule Documentation Template is useful here because it forces teams to record blind spots, validation status, triage questions, and change history alongside the rule itself.
How true positives fit into detection engineering
In detection engineering, true positives are the evidence that a rule or model is aligned to a real threat or business condition, not just syntactic correctness. They help teams decide whether a detection needs more context, a narrower scope, or a different trigger pattern.
They are also important during testing and deployment. Backtesting, replay, and staged rollout can show whether a candidate rule produces genuine detections in historical data, while drift checks show whether the same rule continues to perform as environments, applications, and attacker behaviour change.
Detection as Code Guide shows why true positive replay belongs in version-controlled testing, while Alert Fatigue Reduction Guide explains how alert quality, suppression, and grouping depend on understanding which detections are truly useful.
True positives in SOC decision-making
Analysts often use true positives as a judgment call during triage: the event exists, the alert is materially correct, and the next step is investigation or closure with confidence. That is why the concept matters beyond statistics, it directly affects prioritisation, escalation, and whether a rule is trusted by the team.
True positives also help distinguish between a detection that is technically accurate and one that is operationally worth keeping. A strong detection portfolio usually balances true positive yield with coverage breadth, analyst workload, and the business cost of missing an event.
When teams want to connect that judgment to broader operations, Alert Triage Guide provides the practical workflow for disposition, enrichment, and closure, which is where true positives become visible in day-to-day SOC work.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.AE-03 — Analyses are performed to ensure that anomalies and events are understood | True positives measure whether detections correctly identify real events. |
| Recommendation — Validate that alerts are confirmed against ground truth before tuning detection logic. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | True positives depend on reviewing events and confirming which alerts are meaningful. |
| Recommendation — Review detected events and confirm which ones represent actual security conditions. | ||
| CIS Controls v8 | 8 — Audit Log Management | Accurate true positives rely on logs that can be reviewed and validated for real events. |
| Recommendation — Correlate alert outcomes with logs to verify which detections are truly correct. | ||
| MITRE ATT&CK | T1113 — Screen Capture | ATT&CK supports mapping detections to observed adversary techniques and validating real events. |
| Recommendation — Map validated detections to ATT&CK techniques and measure which ones produce real cases. | ||
| OWASP ASVS | V16 — Security Logging and Error Handling | True positives depend on logging and verification needed to distinguish real security events from noise. |
| Recommendation — Ensure logging is sufficient to confirm whether an alert reflects a real security event. | ||