What is Escalation?

NIST's incident response guide separates two moves that most SOCs file under one word: "Escalation generally refers to increasing resources or time frames, while elevation usually indicates involving a higher level of management in the response efforts." Handing a case from L1 to L2 adds resources, so it is escalation in NIST's sense. Waking up the CISO or legal is elevation. For both, the guide recommends the same thing: track and validate the status of every open incident, so the ones that need more resources or a different strategy are spotted and changed quickly.

Outside security, "incident escalation" usually means routing an IT outage or a customer complaint up a support chain. In a SOC the difference is that someone may still be working against you while the ticket moves. Escalation is the main output of triage. FIRST's CSIRT Services Framework describes event analysis as qualifying each detected potential incident "for escalation to the Information Security Incident Management service area or as false alarms". The alert triage page covers how that verdict gets made. This page covers what happens once the answer is "this needs someone else".

What NIST says should drive the decision

NIST SP 800-61 Rev. 3 does not leave the call to instinct. Under the Incident Management category (RS.MA) it recommends that triage, prioritization, escalation and elevation "should all be based on a set of risk evaluation factors", and lists examples:

• asset criticality;
• functional impact of the incident;
• data impact of the incident;
• stage of observed activity;
• threat actor characterization;
• recoverability.

It also says incidents "should not be handled on a first-come, first-served basis". In a runbook, those factors turn into a short list of triggers, so two analysts looking at the same alert make the same call instead of each applying their own tolerance for risk.

SOC escalation criteria: when L1 hands a case to L2

The table below is a starting point for a runbook, built from those factors. It is not a standard, and every SOC adjusts it to its own estate and to what L1 is allowed to do. Each row names the check L1 runs first and the evidence that turns a suspicious alert into a handoff.

The LSASS row is strict because MITRE ATT&CK (T1003.001) notes that after a user logs on, Windows "generates and stores a variety of credential materials in LSASS process memory", and an attacker with administrator or SYSTEM rights can harvest them to move laterally. On a server, that can mean every administrator who has logged on there. The impossible-travel row is strict because an approved MFA prompt can mean the attacker holds a valid session, and a password reset on its own does not end it. The containment page covers revoking sessions and checking that the revoke held.

What an escalation ticket must contain

NIST recommends tracking each incident's status "along with pertinent information, such as an incident summary, indicators of compromise related to the incident, the status and expected time frame for each assigned action, and next steps to be taken." An L1 ticket that covers that, plus what the next analyst needs to avoid starting over, has seven parts:

1. Entity. Host (name and EDR device ID), account (UPN, not display name), IP and any hash, exactly as they appear in the logs.
2. Timeline in UTC. First and latest suspicious activity, and when the alert fired. Mixing time zones is how a 20-minute gap becomes a missing hour.
3. Evidence. The query you ran, links to the alert and raw events, and the two or three log lines that made you hand it on.
4. What you ruled out, and how. "Not VPN: egress IP is outside our ranges" saves L2 the same lookup.
5. What you already did. Any containment action, with its timestamp and whether you confirmed it applied.
6. The ask. One concrete request: approval to isolate, a memory capture, a decision on disabling a service account.
7. Severity and confidence, as two fields. Severity is the impact if this is real; confidence is how sure you are that it is malicious. High severity with low confidence is a legitimate reason to escalate, and the ticket should say so.

A simulated escalation ticket

Simulated example generated by SOCSimulator Research. The organization, people, addresses and times are invented.

INC-20417   Escalated L1 -> L2   2026-10-21 08:52 UTC
Severity:   High (mailbox of an accounts payable approver)
Confidence: Medium (user not reached yet)
 
Entity:     j.ortega@corp.example
Timeline:   07:58  sign-in from 203.0.113.44 (Lisbon), MFA push approved
            08:03  sign-in from 198.51.100.20 (Austin), MFA push approved
            08:11  inbox rule "Archive" created: moves mail containing
                   "invoice" to the RSS Feeds folder
            08:40  alert fired: impossible travel
Ruled out:  198.51.100.20 is not in VPN or proxy egress ranges; no travel
            on file; registered device is an iPhone, the 08:03 session
            reports an unregistered Windows device
Done:       nothing yet; session revoke needs L2 approval (runbook IR-7)
Ask:        approve session revoke and password reset; check whether mail
            was sent or forwarded from the 08:03 session after 08:11
Evidence:   sign-in log export (2 rows), inbox rule audit record, alert link

L2 can act on this in a minute. They know who is affected, what has been checked, what has not been done and which decision is being asked of them. The inbox rule is the line that moved the case from "odd sign-in" to escalation: it shows someone acting inside the mailbox, not just signing in to it.

When not to escalate

• A documented false positive with matching fields. If rule, host and account match an entry in the tuning backlog, close it and reference that entry. If only some fields match, it is not the same alert.
• An incident is already open for the same entity. FIRST's framework says potential incidents tied to the same assets or identities are "grouped together and escalated as a single information security incident in order to avoid duplicate efforts", and that new related ones are assigned to the open incident "instead of opening a new, separate" one. Attach and comment; do not start a parallel ticket.
• Prevention worked and nothing ran. A file blocked on write on one host, with the delivery path understood, closes at L1 with notes. If the same lure keeps arriving, that pattern goes in the shift handover.
• The action is already yours to take. If the runbook pre-approves it for L1, take it, record it, and escalate only what is left.

Holding a case too long is the other way to get it wrong. Uncertainty is a valid reason to hand a case on, as long as the ticket says what is uncertain. Sitting on a case to avoid looking stuck gives an attacker time, which is why a runbook can add a time-in-queue trigger: unresolved after a set time, the case goes up regardless.

Beyond L2: incident lead, leadership, legal and communications

Once L2 confirms an incident, the chain leaves the SOC. Rev. 3 suggests designating an incident lead for each incident and names the roles that join. Leadership "may have decision-making authority on high-impact response actions, such as shutting down or rebuilding critical services". Legal is consulted when an incident may have legal ramifications. Public affairs handles the media and the public when they need to be told. Regulators and law enforcement are notified "based on criteria in the incident response plan and management approval."

None of that is an analyst decision, but your ticket timestamps feed it, because some notification clocks start when the organization becomes aware of an incident or makes a determination about it:

Your job here is to hand the case on as soon as the trigger is met and to write down when you saw each fact. Whether an incident is material or significant is for the incident lead, legal and leadership to decide. The full life cycle is on the incident response page, and the automated side, where a playbook opens and assigns the ticket for you, on SOAR.

Measuring time to escalate in Microsoft Sentinel

Sentinel has no built-in "escalated" field. If your SOC hands a case to L2 by reassigning the incident, the first change of owner after pickup is a usable proxy. This query measures it from the SecurityIncident table:

// Proxy: minutes from first owner (L1 pickup) to the next owner (handoff)
let lookback = 30d;
let updates = SecurityIncident
    | where CreatedTime > ago(lookback)
    | extend OwnerUpn = tostring(Owner.userPrincipalName)
    | where isnotempty(OwnerUpn);
let pickup = updates
    | summarize arg_min(LastModifiedTime, OwnerUpn) by IncidentNumber
    | project IncidentNumber, PickedUp = LastModifiedTime, FirstOwner = OwnerUpn;
updates
| join kind=inner pickup on IncidentNumber
| where OwnerUpn != FirstOwner and LastModifiedTime > PickedUp
| summarize arg_min(LastModifiedTime, Severity) by IncidentNumber, PickedUp
| extend MinutesToHandoff = (LastModifiedTime - PickedUp) / 1m
| summarize Handoffs = count(), MedianMin = round(percentile(MinutesToHandoff, 50), 1), P90Min = round(percentile(MinutesToHandoff, 90), 1) by Severity
| order by P90Min desc

The query is written against the documented SecurityIncident columns and the userPrincipalName field of the incident owner in the Sentinel incidents API. It has not been run against a live workspace. If L2 takes work from a separate queue, a label or a tag instead of a reassignment, change the condition that defines the handoff. A long P90 on High incidents points at tickets that sat with L1. Lots of Low incidents among the handoffs suggest over-escalation and triggers that need tightening.