Topics in this domain
- Event vs Incident vs Breach
- Developing the Incident Response Plan
- Incident Response Team Roles and Authority
- Incident Classification and Severity Levels
- Incident Response Playbooks and Decision Trees
- Escalation and Communication Plans
- Business Impact Analysis
- RTO, RPO, MTD and Recovery Prioritisation
- Business Continuity Planning and Strategies
- Crisis Management and Continuity Governance
- Disaster Recovery Planning
- Recovery Sites: Hot, Warm and Cold
- Backup Strategies and Cloud DR
- Incident Response Training
- Testing Plans: Tabletop, Functional and Full Interruption
- Evaluating Exercises and Improving Readiness
- Security Event Detection and Monitoring Methods
- SIEM, the SOC and Event Correlation
- Threat Intelligence and Indicators of Compromise
- Incident Triage and Initial Investigation
- Evidence Preservation, Forensics and Chain of Custody
- Containment Strategies: Short-Term and Long-Term
- Making Containment Decisions
- Breach Notification and Regulatory Reporting
- External Communications: Customers, Media and Law Enforcement
- Eradication, Recovery and Return to Normal Operations
- Post-Incident Review and Root Cause Analysis
- Lessons Learned and Incident Trend Analysis
Post-Incident Review and Root Cause Analysis
Don’t waste the incident
Every incident is expensive. The post-incident review (PIR) is how the organisation gets something back: an honest look at what happened, why, and what will change so it doesn’t happen again, or is caught sooner next time. One CISM task is to conduct post-incident reviews covering root-cause analysis, lessons learned, corrective actions and risk reassessment.
The review
- Timeline: what happened, when, and what was done.
- Root cause: why did it happen? Why wasn’t it stopped, or seen, sooner?
- What worked: keep doing it.
- What didn’t: the plan, tools, people, decisions.
- Corrective actions: each with an owner and due date, tracked to closure.
- Reassess risk: update the risk register, plans and playbooks.
Finding the root cause
Techniques include the five whys (keep asking why until you reach something fixable), fishbone (Ishikawa) diagrams and timeline analysis. Don’t stop at the immediate cause:
| Level | Example |
|---|---|
| Immediate cause | An employee clicked a phishing link |
| Contributing causes | No MFA on the VPN; an alert was ignored overnight |
| Root cause | No MFA standard enforced; the SOC isn’t staffed 24x7 |
| Corrective actions | Enforce MFA (IT, 30 days); MDR service for nights (CISO, 60 days) |
Running it well
- Timing: soon after closure, while memories are fresh, often within two weeks.
- Participants: responders, owners, legal, communications, and sometimes the supplier involved.
- Blameless: focus on process and systems, not individuals, so people speak honestly.
- Output: a report to management, tracked actions and updated risk.
Example. A review of a ransomware attack finds the entry point was an unpatched VPN appliance flagged three months earlier. The root cause isn’t the patch team: the critical-patch SLA didn’t cover network appliances. The standard is updated, and appliances join the vulnerability program.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Main purpose of a post-incident review | Identify root causes and improvements |
| A technique for root cause analysis | Five whys or a fishbone diagram |
| Corrective actions need… | Owners, due dates and tracking |
| The right culture for reviews | Blameless, focused on process |
| What else to update after a review | Risk register, plans, playbooks and controls |
In short
- Post-incident review practices are a named CISM topic; a CISM task is to conduct reviews covering root cause, lessons learned, corrective actions and risk reassessment.
- The review reconstructs the timeline, identifies root and contributing causes, and asks what worked and what didn't.
- Root cause analysis techniques: five whys, fishbone (Ishikawa) diagrams, timeline analysis.
- Corrective actions have owners and due dates, and are tracked to closure like risks.
- The risk register, plans, playbooks and controls are updated; results are reported to management.
- Reviews are blameless, focusing on process, so people speak honestly.
Exam traps
- Skipping the review means the same incident can happen again.
- Stopping at the immediate cause (the phishing click) misses the root cause (no MFA, weak detection).
- Blame-focused reviews make people hide information.
- Actions without owners and dates rarely get done.
Slides
Click the slide and use the arrow keys. F toggles full screen.
The review
Finding the root cause
1 / 9