Post-Incident Reviews

Purpose and Scope

Post-incident reviews (also called retrospectives or lessons learned) extract value from security incidents by identifying what worked, what did not, and how to improve. This playbook covers running effective reviews and turning findings into measurable improvements.

Prerequisites

• Incident closed: Recovery complete and situation stable
• Documentation: Incident timeline, response actions, and decisions recorded
• Participant availability: Key responders and stakeholders able to attend
• Blameless culture: Focus on process improvement, not individual blame

When to Conduct Reviews

Run a post-incident review for:

• All significant security incidents
• Near misses that could have been significant
• Incidents with novel attack techniques
• Cases where response took longer than expected
• Situations with unclear detection or response gaps
• Any incident the team wants to learn from

Timing

• Hold the review within 1 to 2 weeks of incident closure
• Too soon: participants are still in response mode
• Too late: details are forgotten
• Allow 60 to 90 minutes for significant incidents
• Shorter reviews (30 minutes) work for minor incidents

Participants

Include people who:

• Detected the incident
• Responded and performed investigation
• Made containment and eradication decisions
• Communicated with stakeholders
• Own affected systems or processes
• Can implement recommended improvements

Optional: external parties, management sponsors, or security leadership.

Facilitation Approach

Set the Tone

• Emphasize blameless analysis
• Focus on systems and processes, not individuals
• Encourage honest discussion of what went wrong
• Thank participants for their response efforts

Review Structure

1. Incident summary: Brief overview of what happened (5 minutes)
2. Timeline walkthrough: Review key events chronologically (15 minutes)
3. What went well: Identify effective actions and processes (10 minutes)
4. What could improve: Discuss gaps and challenges (20 minutes)
5. Root cause analysis: Dig into underlying causes (15 minutes)
6. Action items: Define specific improvements (15 minutes)

Key Questions to Ask

Detection

• How was the incident detected?
• How long was the attacker present before detection?
• Did existing alerts fire? Why or why not?
• What would have detected this sooner?

Response

• How quickly did we respond after detection?
• Did we have the right tools and access?
• Were playbooks and procedures followed?
• Where did we get stuck or slow down?

Communication

• Were the right people notified promptly?
• Was communication clear and effective?
• Did stakeholders get the information they needed?
• Were there any communication breakdowns?

Process and Tools

• Did our tools work as expected?
• Were there gaps in visibility or capability?
• Did processes help or hinder the response?
• What documentation was missing or outdated?

Root Cause Analysis

Go beyond the immediate cause to find underlying issues:

Five Whys Technique

Ask "why" repeatedly to get to root causes:

• Why was the account compromised? Weak password.
• Why was a weak password allowed? No password policy enforcement.
• Why no enforcement? Legacy system does not support it.
• Why is the legacy system still in use? No migration plan.
• Why no migration plan? Not prioritized.

Contributing Factor Categories

• Process: Missing, unclear, or not followed procedures
• Technology: Tool gaps, misconfigurations, or limitations
• People: Training gaps, staffing issues, fatigue
• Environment: External factors, vendor issues, threat landscape

Defining Action Items

Good action items are:

• Specific: Clear description of what needs to be done
• Assigned: Single owner responsible for completion
• Time-bound: Target completion date
• Measurable: Clear criteria for completion
• Realistic: Achievable with available resources

Prioritizing Improvements

Categorize by impact and effort:

• Quick wins: Low effort, high impact. Do first.
• Strategic projects: High effort, high impact. Plan and resource.
• Incremental: Low effort, low impact. Do when convenient.
• Deprioritize: High effort, low impact. Avoid or defer.

Documentation

Create a post-incident review report including:

• Incident summary and timeline
• Impact assessment
• What went well
• Areas for improvement
• Root cause analysis findings
• Action items with owners and due dates
• Metrics (time to detect, time to contain, time to resolve)

Tracking Improvements

• Enter action items into a tracking system
• Review progress in regular team meetings
• Close items only when verified complete
• Track completion rate and time to implement
• Report on improvement trends to leadership

Building a Learning Culture

• Share sanitized findings across the organization
• Celebrate improvements that prevent future incidents
• Reference past incidents when similar situations occur
• Build a knowledge base of lessons learned
• Include improvement metrics in SOC performance reviews

Common Pitfalls

• Blame culture: People will not share honestly if they fear punishment
• Action item graveyard: Items assigned but never completed
• Shallow analysis: Stopping at symptoms instead of root causes
• Missing participants: Key perspectives not included
• Delayed reviews: Waiting too long after incidents
• No follow-through: Not tracking or verifying improvements

References

• NIST SP 800-61: Computer Security Incident Handling Guide
• Google SRE Book: Postmortem Culture
• Etsy Debriefing Facilitation Guide
• SANS Incident Handler's Handbook