Post-Incident Activity and Continuous Improvement
Purpose
Post-incident activity converts a costly event into durable improvement. It is a phase output, not an optional debrief.
What must happen
- Lessons learned meeting: NIST guidance points to holding it within about two weeks, while memory is fresh. Attendees include handlers, system owners, and business and legal stakeholders.
- Root cause analysis: techniques such as the 5 Whys and fishbone diagrams separate the triggering event from the underlying control failure.
- After-action report: timeline, what worked, what failed, root cause, and corrective actions.
- Corrective actions must have an owner, a due date, and a verification step; otherwise they quietly disappear.
- Metrics: mean time to detect, acknowledge, contain, and recover, plus dwell time and alert volume per analyst. Metrics should inform decisions, not become the goal.
- Feedback into preparation: update playbooks, detection rules, logging coverage, and training; adjust the risk register.
- Records: retain evidence and reports per policy and legal obligation, and destroy on schedule.
Traps
Blame-oriented meetings, which suppress the honesty the review depends on. Tracking only mean time to recover while ignoring detection performance. Corrective actions with no owner or date. Skipping the review because the incident was "minor." Keeping evidence forever, or discarding it before legal obligations expire.
Rule of thumb
Every incident should yield at least one detection or prevention improvement and one tracked action with a named owner and a date. If nothing changed, the review did not happen.