Incident severity should help a response team decide what needs attention first, who needs to be involved, and how quickly the next action must happen. It should not be a label chosen only after the investigation is complete.
Direct answer
Classify a security incident by assessing current and potential impact across business operations, data, systems, customers, legal or contractual obligations, and recovery effort. Use clear severity levels with defined escalation, ownership, response targets, communication rules, and review triggers.
Classify early using the facts available, record uncertainty, and update the rating as the scope becomes clearer. A preliminary high severity can be reduced later; a vague low severity can delay the right response.
This guide is operational guidance, not legal or regulatory advice. Reporting and notification decisions depend on the facts, applicable obligations, contracts, and qualified review.
Source and scope: NIST SP 800-61 Rev. 3 supports risk-informed incident assessment. The four-level model and example below are Aneo’s suggested internal taxonomy; severity is not the same as legal reportability, and response targets must be set for the organisation.
Why inconsistent severity creates risk
Teams often use labels such as low, medium, high, and critical without defining what they mean. That causes:
- Similar incidents receiving different responses
- Delayed escalation when customer or privileged systems are involved
- Too many incidents being marked critical
- Unclear ownership and handoffs
- Inconsistent management updates
- Metrics that cannot be compared over time
- Post-incident reviews that cannot explain why decisions changed
A useful severity model links the label to action. If the label does not change priority, ownership, escalation, or communication, it is only decoration.
The five dimensions to assess
1. Business impact
Consider whether the incident affects a critical service, revenue, operations, safety, contractual commitment, or the organisation’s ability to serve customers.
2. Data impact
Consider the type, volume, sensitivity, and confidence of any data exposure, alteration, loss, or unavailability. Record what is known and what remains unconfirmed.
3. System and access impact
Consider whether production, identity, privileged accounts, critical infrastructure, or multiple systems are involved. A single compromised administrator account may need a higher response than a larger number of low-value endpoints.
4. Scope and spread
Consider how many users, assets, locations, customers, or suppliers are affected and whether the activity is contained, active, or still expanding.
5. Urgency and uncertainty
Consider whether immediate action can reduce harm, whether evidence may disappear, and whether the team lacks facts that could materially change the decision.
Uncertainty should not automatically lower severity. It should often increase the need for structured triage and escalation.
A practical four-level model
Severity 1: Critical
Use when there is a material or potentially material impact to critical services, sensitive data, privileged access, multiple customers, or business continuity, especially when the threat is active or rapidly spreading.
Typical response:
- Immediate response ownership
- Security and leadership escalation
- Defined update cadence
- Evidence preservation and decision logging
- Customer, legal, privacy, or regulatory review as applicable
- Coordinated containment and recovery planning
Severity 2: High
Use when the incident has significant impact or credible potential to affect important systems, data, users, or customers, but the scope is limited or containment is progressing.
Typical response:
- Priority investigation and named owner
- Security or operations lead involvement
- Regular updates to relevant stakeholders
- Documented containment and evidence actions
- Review for escalation if scope or impact increases
Severity 3: Moderate
Use when the incident is contained or has limited business impact, but requires coordinated investigation, remediation, or follow-up.
Typical response:
- Assigned response owner
- Defined next action and review time
- Relevant team notification
- Evidence and timeline maintained
- Post-incident review when patterns or control gaps are found
Severity 4: Low
Use when the event has low confirmed impact, is contained, or can be handled through a normal operational workflow while still being recorded appropriately.
Typical response:
- Triage record and owner
- Appropriate remediation
- Trend review for repeated signals
- Escalation if new facts change impact or scope
These levels are a starting model. Set the actual thresholds and response targets to fit the organisation.
Step-by-step classification workflow
Step 1: Open the incident record
Capture the summary, detection time, source, affected asset or service, initial indicators, reporter, and current owner. Do not wait for perfect certainty.
Step 2: Record known facts and assumptions separately
Write what the team observed, what it believes may be happening, and what must be confirmed. This avoids an early guess becoming an accepted fact.
Step 3: Assess impact and scope
Use the five dimensions above. If one dimension is unknown but could materially change the result, escalate the question rather than silently assigning the lowest level.
Step 4: Set preliminary severity and actions
Assign the level, owner, priority, immediate containment action, evidence action, update cadence, and escalation path. Link the decision to the facts available at that time.
Step 5: Reassess at defined triggers
Review severity when:
- A new system, customer, or data type is linked
- Privileged access is confirmed
- The activity spreads or becomes active
- Containment succeeds or fails
- Business impact changes
- A reporting or communication decision is required
- The incident is closed and the final impact is known
Record the old and new ratings, time of change, decision maker, and reason.
Example: suspicious administrator login
An alert shows repeated failed logins followed by a successful login to an administrator account. The team does not yet know whether the login was authorised.
The initial rating may be High because privileged access is involved and the facts are incomplete. The team assigns an owner, confirms the user, preserves authentication logs, reviews changes made by the account, and checks whether production or customer data was accessed.
If the login is confirmed as approved activity and no suspicious changes occurred, the severity may be reduced with the rationale recorded. If unauthorised changes or data access are found, it may be raised to Critical.
Avoid severity inflation and severity minimisation
Severity inflation happens when every alert is treated as critical. This exhausts responders and makes genuine emergencies harder to distinguish.
Severity minimisation happens when teams choose a low level because the facts are incomplete. This delays escalation and can lose important evidence or decision time.
Use the label as a working decision, not a permanent judgement. Confidence, impact, urgency, and potential harm should all be visible in the incident record.
Connect severity to metrics and review
Track more than the number of incidents at each level. Useful measures include:
- Time from detection to initial classification
- Time from classification to ownership
- Time to escalation when severity changes
- Time to acknowledge and time to contain
- Number of severity changes and their reasons
- Repeated incidents by root cause or control gap
- Quality and timeliness of management updates
Metrics are useful only when the definitions remain consistent. Review the severity model after major incidents and when teams report that labels do not produce clear action.
Where IncidentAI fits
IncidentAI helps teams structure incoming incident reports, enrich context, suggest severity and likely cause, route ownership, summarise the timeline, and prepare response or RCA notes. Human responders remain responsible for validating facts, setting final severity, approving actions, and making material decisions.
For the first response steps, see the security incident response first-hour checklist. For ticket quality, see how to design incident ticket fields that help responders.
Frequently asked questions
What is incident severity classification?
It is the structured assessment used to prioritise a security incident based on impact, scope, urgency, uncertainty, and the systems, data, customers, and business services involved.
Should severity be assigned before the investigation is complete?
Yes. Assign a preliminary severity using the facts available, record uncertainty, and update the rating when new evidence changes the assessment.
Who should decide incident severity?
The response process should name an accountable role. The responder may set an initial rating, while a security, operations, service, or leadership role may confirm or change it for higher-severity incidents.
What is the difference between severity and priority?
Severity describes impact and potential harm. Priority describes how quickly and with what resources the team should act. Many organisations link them, but they should remain conceptually clear.
How many incident severity levels should a small team use?
Four levels are often enough: Critical, High, Moderate, and Low. The useful part is defining the actions and escalation rules behind each level.