Free template

Incident Post-Mortem Report Template

Capture lessons learned and prevention steps after an incident with this Incident Post-Mortem Report Template.

Downloaded 3528 times

Incident Post-Mortem Report Template

Download template

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: ___________________________

Flash deal

Flash deal

Today

Today

No time to fill it up? Generate your custom agreement with AI Lawyer in seconds

What’s Included

Legal Research

Legal Research

Legal Research

Contract Drafting

Contract Drafting

Contract Drafting

Document Review

Document Review

Document Review

Risk Analytics

Risk Analytics

Risk Analytics

Citation Verification

Citation Verification

Citation Verification

Easy-to-understand jargon

Easy-to-understand jargon

Easy-to-understand jargon

Details

Learn more about

Incident Post-Mortem Report Template

Click below for detailed info on the template.
For quick answers, scroll below to see the FAQ.

Click below for detailed info on the template.
For quick answers, scroll below to see the FAQ.

INCIDENT POST-MORTEM REPORT TEMPLATE FAQ


What is an incident post-mortem report?

An incident post-mortem report is a structured document created after an incident is resolved. It records what happened, how the team responded, what impact occurred, the root cause, and what changes will be made to reduce the risk of повторення. It also creates accountability by assigning owners and deadlines for follow-up actions.


When should you write a post-mortem report?

Write it after the incident is contained and systems are stable, usually within a few days. For major incidents (SEV-1/SEV-2), teams often schedule a formal post-incident review meeting and produce a written report shortly after.


What should be included in a post-mortem?

A good post-mortem includes: a high-level summary, incident severity and impact, a clear timeline, detection and response actions, root cause analysis, contributing factors, what went well, what didn’t, and a concrete remediation plan with owners and due dates.


How detailed should the timeline be?

It should be detailed enough to show key decisions and events (detection, containment, customer impact, recovery). Include timestamps and sources (alerts, logs, tickets) when available, but avoid unnecessary sensitive details if the report may be shared broadly.


Should a post-mortem be blame-focused?

No. The goal is to improve systems and processes, not to blame individuals. Focus on fixes: monitoring, access controls, patching, playbooks, training, and operational readiness.


What is AI Lawyer?

AI Lawyer is an AI-powered assistant that helps you create and customize legal and business document templates online. It guides you through key sections, suggests wording, and explains complex concepts in simple language. AI Lawyer does not replace a licensed attorney or provide legal advice, but helps you prepare better documents faster and more confidently.

Similar templates

Other templates from

Policy and Compliance Documents

Money back guarantee

Free trial

Cancel anytime

AI Lawyer protects

your rights and wallet

🌐

Company

Learn

Terms

©2025 AI Lawtech Sp. z O.O. All rights reserved.

Money back guarantee

Free trial

Cancel anytime

AI Lawyer protects

your rights and wallet

🌐

Company

Learn

Terms

©2025 AI Lawtech Sp. z O.O. All rights reserved.

Money back guarantee

Free trial

Cancel anytime

AI Lawyer protects

your rights and wallet

🌐

Company

Learn

Terms

AI Lawtech Sp. z O.O.

©2025

Money back guarantee

Free trial

Cancel anytime

AI Lawyer protects

your rights and wallet

🌐

Company

Learn

Terms

©2025 AI Lawtech Sp. z O.O. All rights reserved.