Incident Classification and Categorization

Classification Versus Categorization

These two terms are tested as a distinction, so keep them separate. Classification assigns a severity or priority, how damaging the incident is and how urgently it must be handled, while categorization assigns a type, what kind of incident it is (malware, phishing, unauthorized access, denial of service, data loss, insider misuse, physical). Classification governs how fast and how high you respond; categorization governs which playbook and skills you apply.

Before either step, recall that an event (any observable occurrence) becomes an incident only after triage confirms it adversely affects, or threatens, confidentiality, integrity, or availability. Declaration against defined thresholds is what activates the response. Treating every alert as a full incident exhausts the team; ignoring real ones is worse.

Severity Driven by Business Impact

CISM insists severity be set from business impact and urgency, not from how interesting the technology is. A defaced marketing page may be low severity; a 200-record exposure of regulated health data is high. A representative severity scale:

The practical formula many programs use: Priority = Impact × Urgency. High impact plus high urgency yields the highest priority and the fastest escalation.

Why Consistent Criteria Matter

Pre-defined, written classification and categorization criteria deliver four management benefits the exam rewards:

• Proportionate response: The team neither over-reacts to noise nor under-reacts to a serious breach, because thresholds are decided in advance, not in the heat of the moment.
• Correct escalation and notification: Severity tiers map to who is told and when, which is critical where breach-notification deadlines apply (for example, GDPR's 72-hour authority notification window). Misclassifying a reportable breach as low severity can cause a missed legal deadline.
• Resource allocation: Limited responders are pointed at the highest-priority incidents first.
• Comparable metrics: Consistent labels let management trend incident volume by type and severity, measure mean time to detect and respond, and report meaningful KPIs to the board.

Common Traps

• Letting the responder's intuition set severity: ISACA prefers a documented matrix applied consistently over individual judgment that varies by person and mood.
• Classifying by technology rather than impact: "It was on a server" is not severity; what the disruption does to the business is.
• Static classification: Severity can change as scope is discovered, a "medium" containment may be re-classified "critical" once exfiltration of regulated data is confirmed. The plan should allow re-classification.
• Confusing category with severity: A phishing email (category) can be low or critical severity depending on whether credentials were captured and used.

Worked scenario: A help-desk ticket reports a single workstation running slowly. Triage finds it is beaconing to a known command-and-control host on the finance network. Categorization: malware/compromise; classification escalates from low to critical because the business impact, potential access to financial systems, is now high, triggering executive and legal notification per the IRP.

Triage, Escalation, and the Notification Clock

Triage is the gate between an event and a declared incident. The team evaluates the alert against documented criteria: is it real (not a false positive), does it affect confidentiality, integrity, or availability, and what is its likely scope? Only confirmed incidents proceed into the lifecycle; this discipline conserves limited responders and prevents alert fatigue from burying the serious cases.

Mapping Severity to Escalation

Classification is only useful if each severity tier is wired to concrete actions. A mature program defines, in advance, who is notified and how fast for each level:

This mapping is what makes classification actionable. The exam rewards the manager who has these thresholds pre-agreed so that escalation is automatic rather than debated mid-crisis.

Legal and Regulatory Notification Drivers

Classification often determines whether external notification obligations are triggered. Many regimes impose hard deadlines: the EU GDPR requires notifying the supervisory authority within 72 hours of becoming aware of a qualifying personal-data breach; various U.S. state and sector laws (and HIPAA for health data) impose their own timelines. If an incident touching regulated data is misclassified as low severity, the organization can blow a statutory deadline and incur fines on top of the breach itself.

CISM expects the security manager to ensure classification criteria explicitly flag potentially reportable incidents to legal early.

Severity Can and Should Change

Classification is not a one-time stamp. As investigation reveals true scope, severity should be re-evaluated, upward when exfiltration or regulated data exposure is confirmed, sometimes downward when an alert proves limited. The IRP should permit and document re-classification, and metrics should record the final, validated severity so management trending stays accurate. Consistent categorization likewise lets the organization see, over time, whether phishing, misconfiguration, or insider activity is the dominant incident driver, pointing investment where it reduces the most risk.