Overview
After the firefighting is over, the real work begins. A well-structured post-mortem turns every security incident into a learning opportunity that strengthens your defenses. This template walks you through documenting the incident timeline, identifying root causes, measuring business impact, and defining corrective actions that actually get implemented. The goal is not to assign blame but to build resilience.
Post-Mortem Sections
- Executive summary and incident classification
- Detailed timeline with timestamps and key decisions
- Root cause analysis (primary and contributing factors)
- Impact assessment: data, systems, customers, and financial
- Detection and response effectiveness review
- Corrective actions with owners and deadlines
- Lessons learned and process improvements
- Appendices: evidence logs, communication records, IOCs
Root Cause Analysis Methods
| Method | Best for | Approach |
|---|---|---|
| 5 Whys | Simple, single-cause incidents | Ask "why" iteratively until you reach the root cause |
| Fishbone (Ishikawa) | Complex incidents with multiple contributing factors | Categorize causes across people, process, technology, and environment |
| Fault Tree Analysis | High-severity incidents requiring formal analysis | Map failure paths in a logical tree structure |
| Timeline Analysis | Incidents with unclear sequence of events | Plot every action and event chronologically to identify gaps |
Writing the Timeline
The timeline is the backbone of any good post-mortem. Start from the earliest indicator of compromise, not from when the alert fired. Include every significant event: initial access, lateral movement, detection, triage decisions, containment actions, communications sent, and full recovery. Use UTC timestamps throughout for consistency. Note where there were delays and why. Were analysts waiting for approvals? Did detection take too long? The timeline should tell the story of both the attack and the response.
Impact Assessment Framework
Quantify the impact across multiple dimensions. How many records were exposed? Which systems were offline and for how long? Were customers directly affected? What was the financial cost including incident response fees, legal expenses, and lost revenue? Document regulatory implications: was this a reportable breach under GDPR, HIPAA, or state breach notification laws? Include reputational impact where measurable. The impact section is what leadership and the board care about most.
Corrective Actions That Stick
Every post-mortem produces a list of action items, but the ones that matter have three things: a clear owner, a realistic deadline, and a verification step. Assign each action to a specific person, not a team. Set deadlines within 30, 60, or 90 days depending on complexity. Schedule follow-up reviews to confirm implementation. Track completion rates across all post-mortems to identify systemic issues like chronic underinvestment in detection or repeated access control failures.
Frequently Asked Questions
When should the post-mortem be completed after an incident?
Within two weeks of incident closure for critical incidents and within 30 days for lower-severity events. The longer you wait, the more details are lost and the less actionable the findings become.
Who should participate in the post-mortem review?
Everyone involved in the incident response, plus representatives from teams that own the affected systems. Include a facilitator who was not directly involved to ensure objectivity. Legal and compliance should review the final document.
How do we keep post-mortems blameless?
Focus on systems and processes, not individuals. Ask "what failed" rather than "who failed." Establish a culture where surfacing issues is rewarded. Document decisions that were reasonable given the information available at the time.
Should post-mortem reports be shared externally?
Internal post-mortems should be treated as confidential. If regulatory notification requires a root cause summary, work with legal to prepare a version that meets disclosure requirements without exposing sensitive details about your security posture.
How do we track whether corrective actions are actually completed?
Use a centralized tracking system like Jira or your GRC platform. Assign each action a ticket with an owner and deadline. Review open actions in monthly security steering committee meetings. Report completion rates quarterly to leadership.
Ready to use this resource?
Download it now or schedule a demo to see how Hunto AI can automate your security workflows.