Post-Incident Activity and Lessons Learned
This domain tests whether you can convert an incident into durable improvement - and prove it. Questions focus on timing, participants, metrics, and what a defensible lessons-learned process produces.
The lessons-learned meeting
- Hold it soon after recovery, while memory is fresh; NIST guidance suggests within roughly two weeks of the incident ending, and sooner for short incidents.
- Include responders, system owners, business representatives, communications, and legal. A facilitator who was not the lead handler keeps the discussion honest.
- Structure it: what happened (timeline), what worked, what failed, root cause, and corrective actions with owners and due dates.
- Keep it blameless in tone but factual - the goal is fixing systems, not protecting reputations. The written report can still record decisions and accountability.
Metrics worth reporting
Track time to detect, time to acknowledge or triage, time to contain, time to recover, and dwell time, plus number of affected assets and cost. Trend them across incidents; one number proves nothing, a rising or falling trend informs investment.
Outputs
- An incident report: executive summary, timeline, root cause, impact, actions taken, and recommendations.
- A tracked action register with owners and dates. Untracked recommendations are the classic failure.
- Updates to playbooks, detection rules, asset inventories, and training.
- Retention of evidence and records in line with legal, contractual, and regulatory requirements - decide retention before you delete.
Worked example
A phishing-led compromise took four days to detect. Detection time, not containment, dominates the metric. The lessons-learned meeting produces three actions: deploy DMARC enforcement (owner: email team, 30 days), add a detection rule for the observed mailbox-rule persistence (owner: SOC, 14 days), and add the scenario to the next tabletop (owner: IR lead, 90 days). Each is dated and reviewed monthly. That specificity is what separates a passing answer from a vague one.
Traps
- Skipping the review because the team is exhausted - schedule it before recovery finishes.
- Producing recommendations with no owner, date, or follow-up mechanism.
- Personal blame that suppresses honest reporting next time.
- Deleting case data before checking retention obligations.
- Reporting only that the incident is closed, with no measured outcome.