Incident Severity and Escalation

Severity describes how serious an incident is, based mainly on its service effect, and escalation moves the incident to a higher level of attention and authority when its severity warrants it. The two work together. Severity gives the incident team a shared language for how bad the position is, and escalation gives that language a consequence, in the form of more senior decision makers, more resources, and wider communication. An incident should be escalated when its severity crosses a defined threshold, when it spreads, or when the team handling it cannot restore the service with the resources it has. The escalation decision, like classification, should be recorded at the time.

Severity levels describe the incident in terms that help the firm respond proportionately. A low severity incident may affect a limited service or a small group, with a workaround available, and can be handled by the usual team. A high severity incident may stop a core service, affect many customers, or threaten a regulatory obligation, and needs senior attention and a coordinated response. The levels should be defined by service effect rather than by technical complexity, so that a simple fault with a wide effect is rated high and a complex fault with no service effect is rated low. Definitions that are too detailed will be forgotten under pressure, while definitions that are too vague will be applied differently by different teams. A few levels, each described in plain service terms, usually work best.

An incident should be escalated when any of several conditions is met. The service effect may have grown, because the disruption has spread or lasted longer than expected. The response may have stalled, because the cause is unclear or the fix is not working. The incident may have acquired a wider significance, because it affects a provider used by other services, or because it will need to be reported to an authority or communicated to customers. Or the handling team may simply need help, in the form of more people, a decision it cannot take alone, or a workaround that needs senior approval. Waiting for certainty before escalating is a common error, because certainty often arrives after the moment when senior help would have mattered most.

The decision to escalate should be owned by a named role in the incident response, usually the incident lead, with the service owner able to trigger escalation on service grounds. That clarity matters, because an incident where everyone can escalate but nobody owns the decision will either escalate too often, as a precaution, or too rarely, as each person waits for another to act. The escalation route should name the person or team to whom the incident goes, and the information that person needs to take over effectively. A handover that consists only of a severity label, without the service effect, the actions tried, and the decisions pending, will slow the response rather than strengthen it.

Two opposite errors occur with escalation. Over escalation, where every incident goes to senior management, exhausts senior attention and teaches senior managers to discount the alerts they receive. Under escalation, where serious incidents stay with a small team, leaves the firm without the authority, resources, or communication it needs at the moment of greatest risk. Both errors often have the same cause, which is severity definitions that do not match the firm's services, or an escalation route that is unclear. Reviewing past incidents for whether escalation was timely, and adjusting the definitions in light of that review, is more useful than simply urging teams to escalate more or less.

De-escalation matters as much as escalation, because senior attention and incident resources are finite. An incident can be de-escalated when the service has returned, when the remaining work is routine follow up rather than live response, or when a reassessment shows the severity was overstated. The decision should be recorded with the same care as an escalation, and it should be communicated to everyone who was involved, so that nobody continues to work as if the incident were still at its peak. Premature de-escalation is a risk, particularly where a service appears restored but the underlying cause is unaddressed, so the decision should rest on evidence of recovery, not merely on the absence of new alerts.