TemplateGLOBAL

ISO 27035 Incident Severity and Escalation Matrix

A practical severity and escalation template grounded in ISO/IEC 27035 classification and prioritization guidance.

Use it to make assessment and decision-making faster, more consistent, and easier to review after the fact.

Back to main artifact Review sources

Author

Sorena AI

Published

Mar 4, 2026

Updated

Mar 4, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published Mar 4, 2026

Updated Mar 4, 2026

Overview

Part 2 of ISO/IEC 27035 includes example approaches to categorization, evaluation, and prioritization of information security events and incidents. The purpose is consistency. A good severity matrix should let different responders reach the same answer about priority and escalation from the same facts.

Section 1

Start with the classification scale, not the pager labels

The standard expects the incident management plan to reference a document describing event and incident classification and severity ratings if they are used. That means severity should be built on top of a stable classification scale, not invented separately by each team.

Your matrix should classify the event type and the affected resource before assigning priority.

Classify the incident type consistently across reports
Identify the affected asset or service and the relevant business owner
Keep the scale aligned with the information classification policy

Section 2

Evaluation model: measure consequences, not only technical symptoms

Part 2 states that incident evaluation determines impacts and consequences to the organization and the priority to respond. That means the matrix should consider business, legal, and service consequences as well as technical damage.

Use a small number of dimensions with thresholds that can be applied quickly.

Confidentiality, integrity, and availability impact
Business service criticality and customer impact
Scope of affected systems, users, sites, or tenants
Regulatory, contractual, reputational, and recovery cost impact

Section 3

Prioritization model: tie the score to predetermined response time frames

Part 1 expects incidents to be dealt with efficiently and within predetermined time frames. A severity matrix is incomplete if it only names a level and does not bind that level to a response expectation.

Each priority should specify response ownership, approval authority, update cadence, and closure expectations.

Critical priority: immediate IMT and executive involvement with tight update cadence
High priority: incident coordinator led response with formal containment and business owner involvement
Medium priority: managed operational response with defined review triggers
Low priority: documented disposition or backlog handling with reassessment rules

Recommended next step

Turn ISO 27035 Incident Severity and Escalation Matrix into an operational assessment

Assessment Autopilot can take ISO 27035 Incident Severity and Escalation Matrix from operationalizing response workflows and review cycles to a reusable workflow inside Sorena. Teams working on ISO 27035 can keep owners, evidence, and next steps aligned without copying this guide into separate documents.

Assessment workflow

Open Assessment Autopilot for ISO 27035 Incident Severity and Escalation Matrix

Start from ISO 27035 Incident Severity and Escalation Matrix and turn the guidance into owned tasks, evidence requests, and review checkpoints.

Explore next step

Talk to Sorena

Talk through ISO 27035

Review your current process, evidence gaps, and next steps for ISO 27035 Incident Severity and Escalation Matrix.

Explore next step

Section 4

Escalation triggers: define the situations that override debate

A stable matrix includes automatic escalation triggers so teams do not waste time renegotiating severity during a fast moving incident. These triggers should be tied to the event type, affected resource, and consequence pattern.

The exact triggers vary by organization, but the logic should be deterministic.

Potential exposure of regulated or highly classified information
Compromise of privileged access or core identity systems
Broad customer or production outage that threatens recovery objectives
Evidence of active attacker persistence, lateral movement, or destructive action

Section 5

Required records: severity decisions should be reviewable later

The standard expects documentation through event reports and incident management logs. Your matrix should require responders to record why a severity level was chosen, not only what the final label was.

That record is what lets the organization improve the model later.

Record the observed facts used to classify the event
Record the consequence assumptions used in evaluation and prioritization
Record the escalation decision, decision maker, and time of decision

Section 6

Improve the matrix with actual incident outcomes

Part 2 expects lessons learned and review of risk assessment results when incidents show actual consequences differ from prior expectations. Severity design should therefore be updated using real incident data, not only opinion.

If the matrix regularly understates or overstates incidents, the governance loop is broken.

Compare predicted impact with actual impact after incident closure
Update thresholds where recurrence shows the model is off
Use recovery cost, restoration time, and customer effect data to recalibrate the matrix

Primary sources