Implementing Incident Management

Foundation's Annex A lessons covered the incident management cluster (5.24-5.28) as a concept. Implementation means building an actual plan with named people, specific playbooks, and — critically — a way to test the plan before a real incident forces you to find out it doesn't work.

Core incident response roles

A plan with no named roles defaults to confusion during an actual incident, when confusion is most costly:

These roles don't need to be full-time positions — in a small organization, one person might hold multiple roles — but each incident should have someone explicitly filling each function, decided in advance, not improvised mid-incident.

Why scenario-specific playbooks beat one generic procedure

A single generic "incident response procedure" tends to be too abstract to be immediately actionable. Scenario-specific playbooks — ransomware, phishing-led credential compromise, a suspected data breach, a DDoS attack — let the team skip straight to relevant, concrete steps:

Ransomware playbook (excerpt):
1. Isolate affected systems from the network immediately
2. Identify the ransomware variant if possible (informs decryption feasibility)
3. Do NOT power off affected systems (may lose forensic memory evidence)
4. Activate backup restoration procedure (this roadmap, lesson 6) —
   verify backups are clean before restoring
5. Do not engage with ransom demands without leadership + legal involvement

Different scenarios genuinely require different first actions — the right first move for a suspected data breach (preserve evidence, assess what data was accessed) differs meaningfully from the right first move for active ransomware (isolate immediately to stop spread). A generic playbook risks the team wasting critical early minutes figuring out which of these applies before anyone can act.

Tabletop exercises: testing without a real incident

This roadmap's operational security lesson made the point that an untested backup is an unverified assumption. The exact same logic applies to an incident response plan: a plan that has never been exercised is untested, no matter how well-written it looks on paper. A tabletop exercise — walking through a realistic scenario as a team, out loud, without actually triggering real systems — reliably surfaces gaps: roles that were assumed but never actually assigned to a specific person, contact information that's out of date, a decision point no one had actually thought through (e.g., "who has the authority to decide whether we pay a ransom?").

A reasonable cadence is at least annual, ideally covering a different scenario each time, with findings from each exercise feeding back into plan updates — not run once for the sake of a certification checkbox and then never repeated.

Evidence collection and chain of custody

During a real incident, evidence collected (logs, memory dumps, disk images) may later matter for legal action, insurance claims, or regulatory reporting. Basic chain-of-custody discipline — documenting who collected what, when, and how it was subsequently handled — preserves the evidence's credibility. Evidence collected without this discipline can become unusable later precisely when it's needed most, echoing Foundation's control 5.28.

Post-incident review closes the loop

After any real incident (or significant tabletop exercise), a post-incident review should determine root cause (Foundation, clause 10.2's correction-vs-corrective-action distinction, applied at incident scale) and specifically feed findings back into the risk register (this roadmap, lesson 3) — a real incident is itself powerful evidence for updating likelihood and impact estimates on previously assessed risks, and sometimes reveals a risk that was never identified at all.