Incident Post-Mortem Report Template

Typical length: 4-6 pages
AI Assisted
Export: PDF & DOCX
Multi-jurisdiction ready

Get your custom agreement in minutes Create Agreement

4.8 Rating Downloaded 4949 times

Google For Startups NVIDIA Inception Program

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].

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].

[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].

[Item]

6.2 What Didn’t Go Well.

[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].

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

Download Free Template

Get your complete
agreement in minutes

Select a template

Each template already follows legal structure and best practices.

Provide details

The agreement is automatically filled and adapted to your inputs.

Review & download

Check the generated document, make edits if needed, and download a ready-to-use agreement.

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.

Learn more

Frequently asked

Incident Post-Mortem Report Template — quick answers

Reviewed July 2026 Free download, PDF & DOCX

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