1.9 Incident Classification Framework

The 4-tier classification model

The classification framework maps every incident to one of 4 severity levels based on 3 dimensions: scope (how many users, systems, or data assets are affected), impact (what business function is impaired or what data is at risk), and attacker state (is the attacker active, dormant, or contained).

Severity 1 — Critical. Scope: multiple systems or accounts compromised, OR infrastructure compromise (Entra Connect, domain controllers, federation servers). Impact: confirmed data breach with regulatory notification obligation, OR business-critical systems offline, OR active ransomware encryption. Attacker state: active and expanding. Response: IR team activated within 15 minutes. CISO notified within 30 minutes. External retainer engaged if needed. All containment pre-authorised per the authority matrix.

Severity 2 — High. Scope: single account compromised with evidence of post-compromise activity (persistence established, data accessed, or lateral movement attempted). Impact: sensitive data accessed but not confirmed exfiltrated, OR single business system at risk. Attacker state: active but contained to a limited scope. Response: SOC lead engaged within 15 minutes. Evidence collection initiated immediately. Containment actions (session revocation, endpoint isolation) executed per the authority matrix without waiting for IR team.

Severity 3 — Medium. Scope: single account with sign-in anomaly but no confirmed post-compromise activity. Impact: no confirmed data access, no business system impact. Attacker state: possible compromise, investigation needed. Response: SOC analyst investigates within 1 hour. Evidence collection for the affected account. No containment until investigation confirms compromise.

Severity 4 — Low. Scope: alert with no confirmed compromise indicator. Impact: none confirmed. Attacker state: no evidence of attacker presence. Response: SOC analyst triages within 4 hours. Close if false positive. Document if benign true positive.

The classification framework is documented in the SOC charter, posted at the SOC desk, and included in every analyst’s onboarding. The managed SOC partner (BlueVoyant for NE) uses the same framework — incidents escalated from BlueVoyant arrive pre-classified using NE’s criteria, not BlueVoyant’s internal criteria. This alignment was negotiated during the MSSP onboarding and is reviewed annually.

The framework also defines reclassification triggers. An incident starts at Severity 3 (possible compromise). The investigation confirms post-compromise activity (inbox rule created, emails accessed). The incident is reclassified to Severity 2. The investigation then discovers a second compromised account — reclassified to Severity 1 (multi-account compromise). Each reclassification triggers the escalation path for the new severity level. The analyst documents each reclassification with a timestamp and rationale in the incident timeline.

NE’s classification in action: the March 2026 AiTM escalation

When Wave 5 of INC-2026-0227-001 hit at 09:17 on March 12, the initial alert classified as Severity 3 — a single suspicious sign-in for s.chen@northgateeng.com. Rachel opened the incident, checked the MfaDetail field, and saw “satisfied by claim” from a residential proxy IP. She reclassified to Severity 2 immediately — the MFA-by-claim pattern is a confirmed AiTM indicator per the classification framework, not a “possible” compromise requiring investigation.

Within 8 minutes, 4 more AiTM alerts fired for different users from the same proxy subnet. Rachel reclassified to Severity 1 — multi-account compromise with a coordinated attack pattern. The Severity 1 classification triggered the full escalation chain: CISO notified at 09:30, IR lead paged at 09:31, #soc-critical Teams channel updated with all 5 affected accounts, and BlueVoyant notified to monitor for additional alerts.

Without the classification framework, Rachel would have investigated the first alert as an isolated suspicious sign-in, potentially spending 30 minutes before recognising the campaign pattern. The framework’s explicit criteria — “MFA satisfied by claim from non-corporate IP = Severity 2, reclassify to Severity 1 if multiple accounts” — compressed the classification decision from 30 minutes to 8 minutes. The remaining 22 minutes were spent on containment (session revocation for all 5 accounts) rather than on deciding whether the situation was serious.

The classification framework is reviewed after every Severity 1 incident. The INC-2026-0227-001 PIR added a new criterion: “3 or more AiTM alerts from the same IP subnet within 30 minutes = automatic Severity 1 classification, regardless of whether post-compromise activity is confirmed.” This criterion now feeds the Sentinel automation rule that auto-escalates campaign patterns without waiting for manual reclassification.

The framework’s value is not the document itself — it is the decision speed it enables. An analyst with a framework makes the classification decision in seconds. An analyst without one makes the decision in minutes (while reading the situation) or not at all (triaging each alert independently without recognising the campaign pattern).

Reclassification triggers: when severity changes mid-investigation

The classification framework defines 5 reclassification triggers that force an immediate severity change:

Trigger 1: Multi-account compromise confirmed. Any investigation that discovers a second compromised account reclassifies to Severity 1 regardless of the original severity. The rationale: multi-account compromise indicates a campaign, not an isolated incident — the attacker’s scope and capability are higher than a single-account compromise.

Trigger 2: Data exfiltration confirmed. Any investigation that confirms data was exfiltrated (not just accessed) reclassifies to Severity 1 if the data includes personal data (GDPR trigger), financial data, or classified engineering IP. The regulatory clock starts at confirmation of exfiltration, not at incident detection.

Trigger 3: Infrastructure compromise indicators. Any investigation that identifies Entra Connect abuse, federation changes, PTA agent anomalies, or domain controller compromise reclassifies to Severity 1. Infrastructure compromise is the highest-severity category in the MDDR taxonomy — it enables persistent, undetectable access.

Trigger 4: Attacker breaks containment. Any incident where the attacker establishes new access after containment was executed (new sign-in from a different account, new C2 channel, persistence mechanism firing) reclassifies to Severity 1 if not already at that level. Containment breakout indicates the attacker has capabilities or access paths that the initial containment did not address.

Trigger 5: Regulatory trigger identified. Any investigation that identifies personal data access (GDPR 72-hour clock), essential service impact (NIS2 24-hour early warning), or payment card data exposure (PCI DSS) reclassifies to at minimum Severity 2, regardless of technical severity. The regulatory reporting obligation creates an urgency independent of the technical impact.

Each reclassification is logged in the Sentinel incident timeline with a timestamp, the trigger that caused the reclassification, and the analyst who made the decision. The log ensures accountability and provides the audit trail for post-incident review.

The classification framework is tested during every tabletop exercise. The exercise facilitator presents a scenario and each analyst independently classifies the severity. If the classifications diverge (one analyst says Severity 2, another says Severity 3), the facilitator leads a discussion to identify which criterion was interpreted differently — and the framework is updated to resolve the ambiguity. After 4 exercises, NE’s analysts now achieve consistent classification on 95% of scenarios — up from 72% when the framework was first deployed. The remaining 5% of divergence occurs at the Severity 2/3 boundary for cases where post-compromise activity is ambiguous — the framework was updated to add the MFA-by-claim criterion specifically to resolve this boundary case.

The framework is a living document — updated after every Severity 1 incident based on the PIR findings. The February 2026 version had 3 pages. The April 2026 version (after the AiTM campaign and BEC incident) has 5 pages — the additional content includes the MFA-by-claim classification criterion, the multi-account campaign escalation trigger, and the BEC financial containment parallel track. Each update is versioned and the change history is maintained at the bottom of the document.

The framework integrates with the Sentinel automation programme: automation rules reference the classification criteria to adjust incident severity automatically. An AiTM alert with MFA-by-claim from a non-corporate IP is auto-classified to Severity 2 by the automation rule — the analyst validates the classification rather than making it from scratch. This automation-assisted classification reduces human error and ensures consistent severity assignment across all analysts and shifts, including overnight BlueVoyant triage.

The classification is not a bureaucratic exercise — it is the single decision that determines the speed and resources of the response. A Severity 3 that should have been Severity 1 delays containment by hours. A Severity 1 that should have been Severity 3 wastes senior analyst and IR team time on a routine alert. The framework makes this decision fast, consistent, and defensible.