How should teams handle Severity Classification under ISO/IEC 27035?
Start with a simple scoring approach: classify the incident by how much it affects critical services, sensitive data, operational continuity, and the organization's ability to recover quickly.
Use the same factors every time so similar incidents get similar treatment. NIST SP 800-61r3 points incident teams to risk evaluation factors such as asset criticality, functional impact, data impact, stage of observed activity, threat actor characterization, and recoverability when prioritizing incidents and deciding when to escalate or elevate response activities.
A practical rule is that higher severity usually means broader business impact, more urgent response, more difficult recovery, or a greater likelihood that the activity will spread, persist, or cause regulatory, legal, or customer-notification consequences. Lower severity usually means the event is limited in scope, easier to contain, and unlikely to affect critical services or sensitive data.
- Classify severity using consistent factors such as asset criticality, functional impact, data impact, stage of activity, threat actor characterization, and recoverability.
- Treat incidents as more severe when they affect critical services, sensitive data, or time-sensitive operations, or when containment and recovery are difficult.
- Escalate when the severity level changes the urgency, resourcing, communications, legal review, or recovery decision.
- Document the severity rationale so reviewers can see why the incident was placed in that level rather than a lower or higher one.
NIST says incident triage, prioritization, escalation, and elevation should be based on risk evaluation factors.
The publication gives examples of risk evaluation factors that can be used for severity decisions.
The incident report should be checked to estimate severity and urgency.