19.1 What an Incident Is and How to Classify It
Events Are Cheap; Incidents Are Expensive
An event is any observable occurrence on a system: a login, a failed handshake, a process spawn, a firewall drop. A security incident is a narrower thing: an event, or a chain of events, that actually threatens confidentiality, integrity, or availability (CIA). Thousands of events fire per hour; only the ones that endanger data or operations earn the incident-response process. The classification gate exists so the IR team never drowns in log noise — and so a genuine compromise never slides into the ticket queue as "just another alert."
The Severity Ladder
Most shops run a three-rung ladder. P3 (alert): suspicious but contained or unverified — normal operations handle it on shift, monitor, and log; no IR activation. P2 (incident): a confirmed CIA impact on a live system — on-call IR responders are paged and the containment clock starts. P1 (breach): confirmed exposure of regulated or sensitive data, or widespread outage with legal implications — legal, communications, and executives join, and notification windows under law or cyber-insurance contracts start ticking, sometimes measured in hours. The one design rule that matters: severity definitions must be written down before the 2 a.m. page, because improvised judgment under stress is how incidents get mis-served.
Where Classification Sits in the Lifecycle
NIST SP 800-61 splits the lifecycle into preparation; detection and analysis; containment, eradication, and recovery; and post-incident activity. Classification lives inside detection and analysis, right after validation: analysts filter noise, then assess impact from asset value and incident magnitude — quantitative estimates (currency lost or extractable) plus qualitative categories (data sensitivity, reputational reach). Misclassification costs in both directions: over-escalating false alarms burns responder capacity and trust; under-escalating a real breach burns the clock, which ransomware operators and notification deadlines spend happily.
Decide Fast, Document Anyway
Time-box the initial severity call, give one named role ownership of it, and record the rationale, the decider, and the time. Severity can climb or fall as facts mature; the audit trail of those moves becomes part of the incident record, and insurers and regulators read it.
Architecture Diagram
Key Takeaways
- An event is any observable occurrence; an incident is one that threatens confidentiality, integrity, or availability.
- The ladder is three rungs: P3 alerts stay with operations, P2 incidents page IR, P1 breaches activate legal and comms.
- Write severity definitions and triggers into the runbook in advance; never improvise them during a live page.
- Impact assessment weighs asset value and incident magnitude, quantitatively and qualitatively, inside NIST 800-61's detection-and-analysis phase.
- Time-box the first severity call and document the rationale — insurers and regulators will read it.