5.1.4. Incident Classification and Categorization
💡 First Principle: Without a documented severity scheme, every event gets treated as equally urgent, which means the team's attention goes to whatever arrived most recently or loudest — not to whatever actually threatens the business most.
A classification scheme distinguishes a blocked phishing email (routine, no response needed beyond logging) from active data exfiltration from a production database (highest severity, full incident response activation) — using pre-defined, objective criteria (systems affected, data sensitivity involved, business function disrupted) rather than in-the-moment judgment calls made under stress. Treating every security-related event as a full "incident" causes the opposite failure mode: alert fatigue that desensitizes the team and buries the genuinely severe event in noise.
| Severity | Example | Response |
|---|---|---|
| Low | Single blocked phishing email | Log only |
| Medium | Malware contained to one isolated endpoint | Standard IR workflow, no executive escalation |
| High | Confirmed unauthorized access to a production system | Full IR activation, executive notification |
| Critical | Active data exfiltration from a regulated data store | Full IR activation, executive and legal/regulatory notification |
⚠️ Exam Trap: Every security-related event is sometimes treated as a formal "incident" requiring full response. The correct answer relies on a documented classification scheme to distinguish routine events from true incidents, since treating everything identically causes alert fatigue and misallocated response.
Reflection Question: Your team currently escalates every failed login alert as a full incident requiring executive notification. What's the long-term effect of this on the team's ability to respond to a genuinely critical event?
