Security Incident Triage and Classification
Incident triage is the process by which a SOC determines, quickly and systematically, whether an alert represents a real threat, how severe it is and what handling it should receive - all before the damage materializes. It is the line between an incident contained in minutes and a crisis that lasts for days.
Event, alert and incident: filtering out the noise
A mid-sized corporate environment generates tens of millions of log events per day. Most of these records are operational and irrelevant to security. The SOC analyst's first job is to distinguish three conceptual categories that NIST SP 800-61 Rev. 2 defines precisely:
- Event: any observable occurrence in a system or network - a successful login, a DNS query, a file transfer. Events are neutral by nature.
- Alert: an event or set of events that triggered a detection rule and was forwarded to the analyst for evaluation. Every incident begins with one or more alerts, but most alerts never become incidents.
- Incident: an alert confirmed as adversarial activity or a policy violation with real or imminent impact on the confidentiality, integrity or availability of the organization's assets.
The triage process follows exactly this path: it receives alerts, evaluates context, discards false positives and escalates to incident status only what shows sufficient evidence of a genuine threat. Without this disciplined filtering, the SOC drowns in volume and loses the signals that matter.
Classification by severity: the impact x urgency matrix
Classifying an incident means assigning it coordinates along two dimensions: impact (how serious the potential damage is) and urgency (how quickly that damage can materialize or spread). The resulting severity determines the response SLA and the resources allocated.
Impact is assessed by the assets involved (system criticality, data classification, number of affected users), by the applicable regulations (LGPD, PCI DSS, sector-specific rules) and by the financial or reputational exposure. Urgency is assessed by the potential for lateral propagation, the available containment window and the attacker's active activity.
| Severity | Impact | Urgency | Typical example | Time to notification | Time to containment |
|---|---|---|---|---|---|
| Critical (P1) | Critical | Immediate | Active ransomware on a production server; domain account compromise; confirmed exfiltration of regulated data | 15 minutes | 2 hours |
| High (P2) | High | High | Phishing with harvested credential and confirmed access; malware on an endpoint with no lateral movement; partial DoS on a critical system | 30 minutes | 4 hours |
| Medium (P3) | Medium | Medium | Blocked unauthorized access attempt; malware in quarantine; unauthorized internal vulnerability scan | 2 hours | 24 hours |
| Low (P4) | Low | Low | Acceptable-use policy violation without compromise; IP reputation alert with no established connection | 8 hours | 72 hours |
The SLAs above are for reference. Each organization must calibrate them based on its risk appetite, contractual obligations and SOC operational capacity. What is non-negotiable is that they exist, are formalized and are measured across every occurrence.
Categorization by incident type
Beyond severity, every incident receives a category that determines which playbook is activated. The SANS Institute and NIST converge on the following primary categories:
- Malware and ransomware: malicious code running on the organization's assets, whether for espionage, destruction or extortion. Highest priority for containment and network isolation.
- Phishing and BEC (Business Email Compromise): social engineering to harvest credentials or induce fraudulent financial transfers. Requires immediate session blocking and review of email rules.
- Unauthorized access: use of stolen legitimate credentials or exploitation of a vulnerability to access systems without permission. Investigation of lateral movement is mandatory.
- Denial of service (DoS/DDoS): a volumetric or protocol attack aimed at disrupting service availability. Immediate coordination with the connectivity provider and CDN.
- Data leakage: intentional exfiltration or accidental exposure of sensitive information. Triggers regulatory notification obligations within the deadlines set by the LGPD and sector regulations.
- Insider threat: abuse of privileged access by an employee, third party or former employee. Requires special evidence protocols to preserve legal traceability.
L1, L2 and L3 escalation criteria
The SOC's tiered structure exists to ensure that the level of expertise applied to an incident is proportional to its complexity, without overloading specialists with low-value triage or leaving complex incidents in the hands of analysts who lack the right tools.
L1 - Triage and first response: L1 analysts receive all alerts, perform the initial triage, discard false positives using documented procedures, classify confirmed incidents and execute containment playbooks for Low and Medium severities. They are responsible for recording all collected evidence in the ticket before any escalation.
L2 - In-depth investigation: they receive High-severity incidents or any incident that L1 could not contain with a standard playbook. They perform root cause analysis, correlate events to determine the extent of the compromise, and analyze SIEM logs, network traffic and endpoint artifacts. They decide on broader containment (network segment isolation, mass credential resets).
L3 - Forensics and advanced incident response: engaged for Critical incidents, advanced persistent threats (APT), compromise of regulated data or any situation with potential for significant legal or financial impact. They conduct digital forensic analysis, malware reverse engineering, threat hunting and support legal proceedings when necessary.
Escalation is a technical decision, not a hierarchical one. The criterion is the complexity and impact of the incident, not analyst availability. Escalating late compromises the SLA. Escalating early without criteria unnecessarily overloads L2 and L3.
Reducing false positives
A false positive is not just an operational inconvenience - it is a real cost. Every false positive consumes analyst time that could be spent investigating a true incident. Organizations with high false-positive rates develop alert fatigue, the state in which analysts stop investigating alerts carefully because the volume of noise has overwhelmed the signal. Industry research indicates that SOCs receive between 1,000 and 10,000 alerts per day, with false-positive rates above 50% in many organizations.
The main levers to reduce false positives are: fine-tuning detection rules with a whitelist of known legitimate behaviors, automatically enriching alerts with context (threat intelligence, asset inventory, user history) before they reach the analyst, correlating events in the SIEM to raise the trigger threshold of simple alerts, and continuous, metrics-based review - false-positive rate per rule, per analyst and per category.
The role of SOAR in automated triage
SOAR (Security Orchestration, Automation and Response) is the technology layer that automates the repeatable steps of triage. When a phishing alert reaches the SIEM, the SOAR playbook can, in seconds and without human intervention: extract URLs and hashes from the emails, look them up in threat intelligence sources, check whether other users received the same email, verify whether any user clicked the link, block the malicious domain at the email gateway and web proxy, and open an L2 ticket if there is evidence of a click - all documented with timestamps and evidence for auditing.
The analyst receives an already enriched ticket, with the automated actions logged, and focuses on the decision that requires human judgment: is there a credential compromise? Does the password need to be reset? Is the incident part of a larger campaign? SOAR reduces the MTTR (Mean Time to Respond) from hours to minutes for the most common incident types and frees up analytical capacity for the genuinely complex cases.
Normative references
The triage and classification process described in this article aligns with the following internationally recognized references:
- NIST SP 800-61 Rev. 2 - Computer Security Incident Handling Guide: defines the incident response lifecycle (preparation, detection and analysis, containment, eradication and recovery, post-incident activity) and establishes the fundamentals of classification and severity.
- SANS Institute Incident Handler's Handbook: a six-phase methodology (preparation, identification, containment, eradication, recovery, lessons learned) with practical triage and escalation guidance.
- ISO/IEC 27035: an international standard for information security incident management, with emphasis on organizational structure, roles and integration with the ISMS.
Frequently asked questions
What is the difference between a security event, alert and incident?
An event is any observable record in a system or network - a login, a packet, a query. An alert is an event that triggered a detection rule and requires human attention. An incident is an alert (or a set of correlated alerts) confirmed as malicious activity or a policy violation with real or imminent impact on confidentiality, integrity or availability. Triage exists precisely to travel this path in a systematic and fast way.
How do you define the severity of an incident?
Severity results from the combination of impact (how serious the potential damage to data, systems or operations is) with urgency (how quickly the damage can materialize or spread). A compromised account belonging to an ordinary user has moderate impact and medium urgency - High severity. The same account belonging to a domain administrator raises the impact to critical even if the attacker has not yet moved laterally - Critical severity.
What are the main types of incidents a SOC classifies?
The most common types are: malware and ransomware (malicious code that compromises or encrypts assets), phishing and BEC (social engineering to steal credentials or divert funds), unauthorized access (legitimate use of stolen credentials or exploitation of vulnerabilities), denial of service - DoS/DDoS (intentional disruption of availability), data leakage (exfiltration or accidental exposure of sensitive information) and insider threat (abuse of privileged access by an employee). Each type demands a specific playbook.
What is alert fatigue and how does it compromise triage?
Alert fatigue is the state in which analysts stop investigating alerts carefully because the volume of notifications is so high that the signal is lost in the noise. Industry studies indicate that mid-sized SOCs receive between 1,000 and 10,000 alerts per day, of which more than 50% are false positives. The practical result is that real incidents get buried in the queue. The solution involves tuning detection rules, using event correlation (SIEM), implementing automatic context enrichment via SOAR and establishing alert-quality metrics.
When should an incident be escalated from L1 to L2 or L3?
L1-to-L2 escalation occurs when the triage analyst confirms the incident cannot be contained with standard procedures, when the severity is High or Critical, when there are signs of lateral movement or persistence, or when the estimated resolution time exceeds the tier's SLA. L2-to-L3 escalation is triggered when there is compromise of critical systems or regulated data (PCI, LGPD), when in-depth forensic investigation is required, or when there is a risk of significant financial or legal impact.
How does SOAR help with incident triage?
SOAR automates the repeatable steps of triage: it enriches the alert with IP reputation, file hash, domain and identity data before an analyst even opens it; it executes first-response playbooks such as isolating an endpoint or blocking an IP; it correlates the alert with other events from the same campaign; and it records all actions in the ticket for auditing. The result is a reduction in MTTR from hours to minutes in the most common incident categories.
Decripte and 24x7 incident triage
Decripte operates a continuous SOC with triage, classification and incident response for companies of 1 to more than 100,000 employees in Brazil. Triage follows the methodology described in this article: classification by severity with contractual SLAs, documented L1-L3 escalation and per-category incident playbooks. The DMS platform records every triage decision with a complete audit trail, from the original alert to resolution, ensuring traceability for compliance with the LGPD and sector regulations.
Organizations that want to structure or strengthen their triage process can start for free with the Threat Plan or explore Decripte's incident response plans.