Topics in this domain
- Event vs Incident vs Breach
- Developing the Incident Response Plan
- Incident Response Team Roles and Authority
- Incident Classification and Severity Levels
- Incident Response Playbooks and Decision Trees
- Escalation and Communication Plans
- Business Impact Analysis
- RTO, RPO, MTD and Recovery Prioritisation
- Business Continuity Planning and Strategies
- Crisis Management and Continuity Governance
- Disaster Recovery Planning
- Recovery Sites: Hot, Warm and Cold
- Backup Strategies and Cloud DR
- Incident Response Training
- Testing Plans: Tabletop, Functional and Full Interruption
- Evaluating Exercises and Improving Readiness
- Security Event Detection and Monitoring Methods
- SIEM, the SOC and Event Correlation
- Threat Intelligence and Indicators of Compromise
- Incident Triage and Initial Investigation
- Evidence Preservation, Forensics and Chain of Custody
- Containment Strategies: Short-Term and Long-Term
- Making Containment Decisions
- Breach Notification and Regulatory Reporting
- External Communications: Customers, Media and Law Enforcement
- Eradication, Recovery and Return to Normal Operations
- Post-Incident Review and Root Cause Analysis
- Lessons Learned and Incident Trend Analysis
Incident Classification and Severity Levels
Why classify?
Not every incident deserves a midnight call to the CEO, and some do. Classification decides how fast to respond, who gets involved and who must be told. Agreed in advance, it removes guesswork when the clock is running. One CISM task is to establish and maintain an information security incident classification and categorisation process.
Two things are classified:
- Category: what type of incident it is.
- Severity: how much it matters to the business.
Severity levels
| Severity | Example | Response | Notify |
|---|---|---|---|
| Critical (1) | Ransomware spreading; customer data stolen | Immediately, 24x7, full IR team | Executives, legal, possibly regulators |
| High (2) | Compromised admin account; key service degraded | Within 1 hour | CISO, system owner |
| Medium (3) | Malware on one laptop, contained | Same business day | Security manager |
| Low (4) | Policy violation, no data at risk | Within days | Line manager |
Each level also defines when to escalate into the BCP or DRP.
What drives severity
- Data involved: its classification; personal or regulated data?
- Systems affected: critical business services?
- Scope and spread: one device or many? Still spreading?
- Business impact: revenue, operations, safety.
- Legal and reputation: notification duties, contracts, media attention.
Severity is about business impact, not how technically interesting an incident is.
Categories
| Category | Examples |
|---|---|
| Malware | Ransomware, trojans, worms |
| Unauthorised access | Compromised accounts, intrusions |
| Data loss or leakage | Misdirected email, exfiltration, lost devices |
| Denial of service | DDoS, resource exhaustion |
| Insider misuse | Abuse of legitimate access |
| Physical | Theft of equipment, unauthorised entry |
Consistent categories make trend analysis and reporting possible. A large “other” category makes them useless.
Re-rate as facts emerge
Example. A phishing click on one laptop is logged as Medium. Two hours later, the investigation shows the attacker used the stolen session to access the finance mailbox and set up forwarding rules. The incident is upgraded to High, the CFO is informed, and legal starts assessing notification.
Severity is a live judgement, reviewed at every update. Incidents can be upgraded or downgraded.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Main basis for incident severity | Business impact |
| Why define severity levels in advance | Consistent, timely response and escalation |
| New facts show greater impact | Reclassify and escalate |
| Benefit of consistent categories | Trend analysis and reporting |
| What severity determines | Response time, responders and notifications |
In short
- Establishing and maintaining an incident classification and categorisation process is a CISM task.
- Categories describe the type (malware, unauthorised access, data loss, denial of service, insider, physical); severity describes the business impact.
- Severity criteria are agreed in advance: data involved, systems affected, scope and spread, business impact, legal and reputational exposure.
- Each severity level sets response times, who responds, who is notified and when to escalate to BCP or DRP.
- Severity is reassessed as facts emerge; incidents can be upgraded or downgraded.
- Consistent categories make trend analysis and reporting possible.
Exam traps
- Severity is about business impact, not how technically interesting an incident is.
- Rating an incident once and never revisiting it leads to under-response.
- Without agreed criteria, different analysts rate similar incidents differently.
- Vague categories ('other') make trend analysis useless.
Slides
Click the slide and use the arrow keys. F toggles full screen.
Severity levels
What drives severity