8.4. Incident Management
💡 First Principle: Incident response is a time-critical, evidence-sensitive process where every minute of delay increases the damage (attacker persistence, data exfiltration volume, lateral spread), and every procedural error destroys forensic evidence or creates legal liability. The IR process must be planned, practiced, and documented before the incident occurs — because during a crisis, you execute plans, you do not create them.
The distinction between an event, an alert, and an incident matters operationally: thousands of security events occur every hour (login attempts, file accesses). Some trigger alerts based on detection rules. Only confirmed alerts with actual or probable impact qualify as incidents requiring the IR lifecycle.
Why this matters: IR lifecycle sequencing is heavily tested. The exam expects you to know that containment comes before eradication (you must stop the bleeding before you remove the bullet), that evidence preservation comes before system restoration, and that post-incident lessons learned are not optional — they are the mechanism through which the organization's security posture improves.
⚠️ Common Misconception: "Incident response and disaster recovery are the same process." IR handles security events (breaches, malware infections, unauthorized access). DR handles availability events (hardware failures, natural disasters, site loss). They share some infrastructure (communication plans, escalation procedures) but have different objectives: IR aims to identify, contain, and eradicate a threat; DR aims to restore operations to an acceptable level. A ransomware attack may invoke both — IR to investigate the intrusion and DR to restore encrypted systems.
