The concept
An incident is easier to manage when responsibilities and contact routes are known in advance. A basic plan identifies who receives reports, who can isolate affected systems, how evidence is preserved, and how operations continue. Encourage prompt reporting of mistakes; people who fear blame may delay the information needed to reduce harm.
Worked example
A fictional charity discovers that an account sent unexpected messages. The receptionist knows to contact the designated coordinator through an established channel. The coordinator follows the service's recovery process, reviews access, preserves relevant records, and identifies other systems connected to the account. Staff use a previously documented alternative channel for urgent work while the investigation proceeds, instead of inventing conflicting instructions in the compromised mailbox.
Limits and judgment
Specific technical steps depend on the system and circumstances, so a generic checklist cannot replace qualified incident support. Avoid destroying evidence through improvised cleanup or making unsupported public claims about scope. After recovery, record what happened, what remains uncertain, and what process should change. A short rehearsal often reveals missing contacts or inaccessible instructions before a real disruption.
FROM UNDERSTANDING TO ACTION
Put it to work.
Run a tabletop exercise: one shared account appears compromised. Assign reporting, investigation, and continuity roles.
RETRIEVE. REASON. REMEMBER.
Knowledge check.
Choose one answer for each question, then check your reasoning.
Sources & further reading.
Links support the core concepts or identify the book. Examples, exercises, and critical analysis are original Institute material. Source checks are not an independent expert review of every claim.
- NIST: Securing Data & Devices ↗
Security or privacy principle; the fictional scenarios and operational analysis are original. Source reviewed 2026-10-19.