Triage and Incident Prioritisation

Every detection tool, whether a SIEM correlation rule, an endpoint detection and response (EDR) agent, or a network intrusion detection system, generates alerts. An alert is not an incident. It is a signal that something matching a detection rule has occurred. The first task of triage is classification: deciding whether the alert represents a true positive (a real security event) or a false positive (a benign event that matched a detection rule it should not have).

Classification relies on enriching the alert with context. Raw alert data typically contains a timestamp, a source and destination IP or host, a rule name, and a severity score assigned by the detection tool. None of this is sufficient on its own. The analyst enriches the alert by pulling supporting evidence: relevant log entries, endpoint telemetry, threat intelligence lookups for IP addresses and file hashes, user account history, and asset inventory records for the affected systems. This enrichment step is where the analyst distinguishes a scanning probe from an authenticated intrusion, or a misconfigured application from a data exfiltration attempt.

The classification output should be documented in the incident tracking system with the evidence examined and the reasoning used. This matters for two reasons. First, if the analyst's classification is wrong (a false negative, where a real incident is closed as benign), the documentation allows the error to be traced and the decision logic to be corrected. Second, closed false positives build a record that allows the detection engineering team to tune the rule that fired, reducing future noise.

Once an alert is classified as a true positive, it must be assigned a severity level that determines how quickly the team responds and which resources are mobilised. Severity assignment based on gut feel is inconsistent across analysts and shifts under pressure. A severity matrix makes the assignment explicit and repeatable.

A severity matrix has two axes. The first is technical impact: how much access or damage has the attacker achieved or could achieve from the confirmed foothold? Indicators include whether the compromise is limited to one endpoint or spans multiple systems, whether the attacker has privileged credentials, whether data has been exfiltrated or encrypted, and whether the attack is still in progress. The second axis is business impact: how important is the affected system to the organisation's operations, legal obligations, or reputation? This axis draws directly from the asset criticality register.

The matrix is populated with target response times defined in the incident response plan. Those targets vary by organisation: a financial services firm regulated under the Payment Card Industry Data Security Standard (PCI-DSS) or the EU's Digital Operational Resilience Act (DORA) may have contractual and legal obligations to begin containment within specific windows. In India, the Information Technology (Amendment) Act 2008 and CERT-In's 2022 Cyber Security Directions mandate that certain categories of incident be reported to CERT-In within six hours of detection. In the US, the SEC's 2023 cybersecurity disclosure rules require publicly listed companies to disclose material incidents within four business days of determination. These external timelines set a floor on how quickly triage and initial response must occur.

Asset criticality is the bridge between a technical alert and a business-risk judgment. Two identical alerts, say, a suspicious PowerShell execution, fire on two different hosts. One host is a domain controller serving the entire organisation's authentication infrastructure. The other is a developer's test workstation with no network access to production systems. The technical alert is the same; the business impact is radically different. Without asset criticality data in the triage workflow, both alerts receive the same score and the domain controller may not be prioritised appropriately.

Asset criticality is assigned in advance, as part of forensic readiness and IR preparation, not during an active incident. The assignment process typically maps assets to a tiered scale (for example, Tier 1: mission-critical, Tier 2: important, Tier 3: standard) based on the answers to questions such as: Would a one-hour outage of this system halt revenue-generating operations? Does this system hold regulated personal data (personal health information under HIPAA in the US, or sensitive personal data under India's Digital Personal Data Protection Act 2023, or special-category data under the EU General Data Protection Regulation)? Is this system required for compliance evidence (audit logs, access records)?

The criticality label is stored in the asset inventory and should be surfaced automatically in the triage interface when an alert fires on a known asset. When an alert fires on a host not in the inventory, a conservative approach treats it as Tier 2 until the asset is identified, rather than Tier 3, because unmanaged assets are often higher risk than known ones.

A false positive is an alert that fires on a benign event. Some false positives are inevitable: any detection rule broad enough to catch all variants of a threat will also catch benign events that share surface features. The problem is not individual false positives but a sustained high false positive rate, which creates alert fatigue and degrades the team's ability to detect real incidents.

The causes of high false positive rates fall into a small number of patterns. Overly broad detection rules written without environment context, for example, alerting on any PowerShell execution rather than on PowerShell executions in contexts where PowerShell is not legitimate, generate noise across all hosts. Failure to suppress known-good baselines, such as a scheduled task that runs a benign script every night, causes the same alert to fire repeatedly. Threat intelligence feeds containing stale indicators of compromise (IOCs) that now point to reclaimed or shared infrastructure generate alerts on legitimate traffic.

Managing false positives without sacrificing detection coverage requires documentation before suppression. Before a detection rule is tuned or a suppression is added, the analyst should document the false positive in the incident tracking system, including the rule that fired, the evidence that showed it was benign, and the context (for example, this alert fires every Monday at 02:00 because of the weekly backup job on this host). Suppressions are then targeted and time-bounded or host-specific rather than global. Global suppression of a rule that fires frequently as a false positive may also suppress the same rule when it fires on a real incident.

Not all alerts can be classified by the first analyst who sees them. A tiered escalation model ensures that unresolved alerts move to more experienced analysts rather than being closed without adequate investigation. Most SOC structures use three analyst tiers. Tier 1 handles initial alert review, enrichment, and classification of routine events. Tier 2 handles complex or ambiguous cases referred by Tier 1, and conducts deeper technical analysis including log correlation and threat hunting. Tier 3 handles advanced persistent threat scenarios, forensic investigation, and cases that require specialist knowledge.

Escalation criteria should be defined in the IR plan rather than left to analyst judgment. Typical criteria include: the alert cannot be classified as true or false positive within a defined time window (commonly 30 to 60 minutes for Tier 1); the alert involves a Tier 1 critical asset; the alert matches a known threat actor pattern listed in the threat intelligence feed; or the scope of affected systems appears to be expanding while investigation is in progress. When an alert meets escalation criteria, it moves to the next tier with the enrichment data already collected rather than requiring the receiving analyst to restart from scratch.

Time-to-escalate is a key triage metric. In the EU's NIS2 Directive (which applies to operators of essential services and digital service providers across EU member states), significant incidents must receive an early warning to the competent authority within 24 hours of detection. In the UK, the National Cyber Security Centre (NCSC) expects operators of essential services to report significant incidents promptly. These regulatory timelines mean that delays in the escalation path between Tier 1 detection and senior decision-making can create legal exposure as well as technical risk.

A triage playbook is a documented decision procedure for a specific alert type or threat scenario. It specifies exactly which evidence to collect, which questions to ask, which thresholds trigger escalation, and which reference materials (threat intelligence, asset inventory, past incident records) the analyst should consult. Playbooks reduce the cognitive load on analysts under pressure and make triage consistent across different shifts and experience levels.

Effective playbooks are built from prior incident data. After each incident, the post-incident review should ask whether the triage process worked correctly: was the initial severity assignment accurate? Were any escalation steps delayed? Did false positive suppression miss the relevant context? The answers update the playbook for that alert type. Over time, this cycle produces playbooks that reflect the organisation's actual environment and threat history rather than generic templates.

Triage quality can be measured. Key metrics include mean time to triage (the average time between alert generation and classification), false positive rate by rule and by alert source, escalation rate (the proportion of Tier 1 alerts that escalate to Tier 2 or 3), and severity accuracy (the proportion of severity assignments confirmed correct after the full incident investigation). These metrics, reviewed regularly, identify which detection rules, asset categories, or analyst procedures need improvement and prevent triage from becoming a static process that degrades as the threat environment changes.