Incident Classification Framework

Severity is business impact, not technical complexity

Most SOC teams inherit severity from the detection rule. Sentinel assigns severity when the analytics rule is created — Informational, Low, Medium, High. The analyst sees the severity the rule assigned and treats it as the incident severity. This creates a mismatch: rule severity is based on the technique's general risk level, while incident severity should be based on the specific business impact in this organization at this time.

A "suspicious sign-in" rule fires at Medium severity. If the entity is a standard user with no privileged access, Medium is appropriate. If the entity is the CFO, the head of M&A, or a global admin, the same alert warrants High or Critical because the business impact of that account being compromised is orders of magnitude greater. The rule can't know who the entity is when it's authored — it fires at a fixed severity for every entity. The classification framework adjusts the severity based on the impact assessment that happens during triage.

Estimated time: 40 minutes.

The three classification criteria

Incident severity is determined by three factors that the analyst evaluates during triage or investigation. Each factor independently raises or lowers the severity.

Toggle the classification criteria below to see how each factor changes the severity determination. Start with all criteria at their lowest setting — a possible compromise of a standard user, historical activity. Then toggle each criterion upward and watch the severity, SLA, and notification requirements change:

This simulator demonstrates how classification criteria combine to determine incident severity at NE.

Criterion 1: Asset value

The entity involved in the incident determines the asset value factor. NE defines three asset tiers:

Crown jewels: the CEO, CFO, and CTO accounts; global administrator accounts; the finance@ne.com shared mailbox; the Azure subscription owner; the Sentinel workspace contributor role. Any confirmed compromise of a crown jewel entity is automatically Severity 1 regardless of the other two criteria.

VIP and privileged: department heads, Entra ID role holders (Security Administrator, Exchange Administrator, etc.), service accounts with administrative permissions, and accounts identified on the VIP watchlist. Probable compromise of a VIP entity is Severity 2.

Standard: all other user accounts and devices. These follow the confidence and activity criteria normally. A confirmed compromise of a standard user account is typically Severity 2 or 3 depending on the confidence level and whether the compromise is active.

Criterion 2: Confidence level

The confidence level reflects how certain the analyst or investigator is that a compromise has occurred. Three levels:

Confirmed: investigation has established that unauthorized access occurred. Evidence includes: sign-in from a known-malicious IP with subsequent unauthorized actions, inbox rule creation by an attacker-controlled session, data exfiltration demonstrated through MailItemsAccessed or file download logs. Confirmed compromises are factual — the investigation has sufficient evidence to demonstrate unauthorized access.

Probable: triage or investigation shows indicators strongly suggesting compromise, but the evidence doesn't definitively prove it. Evidence includes: sign-in from an unfamiliar IP with MFA-by-claim (possible AiTM but could be legitimate VPN), inbox rule creation at an unusual time (possible attacker but could be the user). Probable compromises warrant investigation and precautionary containment.

Possible: triage shows suspicious indicators that may or may not indicate compromise. Evidence includes: a UEBA risk score spike, an unusual but not definitively suspicious sign-in pattern, or a single anomalous event without corroborating evidence. Possible compromises warrant investigation but not immediate containment.

Criterion 3: Active vs historical

An active compromise means the attacker currently has access or is executing attack actions — observed by ongoing authentication, ongoing data access, or ongoing lateral movement. A historical compromise means evidence indicates access occurred in the past but the attacker may no longer have active access — a compromised session that has since expired, a credential that was changed, or a technique that was blocked by a subsequent policy change.

Active compromises escalate by one severity level because the attacker is currently operating and the response window is measured in minutes, not hours. A probable compromise of a standard account (normally Severity 3) becomes Severity 2 if the compromise is active. A confirmed compromise of a VIP account (Severity 2) becomes Severity 1 if active.

The classification matrix

The three criteria combine into a classification matrix that the analyst references during triage. The matrix produces a deterministic severity for any combination of asset value, confidence, and activity status.

For NE, the key decision points are: any crown jewel entity with confirmed or probable compromise → Severity 1. Any VIP entity with confirmed active compromise → Severity 1. Any VIP with confirmed historical or probable active → Severity 2. Any standard entity with confirmed active → Severity 2. All other combinations → Severity 3 or 4 based on the specific indicators.

The matrix is a reference card — one page, laminated on the analyst's desk. The analyst doesn't need to memorize it. They check the entity against the asset tier list, assess the confidence from the triage enrichment results, determine whether the compromise appears active, and read the severity from the matrix. This takes 30 seconds after the triage enrichment is complete.

Worked examples at NE

Example 1: A suspicious sign-in alert fires for rachel.okafor@ne.com (CISO — crown jewel). MFA succeeded. IP is from a city Rachel doesn't normally sign in from. Assessment: crown jewel entity + possible confidence + active. The matrix says: Severity 1 (any crown jewel with possible or higher confidence). The 15-minute SLA begins immediately. Even though this might turn out to be Rachel traveling, the business impact of the CISO's account being compromised justifies the Severity 1 response. If investigation determines it's legitimate, the severity downgrades and the incident closes as BTP. The 15-minute initial response was the right investment given the entity's value.

Example 2: Defender for Endpoint detects encoded PowerShell execution on a workstation. The device belongs to a standard user in the Engineering department. The parent process is a known legitimate tool (AutoHotkey). Assessment: standard entity + possible confidence + active. The matrix says: Severity 3. The 1-hour SLA applies. Investigation may reveal it's a legitimate automation script (downgrade to Severity 4, close as BTP) or a malware dropper (upgrade to Severity 2, containment action).

Example 3: A threat intel indicator match fires on a domain that appeared in a vendor advisory about Cobalt Strike infrastructure. The match is in DNSEvents from 3 days ago — a single query, no subsequent connections. Assessment: unknown entity + possible confidence + historical (3 days ago). The matrix says: Severity 4. The 4-hour SLA applies. The DNS query alone doesn't confirm compromise — the domain might be sinkholed, the query might be from legitimate web browsing that happened to touch the domain. Investigation checks for any subsequent connections or related indicators.

Each example shows the classification process: identify the entity tier, assess confidence from the available evidence, determine active vs historical, and read the severity from the matrix. The process is the same regardless of the alert type or the analyst's experience level.

Upgrading and downgrading severity

Severity is not fixed at initial classification. As investigation reveals more information, severity adjusts. A Severity 3 incident that L2 investigation confirms as an active compromise with data exfiltration upgrades to Severity 1. A Severity 2 incident where investigation determines the suspicious activity was a legitimate admin action downgrades to Severity 4 (informational) before closure.

Every severity change is documented in the incident comments with the rationale — "Upgrading from Severity 3 to Severity 1: investigation confirmed active mailbox access from attacker-controlled session. CFO account (crown jewel). Active exfiltration of financial data in progress." The documentation supports the metrics framework (Section 1.6) and the post-incident review.

Classification accuracy and training

Classification accuracy for severity is harder to measure than disposition accuracy (Section 1.5) because severity involves judgment about business impact. Two analysts might reasonably disagree on whether a probable compromise of a VIP account warrants Severity 1 or Severity 2. The classification matrix reduces this variance by making the criteria explicit, but edge cases will always exist.

NE addresses classification consistency through two mechanisms. First, the monthly severity review: the SOC lead reviews all Severity 1 and Severity 2 incidents from the past month and assesses whether the initial classification was appropriate. Over-classification (assigning Severity 1 to incidents that were actually Severity 2 or 3) wastes high-priority response resources. Under-classification (assigning Severity 3 to incidents that warranted Severity 1) delays response to critical incidents.

Second, the classification exercise: quarterly, the SOC lead presents 10 anonymized alert scenarios and asks each analyst to classify them using the matrix. The exercise reveals disagreements — where two analysts assign different severities to the same scenario. Each disagreement is discussed, and if the matrix doesn't resolve it clearly, the criteria are refined. This is the same inter-analyst agreement test used for the triage framework in Section 1.5, applied to severity classification.

The goal is not perfect agreement — reasonable analysts will sometimes disagree on edge cases. The goal is systematic agreement above 80% on the severity classification, with disagreements concentrated on edge cases rather than on straightforward scenarios. Below 80% agreement means the matrix criteria need clarification. At NE, the first classification exercise produced 75% agreement. After refining the VIP entity criteria and adding a worked example for the "active vs historical" distinction, the second exercise produced 90% agreement.

SLA mapping

Each severity level maps to specific response time targets. These SLAs are defined in the charter (Section 1.7) and enforced through the metrics framework (Section 1.6).

Severity 1 (Critical): initial response within 15 minutes. Containment action within 1 hour. CISO notification within 30 minutes. War room assembled within 1 hour. Post-incident review within 72 hours of resolution. The 15-minute initial response means a human analyst has acknowledged the incident, read the details, and begun investigation or containment — not that the incident is resolved.

Severity 2 (High): initial response within 30 minutes. Investigation scope determination within 2 hours. SOC lead notification immediately. Containment recommendation within the investigation window. Post-incident review within 1 week of resolution.

Severity 3 (Medium): initial response within 1 hour. Investigation within 4 hours. SOC lead notification in daily summary. Containment as recommended by investigation.

Severity 4 (Low): initial response within 4 hours. Investigation by next available analyst. No separate notification — included in weekly metrics summary.

NE's classification in practice

At NE, INC-NE-2026-0227-001 was initially classified as Medium severity by the analytics rule. The entity was a standard user — not a VIP or crown jewel. The alert type (suspicious sign-in) was Medium by default. Under the pre-incident severity system, Medium was appropriate. The alert stayed at Medium. It was triaged at L1 per the Medium SLA. The 21-day dwell began.

Under the post-incident classification framework, the same alert would be evaluated differently. The entity: standard user. The confidence: possible (unusual sign-in, MFA present but method suspicious). The activity: active (sign-in just occurred). Classification: Severity 3, which triggers the 1-hour initial response SLA and 4-hour investigation window. If triage enrichment revealed the MFA-by-claim indicator, confidence would upgrade to probable, activity is active, and the severity would adjust to Severity 2 — triggering SOC lead notification and a 2-hour investigation window.

The classification framework wouldn't have prevented the initial alert from being Medium. It would have ensured the triage enrichment checked the MFA method (Section 1.5's enrichment steps) and that the confidence assessment triggered the severity adjustment that brought the incident to L2 attention within hours rather than days.

The operational difference

The numbers tell the story of the classification framework's impact. Before the framework, NE's severity distribution was: 2% Severity 1, 8% Severity 2, 35% Severity 3, 55% Severity 4. Severity was driven entirely by rule assignment. After the framework, the distribution shifted to: 4% Severity 1, 15% Severity 2, 45% Severity 3, 36% Severity 4. The increase in Severity 1 and 2 incidents didn't mean more attacks — it meant the framework correctly elevated incidents involving VIP entities and active compromises that the rule-based system would have left at Medium.

The SLA compliance data tells the second part of the story. Before: 96% SLA compliance on all severities combined — a healthy-looking number driven by the 55% of incidents at Severity 4 (4-hour SLA, easy to meet). After: 89% SLA compliance — lower on paper, but measured against appropriate severity assignments. The Severity 1 and 2 incidents that the framework correctly elevated were now getting the response urgency they deserved, even though the tighter SLAs were harder to meet consistently.

The framework is now part of NE's SOC charter and the L1 classification card is referenced during every triage. The combination of the triage decision framework (what to check), the escalation framework (when to escalate), and the classification framework (how urgent the response is) produces a complete operational path from alert to response — regardless of which analyst is on shift.