Related guides:
Key takeaways
- A postmortem turns an incident into durable improvements with a timeline, root cause, and tracked actions.
- This workbook covers 5 Whys analysis, contributing factors, six-dimension impact assessment, and a P1/P2/P3 action tracker.
- Run postmortems for SEV-1 and SEV-2 events within 5 business days of resolution.
- SecureSlate helps link corrective actions to controls and evidence.
Overview
Auditors and customers want to see that incidents lead to real change, not just a Slack thread that fades. A structured postmortem documents what happened, why, and what you fixed.
What makes it useful
- Incident summary: ID, title, detection and resolution times, duration, and severity.
- Chronological timeline: Timestamped events with systems, people, and evidence sources.
- Root cause analysis: 5 Whys plus contributing factors across technical, process, people, and third-party dimensions.
- Impact assessment: Customer, data, financial, reputational, operational, and regulatory impact.
- Corrective actions: Priority-coded tracker with owners, due dates, and status.
Download the template
Complete within 5 business days while details are fresh. Share a blameless draft with participants before finalizing.
Tab-by-tab walkthrough
Overview and Version & Approval
Document control and sign-off. Link to the parent incident ticket.
Incident Summary
Fill Incident ID, title, severity, detection time, resolution time, and total duration. One-paragraph executive summary of what happened and customer impact.
Timeline
Row per event: UTC timestamp, event type (Detection, Escalation, Containment, Communication, Eradication, Recovery), description, systems involved, and source (SIEM, ticket, Slack). Pull from your IR war room channel and ticketing system.
Root Cause Analysis
Document contributing factors in four buckets, then work through 5 Whys to reach the root cause. Avoid stopping at "human error" without systemic fixes.
Impact Assessment
Score impact across six dimensions with estimated cost where possible. Supports breach notification and insurance discussions.
Corrective Actions
Log every action with Priority (P1 Critical, P2 High, P3 Medium), Category, Owner, Due Date, Status, and evidence link. P1 items should close within 30 days.
How to use it as audit evidence
| Auditor question | Where to answer |
|---|---|
| Did you analyze the incident? | Root Cause Analysis tab |
| What was the blast radius? | Impact Assessment tab |
| What did you fix? | Corrective Actions with closed tickets |
| Was response timely? | Timeline with timestamps |
Store finalized postmortems in your evidence library and reference them in your IR plan lessons learned log.
Common mistakes
- Timeline built from memory instead of log exports
- Root cause stops at a person instead of a control gap
- Corrective actions with no owner or due date
- Postmortem completed but actions never verified in the next audit period
When to hold a postmortem
Not every alert needs a full review. Set clear triggers so the decision is not made case by case under pressure. A postmortem is usually required for:
- Any security incident involving customer data or credentials
- Any outage that breached an SLA or lasted longer than your RTO
- Any incident rated SEV-1 or SEV-2 in your incident response plan
- Any event that needed customer, regulator or insurer notification
- Near misses that would have been serious if one more control had failed
For smaller incidents, a short write-up in the ticket is enough, as long as corrective actions are still tracked.
Running the postmortem meeting
- Prepare a draft first. The incident lead fills in the
Incident SummaryandTimelinetabs from logs, alerts and the incident channel before the meeting. Do not build the timeline from memory in the room. - Invite the right people. Everyone who responded, the service owner, and someone from support or customer success who heard from customers. Keep it under ten people.
- Set the tone. Open by stating the meeting is blameless: the goal is to understand how the system allowed the incident, not who made a mistake.
- Walk the timeline. Go through it event by event. Ask what each person knew at that moment and why the next step made sense to them.
- Find the root cause. Use 5 Whys in the
Root Cause Analysistab. Keep asking until you reach a control, process or design gap you can fix. - Agree corrective actions. Each action needs an owner, a due date and a way to verify it is done.
- Publish. Share the final document with the wider team within five business days.
A 60-minute meeting is enough for most incidents if the draft is ready beforehand.
Writing good corrective actions
Weak actions are the most common reason the same incident happens twice. Compare:
| Weak action | Strong action |
|---|---|
| Be more careful when deploying | Add an automated check that blocks deploys without a passing database migration test |
| Improve monitoring | Add an alert when API error rate exceeds 2% for 5 minutes, routed to the on-call engineer |
| Remind staff about phishing | Enforce phishing-resistant MFA for all admin accounts by the end of the quarter |
| Review access | Remove standing production access and require just-in-time approval for database access |
A strong action changes a system or a control, has a clear finish line and can be checked by someone else. Close each action with a link to the ticket, pull request or configuration change as evidence.
Sharing lessons learned
The value of a postmortem grows when other teams learn from it. Keep a short "lessons learned" log that lists each incident, its root cause in one sentence and the main fix. Review the log quarterly to spot patterns, such as several incidents caused by the same vendor or the same missing alert. For customer-facing incidents, a short public summary on your status page or trust center builds confidence, as long as it does not expose details that could help an attacker.
How SecureSlate helps
SecureSlate tracks remediation tasks, maps them to controls, and keeps post-incident evidence organized for audits and customer reviews.
FAQ
Which incidents need a postmortem?
At minimum all SEV-1 and SEV-2 events, plus the other triggers listed under when to hold a postmortem, such as incidents involving customer data or an SLA breach. Many teams also postmortem near-misses that could have been SEV-1.
Should postmortems be blameless?
Yes. A blameless review focuses on how processes, tools and controls allowed the incident, rather than on blaming individuals. People share more honestly when they are not afraid of punishment, which leads to better fixes. HR matters are handled separately.
How long should corrective actions take?
P1 within 30 days, P2 within 60 days, P3 within 90 days. Adjust based on risk.
Who should write the postmortem?
The incident lead or the owner of the affected service usually writes the draft. It is then reviewed by everyone who took part in the response before it is finalized.
Do auditors ask for postmortems?
Yes. SOC 2 and ISO 27001 auditors commonly sample incidents from the audit period and ask to see the analysis, the corrective actions and evidence that the actions were completed.
Disclaimer (legal note)
This article is for general information only and is not legal, regulatory, or professional advice. Requirements vary by framework, industry, and jurisdiction. Consult qualified advisors for your specific obligations.
Need compliance without the complexity?
SecureSlate automates ISO 27001, SOC 2, GDPR, HIPAA, and more. Built for growing teams. See it in action.
Find compliance gaps in 30 seconds
