Incident Post-Mortem Report Template

This Incident Post-Mortem Report (the “Report”) is created by [Company Name] on [Report Date].

1. Incident Overview

1.1 Incident ID. [Incident ID].
1.2 Incident Title. [Short descriptive title].
1.3 Severity Level. ☐ SEV-1 (Critical) ☐ SEV-2 (High) ☐ SEV-3 (Moderate) ☐ SEV-4 (Low).
1.4 Incident Type.
☐ Security incident ☐ Data breach ☐ Ransomware ☐ Outage ☐ Fraud ☐ Other: [Type]
1.5 Dates.

• Detected: [Date/Time]

• Contained: [Date/Time]

• Resolved: [Date/Time]
  1.6 Prepared By. [Name/Role].
  1.7 Reviewed By. [Names/Roles].

2. Executive Summary

2.1 Summary. [2–5 sentences describing what happened in plain language].
2.2 Customer/Business Impact. [What users experienced and business effect].
2.3 Scope. [Systems, data types, and boundaries].
2.4 Current Status. ☐ Resolved ☐ Monitoring ☐ Ongoing remediation.

3. Impact Assessment

3.1 Systems Impacted. [List systems/services].
3.2 Duration. [Total downtime or incident window].
3.3 Data Impact (If Any). [Data types affected, number of records, encryption status].
3.4 Financial/Operational Impact. [Costs, revenue impact, SLA credits, overtime].
3.5 Reputational/Legal Impact (If Any). [Customer notices, regulator involvement, contract impact].
3.6 Users/Customers Affected. [Count/segments].

4. Timeline

4.1 Timeline of Events.

• [Time] – [Event]

• [Time] – [Event]

• [Time] – [Event]

• [Time] – [Event]
  4.2 Detection Sources. [Alerts, reports, tickets, logs].
  4.3 Key Decisions. [Decisions made and why].

5. Root Cause Analysis

5.1 Primary Root Cause. [Technical/process cause].
5.2 Contributing Factors. [Misconfigurations, missing controls, training gaps].
5.3 Why It Was Not Prevented. [What control failed or was missing].
5.4 Why It Was Not Detected Earlier. [Monitoring gaps, alert fatigue].
5.5 Corrective Actions Taken During Incident. [Immediate fixes].

6. Response Review

6.1 What Went Well.

• [Item]

• [Item]
  6.2 What Didn’t Go Well.

• [Item]

• [Item]
  6.3 Where We Got Lucky (Optional). [External factors that reduced impact].
  6.4 Process Deviations. [Playbook steps missed or unclear].

7. Remediation Plan (Action Items)

7.1 Action Items.

• Action: [Fix] | Owner: [Name] | Due: [Date] | Priority: ☐ High ☐ Medium ☐ Low

• Action: [Fix] | Owner: [Name] | Due: [Date] | Priority: ☐ High ☐ Medium ☐ Low

• Action: [Fix] | Owner: [Name] | Due: [Date] | Priority: ☐ High ☐ Medium ☐ Low
  7.2 Validation. How we will confirm fixes worked: [Testing/monitoring/audit].
  7.3 Long-Term Improvements. [Architecture or process changes].
  7.4 Training/Documentation Updates. [What will be updated and when].

8. Communications Summary

8.1 Internal Communications. [Who was notified and when].
8.2 External Communications. [Customers/regulators/partners and timeline].
8.3 Public Statements. ☐ None ☐ Issued (attach).
8.4 Support Readiness. [Support macros/FAQ used].

9. Evidence and Attachments

9.1 Evidence References. [Links to logs, tickets, forensics reports].
9.2 Attachment List. [Screenshots, exports, vendor notices].
9.3 Storage Location. [Secure folder], access restricted to: [Roles].

10. Approvals

10.1 Security/IT Review. [Name/Title] – Date: [Date].
10.2 Legal/Privacy Review (If Applicable). [Name/Title] – Date: [Date].
10.3 Executive Approval (If Required). [Name/Title] – Date: [Date].

Signatures

By signing below, the undersigned acknowledge that this Report is a record of the incident and the remediation plan as of the signature date.

Prepared By: [Name]
Title/Role: [Title]
Date: [Date]
Signature: ___________________________

Reviewed By: [Name]
Title/Role: [Title]
Date: [Date]
Signature: ___________________________

Approved By (Optional): [Name]
Title/Role: [Title]
Date: [Date]
Signature: ___________________________