FAQGlobalISO/IEC 27035

ISO/IEC 27035 FAQ Severity Classification

Classify incident severity under ISO/IEC 27035 using organization-specific criteria and reassess it as facts, impact, and recoverability change.

ISO/IEC 27035 is voluntary guidance, not a law or standalone certification scheme. Apply separate legal, contractual, regulatory, privacy, and evidence requirements where relevant.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 25, 2026
Questions
5

Structured answer sets in this page tree.

Primary sources
4

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated Jul 25, 2026
Overview

ISO/IEC 27035 does not prescribe universal severity labels. Each organization should build an suited to its information, systems, services, risks, and response capability, then apply it consistently during and revise the rating as facts change.

Search this module

Find a question or answer quickly

5 of 5 questions
Question 1

What should an ISO/IEC 27035 severity classification consider?

Base the rating on actual or projected adverse consequences for the organization's operations, individuals, and other organizations. Useful criteria include asset or service criticality, confidentiality, integrity and availability impact, scope, affected parties, spread, threat activity, recoverability, safety, and uncertainty. ISO examples include partial or complete interruption of core services, minor or large disclosure of sensitive information, system destruction, network failure, physical damage, infrastructure failure, malware, technical attack, rule breach, and compromise of information.

Keep category, severity, urgency, and notification analysis distinct. Severity expresses impact under the organization's scale; priority also reflects time and response needs. A statutory or contractual reporting threshold must be assessed against its own wording.

  • Define each level with observable criteria, required coordinator or team, decision authority, response target, and escalation route.
  • Keep initial and revised ratings with timestamps and reasons rather than overwriting the record.
  • Do not treat the internal severity label as proof that a statutory reporting threshold is or is not met.
Citations
NIST SP 800-61r3

NIST supports risk-based incident triage, prioritization, escalation, and elevation using factors such as asset criticality, functional and data impact, observed activity, threat actor characteristics, and recoverability.

Question 2

What should a severity matrix and case record contain?

Define each level with observable impact or consequence criteria, examples, required response roles, authority, target times, communication route, escalation trigger, and exit criteria. Avoid labels such as low, medium, and high without tests that different assessors can apply consistently. ISO/IEC 27035-3 includes an informative four-level example, but its names and thresholds are not mandatory and should not be copied without adapting them to the organization's services and risk.

For each case, retain the initial rating, evidence used, uncertainty, assessor, time, and required actions. Add later ratings instead of overwriting the first one so the record shows how the incident evolved.

  • Test borderline and multi-service scenarios in exercises.
  • State how cumulative events, unknown scope, safety impact, and critical suppliers affect the rating.
  • Compare similar incidents periodically to find inconsistent classifications.
Citations
Question 3

Who should assign and approve severity?

The should assess the event or incident against the approved scale and assign the initial rating, with input from affected business, asset, service, privacy, safety, and supplier owners as needed. The policy should identify who may confirm, raise, or lower each level.

The rating should activate response resources and authority, not wait for a committee. Decisions outside delegated authority, including crisis activation or material business interruption, should follow the escalation path.

  • Allow provisional high ratings when the potential impact is serious and facts are incomplete.
  • Record disagreements, the final decision, and the authority used.
  • Do not let an incident owner lower severity only to meet a service target.
Citations
ISO/IEC 27035-1:2023 standard page

ISO/IEC 27035-1 defines the incident-management process context for assessing incidents, which supports severity classification and escalation decisions.

Question 4

When should severity be reassessed?

Reassess after analysis, containment attempts, discovery of additional affected systems or people, recovery setbacks, supplier updates, or a change in legal or contractual notification analysis. Review at the frequency set for the current level and whenever the incident leaves its defined criteria.

A lower rating should follow evidence that impact and uncertainty have reduced, not only elapsed time. Record the new rating, time, facts, decision maker, and changes to resources, communications, or targets.

  • Keep response and notification clocks running according to their controlling rules.
  • Escalate when the incident is not under control or exceeds authority even if the numeric rating has not changed.
  • Use post-incident review to correct criteria that produced delay, ambiguity, or inconsistent results.
Citations
ISO/IEC 27035-1:2023 standard page

ISO/IEC 27035-1 defines the incident-management process context for assessing incidents, which supports severity classification and escalation decisions.

Question 5

Which ISO parts and external thresholds apply?

ISO/IEC 27035-1:2023 supplies the generic process and roles. ISO/IEC 27035-2:2023 covers planning for categorization, evaluation, prioritization, forms, escalation, and response capability. ISO/IEC 27035-3:2020 covers operational and gives informative examples based on incident type, impact, information or system importance, damage scale, alarm level and severity, organizational spread, and financial loss. The examples illustrate a method and do not create a universal scoring formula.

The series is voluntary global guidance for organizations of any type, size, or nature. It does not create a certification class, legal incident category, regulator threshold, notification deadline, recovery objective, or service-level target. Apply binding laws, regulator rules, contracts, insurance terms, safety duties, and customer commitments against their own wording even when the internal severity stays unchanged.

  • Record the edition, matrix version, facts, evidence, uncertainty, assessor, timestamp, rating, required actions, and next review trigger.
  • Review the matrix after incidents, exercises, material service or supplier changes, new threat patterns, inconsistent ratings, and changes to law or contracts.
  • Keep category, severity, priority, escalation, crisis activation, and external notification as linked but separate decisions.
Citations
Primary sources

References and citations

iso.org
Referenced sections
  • ISO identifies Part 2:2023 as planning and preparation guidance, including creation of a classification scale.
iso.org
Referenced sections
  • ISO identifies Part 3:2020 as ICT operations guidance; its triage and annex examples inform organization-specific severity criteria.
csrc.nist.gov
Referenced sections
  • NIST supports risk-based incident triage, prioritization, escalation, and elevation using factors such as asset criticality, functional and data impact, observed activity, threat actor characteristics, and recoverability.
"asset criticality, functional impact of the incident, data impact of the incident, stage of observed activity, threat actor characterization, and recoverability"
Related guides

Explore more topics

ISO/IEC 27035 Compliance Guide
Understand what the ISO/IEC 27035 series covers, how its three published parts fit together, and how to adopt the guidance without mistaking it for a law or certification scheme.
ISO/IEC 27035 CSIRT Roles FAQ
Assign ISO/IEC 27035 incident coordinator, IMT, IRT or CSIRT, point-of-contact, evidence, communications, and business decision roles.
ISO/IEC 27035 Escalation FAQ
Define ISO/IEC 27035 escalation and elevation triggers, authorities, handoff evidence, and reassessment rules before incidents occur.
ISO/IEC 27035 Event vs Incident FAQ
Distinguish an information security event from an incident under ISO/IEC 27035 and record the assessment without discarding useful event evidence.
ISO/IEC 27035 Evidence Log Template
Use an ISO/IEC 27035-aligned incident log to preserve facts, decisions, actions, communications, evidence references, and chain-of-custody information.
ISO/IEC 27035 Incident Lifecycle Guide
Follow the ISO/IEC 27035 five-phase incident-management process and understand how the detailed ICT response loop fits inside it.
ISO/IEC 27035 Incident Lifecycle Workflow
Turn the ISO/IEC 27035 lifecycle into an operational workflow with explicit decisions, handoffs, owners, evidence, and reopening triggers.
ISO/IEC 27035 Incident Management FAQ
Plain-language ISO/IEC 27035 answers on events, incidents, roles, severity, escalation, evidence, notification, retention, review, and lessons learned.
ISO/IEC 27035 Incident Response Playbook
Build ISO/IEC 27035-aligned playbooks that guide detection, triage, analysis, containment, eradication, recovery, reporting, and evidence preservation.
ISO/IEC 27035 Incident Severity and Escalation Matrix
Design an ISO/IEC 27035-aligned severity and escalation matrix using impact, priority, damage, urgency, recoverability, and reporting triggers.
ISO/IEC 27035 Incident Timer Workflow
Create an incident clock that tracks operational checkpoints and separate legal or contractual deadlines without inventing ISO/IEC 27035 time limits.
ISO/IEC 27035 Lessons Learned FAQ
Apply ISO/IEC 27035 lessons learned to plans, controls, risk decisions, training, relationships, metrics, and future response capability.
ISO/IEC 27035 Notification Evidence FAQ
Preserve evidence for internal and external incident notifications without attributing legal deadlines or reporting duties to ISO/IEC 27035.
ISO/IEC 27035 Notification Threshold Mapping Guide
Map ISO/IEC 27035 incident reporting routes to separate legal, contractual, customer, supplier, insurer, and internal notification thresholds.
ISO/IEC 27035 Post Incident Review FAQ
Run an ISO/IEC 27035 post-incident review after stabilization and recovery, then assign measurable improvements without losing accountability.
ISO/IEC 27035 Retained Logs FAQ
Retain ISO/IEC 27035 incident logs and digital evidence according to purpose, investigation needs, law, contracts, privacy, and organizational policy.
ISO/IEC 27035 vs ISO 22301 Comparison
Compare ISO/IEC 27035 incident-management guidance with ISO 22301 business continuity management-system requirements and certification scope.
ISO/IEC 27035 vs NIS2 Comparison
Compare voluntary ISO/IEC 27035 incident-management guidance with binding NIS2 duties for in-scope EU entities and national implementation.
ISO/IEC 27035 vs NIST SP 800-61 Comparison
Compare ISO/IEC 27035 with the current NIST SP 800-61 Rev. 3 while preserving this legacy route for visitors using the older publication name.
ISO/IEC 27035 vs NIST SP 800-61 Rev. 3 Comparison
Compare the ISO/IEC 27035 series with NIST SP 800-61 Rev. 3 incident-response guidance and show how organizations can use both.