An escalation matrix is the documented answer to the question: when this specific type of problem occurs and the current tier cannot resolve it within this time, who gets contacted, through what channel, and with what information. Without a documented escalation matrix, the answer to that question depends on who is on shift and who they happen to know, which means escalation is inconsistent, slower than it needs to be, and entirely dependent on institutional knowledge that leaves when engineers leave.
For ISPs with 24x7 operations or on-call coverage, the escalation matrix is the operational backbone that makes coverage work without the most experienced engineer being permanently available.
The Tier Structure
Most ISP operations teams have a natural tier structure whether it is formally named or not. Defining it explicitly makes it possible to design the escalation paths correctly.
Tier 1 is the first point of contact for any operational event: the on-shift NOC engineer, helpdesk agent, or monitoring responder. Tier 1 handles routine alerts, subscriber support calls, and incidents that have known resolution procedures. Tier 1 should be able to resolve the majority of events without escalation: if Tier 1 escalates more than 20-30% of events, either the Tier 1 capability is insufficient or the escalation trigger criteria are too aggressive.
Tier 2 is senior operations engineers with deeper technical knowledge. Tier 2 handles incidents that Tier 1 cannot resolve within the defined response time, incidents involving core infrastructure, and any incident requiring configuration changes to production equipment. Tier 2 is the primary on-call tier for ISPs without 24x7 staffed NOCs.
Tier 3 is subject matter experts, network architects, or external vendor support. Tier 3 handles incidents that Tier 2 cannot resolve, situations requiring deep expertise in specific platforms, and incidents that have been ongoing beyond the SLA resolution time. For Pakistani ISPs, Tier 3 often includes upstream provider technical support contacts.
Escalation Triggers
Define specific triggers for escalation from each tier rather than leaving the decision to individual judgment. Trigger criteria include both time-based triggers (escalate if not resolved within 30 minutes at Tier 1) and condition-based triggers (escalate immediately if the incident affects core routing or more than 50 subscribers regardless of how long it has been open).
Time-based triggers provide a safety net for incidents where the complexity was underestimated initially. Condition-based triggers ensure that high-severity incidents receive senior attention immediately rather than waiting for a time threshold to expire. Both types of trigger should be in the matrix.
For CTDISR-2025 incident reporting, there is an additional trigger type: any incident that may qualify as a cybersecurity incident under CTDISR-2025 Section 5 should automatically trigger a notification to the CISO alongside the standard operational escalation, because the 24-hour PTA reporting clock starts at detection and cannot wait for the operational escalation chain to work through its tiers.
Contact Information Management
The escalation matrix is only functional if the contact information in it is current. An on-call roster with outdated mobile numbers, a Tier 2 contact who left the company three months ago, or an upstream provider emergency number that was changed and never updated all convert the matrix from a functional tool to a false sense of security.
Assign ownership of the escalation matrix to a specific role (typically the NOC manager or CISO) and define a review cadence: monthly at minimum, immediately following any personnel changes that affect on-call coverage. The matrix should be stored somewhere accessible during an incident: a shared operations platform, a posted document in the NOC, a pinned message in the operations communication channel. Not in a file on one person's laptop.
The Information Package at Escalation
When escalating to a higher tier, the engineer initiating the escalation should provide a standard information package rather than requiring the receiving engineer to gather context from scratch. Define what this package contains: the incident description, what has been tried and what the results were, the current status of affected services, subscriber impact assessment, and what specific assistance is needed from the higher tier.
This information package is the difference between an escalation that enables the Tier 2 engineer to immediately engage with the problem and one that starts with ten minutes of situation reconstruction. For Tier 3 escalations to upstream providers, the package should additionally include circuit identifiers, relevant log excerpts, and test results showing the issue is confirmed to be on the upstream's side.
For operators building their escalation matrix as part of a broader NOC design, NOC Enablement & Monitoring covers escalation design alongside monitoring, alerting, and shift structure. For escalation procedures documented as formal runbooks, RunBook AI generates structured documentation that operations staff can follow during incidents when clarity matters most.