> ## Documentation Index > Fetch the complete documentation index at: https://docs.contraforce.com/llms.txt > Use this file to discover all available pages before exploring further. # How to Classify Incidents: True vs False Positive > Choose a classification when you close an incident: True Positive, Benign Positive, False Positive, or Undetermined, with examples and a decision tree. Properly classifying incidents is essential for accurate reporting, tuning detection rules, and understanding your security posture. This guide explains when to use each classification type. ## Classification vs Status Before diving into classifications, it's important to understand the difference between **Status** and **Classification**: **Work state** of the investigation * **New** — Not yet reviewed * **Active** — Under investigation * **Closed** — Investigation complete **Outcome** of the investigation * True Positive * False Positive * Benign Positive * Undetermined **Status** tracks *where you are* in the investigation process. **Classification** documents *what you found* when the investigation is complete. *** ## Classification Types ### True Positive The incident represents an **actual security threat** that required response. **When to use:** * Confirmed malicious activity was detected * A real attack or compromise occurred * Threat actor activity was identified * Malware, phishing, or unauthorized access was verified **Examples:** * User credentials were actually compromised * Malware was confirmed running on an endpoint * Data exfiltration attempt was verified * Unauthorized access to sensitive resources occurred True Positives validate that your detection rules are working correctly. Document the threat details in comments for future reference. *** ### Benign Positive The detection was **technically correct**, but the activity was **legitimate** and authorized. **When to use:** * Suspicious-looking activity was actually authorized * A user performed unusual but legitimate actions * IT/Admin activities triggered security alerts * Penetration testing or security assessments caused alerts **Examples:** * Admin legitimately accessed multiple systems during maintenance * User traveled and logged in from an unusual location * Authorized penetration test triggered alerts * New software deployment caused unusual process behavior Benign Positives help identify opportunities for tuning. Consider creating exceptions or adjusting detection thresholds for known legitimate activities. *** ### False Positive The incident was **incorrectly triggered** due to flawed detection logic or bad data. **When to use:** * Detection rule logic is flawed or too broad * Inaccurate or corrupted data triggered the alert * Misconfiguration caused incorrect detection * The alert has no basis in actual activity **Sub-classifications:** | Reason | Description | | - | - | | **Inaccurate data** | The data used to generate the alert was incorrect, incomplete, or corrupted | | **Incorrect alert logic** | The detection rule itself is flawed and needs to be modified or disabled | **Examples:** * Alert triggered on a non-existent user due to log parsing error * Detection rule matches normal business activity too broadly * Time zone misconfiguration caused false temporal correlation * Deprecated system generated alerts for decommissioned resources False Positives indicate detection problems that should be addressed. Report patterns of False Positives to improve detection quality. *** ### Undetermined The investigation was **inconclusive**—the cause or outcome couldn't be determined. **When to use:** * Insufficient evidence to reach a conclusion * Logs or data needed for investigation are unavailable * The incident doesn't fit other classification categories * Investigation was abandoned due to resource constraints **Examples:** * Relevant logs expired before investigation completed * Activity was suspicious but couldn't be verified either way * Source system was decommissioned, preventing further analysis * Alert context was insufficient for determination When using Undetermined, always add detailed comments documenting what was discovered during the investigation. This helps if the incident needs to be revisited later. *** ## Quick Reference | Classification | Meaning | Action | | - | - | - | | **True Positive** | Real threat confirmed | Document threat details, validate response actions | | **Benign Positive** | Correct detection, authorized activity | Consider tuning or adding exceptions | | **False Positive** | Incorrect detection | Report for rule improvement | | **Undetermined** | Inconclusive investigation | Document findings in comments | *** ## Classification Decision Tree Use this flow to determine the correct classification: ```mermaid theme={null} flowchart TD A[Incident Investigation Complete] --> B{Was there actual\nmalicious activity?} B -->|Yes| C[True Positive] B -->|No| D{Was the detection\ntechnically correct?} D -->|Yes| E{Was the activity\nauthorized?} D -->|No| F[False Positive] E -->|Yes| G[Benign Positive] E -->|No/Unknown| H{Can you determine\nthe cause?} H -->|No| I[Undetermined] H -->|Yes| B ``` *** ## Best Practices Document your investigation findings regardless of classification. This creates an audit trail and helps with future investigations of similar incidents. Work with your team to establish classification guidelines. Consistent classification improves metrics accuracy and detection tuning. Regularly review classification trends. High False Positive rates indicate detection rules that need tuning. High Benign Positive rates suggest exception lists need updating. Use Undetermined only when you genuinely cannot determine the outcome. Overuse of Undetermined reduces the value of your classification data. *** ## Related Guides Complete workflow for managing incidents. Complete workbench to manage your incident resolution. *** Questions about classifications? Contact us at [support@contraforce.com](mailto:support@contraforce.com). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.