Escalation procedure

Also known as: escalation path

Agreed rules for when a problem must be passed up to someone more senior or more expert, and to whom.

Draft - this entry has not been reviewed yet.

How to put it into practice

The usual steps, in order. Adapt them to your organisation.

Build a severity matrix with four or five levels and objective criteria, such as which systems are hit and how critical they are, how many users or customers are affected, whether personal data may be involved and whether there are signs of an active attacker.
For each level, write who must be told, within how many minutes, over which channel, and who has the authority to decide.
Define both routes - functional escalation to people with more specialist skill, such as tier 2, the network team or your external IR provider, and hierarchical escalation to people with more authority, such as the security manager, the IT director or the crisis team - and let either be triggered on its own.
Add time limits that escalate automatically, for example to the next person if an alert is not acknowledged within 15 minutes, and set them up as escalation policies in your on-call tool.
Route every possible significant incident straight to the person who assesses NIS2 significance, because the 24-hour early warning runs from awareness, and send anything that may involve personal data to the data protection function at once.
Name people and deputies, not just roles, and keep phone numbers on paper or in a channel that does not depend on the systems under attack.
Log every escalation and de-escalation decision with a timestamp, and write the criteria for stepping down again.
Test the procedure in exercises and review it after each real incident and at least once a year, so the matrix and contact details stay current.

Common pitfalls

Severity levels so vague that everything ends up either critical or ignored.
Escalation that depends on whether the person on duty dares to wake a director at night, instead of on clear rules.
Contact details kept only in the email or directory service that the incident has taken down.
Holding back a possible NIS2 or GDPR case until it is certain, so the reporting deadline has already passed.

Good guides

Plan - Your cyber incident response processes(opens in a new tab) · NCSC UK
Site Reliability Engineering - Managing Incidents(opens in a new tab) · Google
Vejledning til NIS 2-loven - Hændelsesunderretning(opens in a new tab) · Styrelsen for Samfundssikkerhed (in Danish)

Technical deep dive

Escalation has two dimensions that ITIL and most incident-response frameworks separate. Functional (horizontal) escalation moves an alert or incident to people with more specialised skills, for example from a SOC tier 1 analyst to tier 2 or 3, to the network team or to an external incident response retainer. Hierarchical (vertical) escalation moves it to people with more authority, such as the security manager, the CIO, the crisis team or the board, because a decision is needed that the current handler is not mandated to take. Most procedures combine both and trigger them independently.

Triggers are defined as a severity matrix, typically four or five levels (SEV1 to SEV4 or P1 to P4), with objective criteria such as affected systems and their criticality, number of users or customers affected, confirmed or suspected involvement of personal data, evidence of an active attacker, lateral movement or privileged-account compromise, and media or regulator attention. Each level maps to who must be informed, within what time, over which channel, and who has decision authority. Time-based escalation is equally important: if an incident at a given severity is not acknowledged within, say, 15 minutes or not contained within a set period, it escalates automatically. On-call tooling implements this as escalation policies that page the next person in the chain.

Regulatory thresholds belong in the matrix. Under NIS2 Article 23(3) an incident is significant if it has caused or is capable of causing severe operational disruption or financial loss, or has affected or can affect others by causing considerable material or non-material damage, and Commission Implementing Regulation (EU) 2024/2690 sets quantitative thresholds for digital infrastructure and digital service providers. Because the 24-hour early warning runs from awareness of a significant incident, the procedure must route candidate incidents quickly to whoever assesses significance. Likewise, any incident that may involve personal data should be escalated to the data protection function immediately, since the GDPR 72-hour clock under Article 33 runs in parallel.

Common failures are procedures that name roles but not people or deputies, contact details stored only in systems affected by the incident, escalation that depends on the first responder's courage to wake a director at night, and severity levels defined so vaguely that everything is either critical or ignored. De-escalation criteria and a record of every escalation decision with timestamp are also part of the procedure, as they feed the incident report and the lessons-learned review.

What to learn first

Everything this builds on, foundations first.

Threat
→Incident response
→Escalation procedure

Relationships

Part of: Contingency plan
Requires: Incident response
Used with: Management responsibility Security operations centre (SOC)Alert triage

Sources & further reading

Standards & official texts

NIST SP 800-61 Rev. 3 - Incident Response Recommendations and Considerations

Course material

Cyber Security Fast Track - Kursuskompendium, Modul 6 og 7

Where this data comes from

This entry was drafted by an AI from the sources above and has not yet been checked by a person. Treat it as a starting point, and check anything important against the sources.

See the review queue Suggest a correction on GitHub This term as JSON

Check yourself

Loading…