Incident escalation, response planning, forensics, insurance, and root-cause remediation.
This chapter explains what happens after prevention fails and an event must be assessed, escalated, and contained. The ISC focus is on disciplined response, evidence preservation, recovery planning, and learning from failure.
Incident-response questions should be sequenced carefully. A strong response distinguishes events from incidents, escalates promptly, preserves evidence, restores operations, and fixes root causes without destroying the audit trail.
| Response stage | First question | Common ISC trap |
|---|---|---|
| Events and escalation | Has the event met the threshold for formal incident response? | Treating all alerts as equal or delaying escalation. |
| Response and crisis management | Who coordinates containment, communication, and recovery decisions? | Letting technical remediation proceed without incident governance. |
| Forensics and chain of custody | What evidence must be preserved and how is custody documented? | Destroying evidence while trying to restore service quickly. |
| Cyber insurance | What risk is transferred and what conditions or exclusions apply? | Treating insurance as a substitute for response controls. |
| Root cause and permanent fix | What underlying weakness caused the incident and how will recurrence be prevented? | Closing the incident after recovery without remediation. |
| Step | What to do | Why it matters on ISC |
|---|---|---|
| 1. Triage the event | Determine whether the alert is an event, incident, breach, outage, or false positive. | Formal escalation depends on severity and impact. |
| 2. Escalate and contain | Activate roles, communication paths, containment actions, and crisis governance. | Technical response must be coordinated before evidence or operations are harmed. |
| 3. Preserve evidence | Maintain logs, images, chain of custody, and investigative records. | Recovery actions can destroy evidence if forensics are not planned. |
| 4. Restore operations carefully | Use tested recovery procedures, backups, validation, and stakeholder communication. | Availability matters, but restoration should not reintroduce the same weakness. |
| 5. Perform root-cause remediation | Identify permanent fixes, insurance follow-up, lessons learned, and control improvements. | Incident response is incomplete if recurrence risk remains unaddressed. |
| Checkpoint | Exam use | What to avoid |
|---|---|---|
| Classification | Decide whether the event is a routine alert, confirmed incident, breach, outage, or false positive. | Escalating everything the same way or delaying escalation after severity is clear. |
| Response authority | Identify who can invoke the plan, communicate externally, approve containment, and direct recovery. | Letting ad hoc technical action replace incident governance. |
| Evidence preservation | Preserve logs, images, timestamps, access records, and custody documentation. | Rebuilding systems before capturing evidence needed for investigation or legal support. |
| Recovery validation | Confirm backups, restored systems, changed credentials, and affected processes before returning to normal operation. | Restoring service quickly while the original weakness still exists. |
| Lessons learned | Connect root cause, insurance conditions, control gaps, and permanent remediation. | Closing the incident ticket after operations resume but before control improvement occurs. |