Post-Incident Review and Root Cause Analysis Template

Most organisations close an incident once service is restored, and the same weakness causes the next one. A post-incident review (PIR, also called a postmortem) turns an incident into durable fixes, but only if it is triggered consistently, finds systemic causes rather than a person to blame, and tracks its actions to closure. This template gives you a policy and a review format you can adopt as-is: when a review is mandatory, who runs it, how root cause analysis is done, what the report contains and how actions are governed. It follows NIST SP 800-61 Rev. 3, which places lessons learned in the CSF 2.0 Improvement category, and the blameless postmortem practice described in Google's SRE book. It is written for incident managers, SOC leads, engineering managers and the executives who sponsor the actions.

How to use this template

Replace text in square brackets, such as [Organisation], [Incident Manager] and [X working days], with your own terms and thresholds.
"Must" is a mandatory requirement; "should" is a recommended practice where a documented exception may be justified.
Use it with your incident response plan, not instead of it. Section 4 assumes incidents are already declared and classified by severity. See the Incident Response Plan Template.
The report structure in 4.4 works for security incidents and for operational outages. Keep one process so lessons from both reach the same backlog.
Review this policy at least annually and after any incident where the review process itself failed.

1. Purpose

This policy sets the requirements for reviewing incidents at [Organisation] so that the underlying causes are found, improvements are agreed and implemented, and lessons are shared. Reviews are blameless: their purpose is to improve systems, processes and controls, not to judge individuals. The policy supports the NIST CSF 2.0 outcomes RS.AN-03 (analysis establishes what took place and the root cause) and ID.IM-03 (improvements identified from executing processes, including incident response).

2. Scope

This policy applies to:

All security incidents declared under [Incident Response Plan], including incidents involving third parties, cloud providers and suppliers.
Operational incidents and outages that meet the triggers in 4.1, including failed changes and expired certificates.
Near misses and exercises where [Security Operations Manager] or a service owner requests a review.
All employees, contractors and managed service providers who took part in, or own systems affected by, an incident.

Disciplinary matters, HR investigations and legal privilege decisions are out of scope and follow [HR and Legal procedures]. Where a review uncovers deliberate misconduct, the facilitator pauses the review and refers the matter (see 5).

3. Roles and responsibilities

Role	Responsibility in the review
[Review Sponsor] (e.g. CISO or CIO)	Owns this policy, approves Severity 1 reports, funds actions and arbitrates disputed priorities.
[Incident Manager]	Ensures the review is scheduled, preserves the incident record and hands the timeline to the facilitator.
Review facilitator	Someone not directly involved in the response. Runs the meeting, enforces blameless language, leads root cause analysis and drafts the report.
Responders and service owners	Contribute facts, logs and context; review the draft for accuracy.
Action owners	Named individuals who deliver each corrective action by its due date or request a change through the action register.
[Legal and Privacy]	Advise on privilege, regulatory notification facts and redaction before wider sharing.
[Risk and Compliance]	Record accepted residual risk and track overdue actions in the risk register.

4. Policy statements

4.1 When a review is required

A review must be held when any of the following occur. The triggers are set in advance so that the decision is not made under pressure after the event, a practice the Google SRE book recommends.

Any security incident of [Severity 1 or 2], any confirmed data breach, or any incident that required regulatory or customer notification.
Compromise of a privileged account, service account, API key, OAuth token or other non-human identity.
Customer-visible downtime or degradation above [X minutes] or any data loss.
Detection by a third party, customer or researcher rather than by [Organisation]'s own monitoring.
Time to contain above [X hours] for the severity level.
A repeat of a cause identified in a previous review within [12 months].

Any stakeholder may request a review of an incident below these thresholds.

4.2 Timing and evidence

A review meeting must be held within [5 working days] of the incident being closed, or of containment for long-running incidents. A draft report must follow within [10 working days].
Lessons that reduce ongoing risk must be shared as soon as they are identified, not held until the report is final. NIST SP 800-61 Rev. 3 makes the same recommendation.
The incident record, chat channels, tickets, alerts and log exports must be preserved before the review. Records must be access-controlled and their integrity protected (CSF 2.0 RS.AN-06 and RS.AN-07). Where prosecution or litigation is possible, [Legal] decides whether formal chain of custody applies.

4.3 Blameless conduct

Reviews must assume that every person acted in good faith on the information available to them at the time.
Reports must describe actions and decisions, not individuals' failings. "The on-call engineer approved the change" is acceptable; "the engineer was careless" is not.
"Human error" must not be recorded as a root cause. The review must ask what made the error possible and what would have caught it.
Participation in a review must never be used as evidence in performance management.

4.4 Report contents

Every review report must contain the sections below. Severity 3 reviews may use a short form of sections 1, 4, 6 and 7.

#	Section	What to record
1	Summary	Three to five sentences: what happened, impact, how it ended, top action.
2	Impact	Users, customers, records, systems and identities affected; duration; financial and regulatory impact; notifications made.
3	Timeline	UTC timestamps for first malicious or faulty event, detection, declaration, containment, eradication and recovery, with the source of each timestamp.
4	Detection and response analysis	How it was detected, what alerted and what should have. Which runbooks were used and whether they worked.
5	What went well	Practices to keep and spread.
6	Root and contributing causes	Output of the analysis in 4.5, separating technical, process and organisational causes.
7	Corrective and preventive actions	Each with owner, priority, due date, ticket reference and the cause it addresses.
8	Framework and ATT&CK mapping	For security incidents, the MITRE ATT&CK techniques observed and the controls that failed or held.
9	Open questions	What is still unknown and how it will be resolved.

4.5 Root cause analysis

The review must look for underlying and systemic causes, not only the trigger, in line with NIST SP 800-61 Rev. 3 under RS.AN-03 (establish the sequence of events and assets involved, identify vulnerabilities and threats, then analyse for root causes). The facilitator must use at least one structured method:

Method	How it works	Best for	Watch out for
5 whys	Ask "why" repeatedly from the problem statement until a cause is reached that a process or control change can fix.	Single-thread incidents, Severity 3 reviews.	Stops at one chain; drifts to a person. Run it once per contributing factor.
Fishbone (Ishikawa) diagram	Group candidate causes under headings such as people, process, technology, environment, suppliers and measurement, then test each against the evidence.	Incidents with several interacting causes.	Lists of possible causes recorded as confirmed ones.
Timeline and control gap analysis	For each step of the attack or failure, record which preventive or detective control should have stopped or seen it, and why it did not.	Security incidents mapped to ATT&CK.	Ignoring controls that worked, which are equally useful evidence.
Change analysis	Compare the failed state with the last known good state and list every difference.	Outages after changes or deployments.	Missing slow drift such as expired certificates or stale credentials.

Where the root cause cannot be established, the report must say so plainly and record the hypotheses tested. The Cyber Safety Review Board's review of the Summer 2023 Microsoft Exchange Online intrusion is a useful model: it states that how the signing key was obtained had not been determined, and it criticised a public statement naming a probable cause that was not corrected for months. See the Microsoft Storm-0558 key breach analysis.

4.6 Corrective actions

Every root and contributing cause must have at least one action, or a recorded risk acceptance by the [Review Sponsor].
Actions must be specific and testable ("alert on use of signing keys older than [X] days"), not general ("improve monitoring").
Priority targets: [P1 within 30 days], [P2 within 90 days], [P3 within 180 days]. Overdue P1 actions are escalated to the [Review Sponsor] and entered in the risk register.
An action is closed only when its owner provides evidence that the change is live, such as a test result, a detection firing in a test or a configuration export.

4.7 Approval and sharing

The draft is reviewed by participants for accuracy, then by [a senior reviewer] for depth of cause analysis and quality of actions before approval.
Approved reports are stored in [the review repository] and a redacted summary is shared with [engineering, SOC and risk teams]. Personal data and customer data must be removed before wider sharing.
Where third parties were involved, shareable findings are passed to them through [Supplier Manager] (CSF 2.0 RS.CO-03).

5. Exceptions

Exceptions to timing or format must be approved by the [Review Sponsor] and recorded with a reason and a new date. A review must not be cancelled because the incident was small or the cause seems obvious; use the short form instead. Where [Legal] places a review under privilege, the review still takes place in the agreed format and a non-privileged lessons summary is produced. If evidence of deliberate misconduct emerges, the facilitator pauses that thread and refers it under [HR procedure]; the systemic review continues.

6. Compliance and monitoring

[Security Operations Manager] reports these measures to [the security committee] each quarter:

Percentage of triggering incidents with a review held within [5 working days] (target: [95%]).
Median days from incident closure to approved report.
Percentage of corrective actions closed by their due date, by priority.
Number of repeat incidents whose cause matches a previous review within 12 months (target: falling).
Share of incidents first detected internally rather than by a third party.
Participant survey score on whether reviews feel safe and useful.

Internal audit reviews a sample of reports annually against section 4.4.

7. Review and approval

Field	Entry
Policy owner	[Name, role]
Approved by	[Review Sponsor], [date]
Version	[1.0]
Next review	[date, no later than 12 months]
Related documents	[Incident Response Plan], [SOC runbooks], [Risk Management Policy], [Change Management Policy]

Implementation guidance

Rolling it out

Agree triggers and severities: align 4.1 with the severity scheme in your incident response plan before anything else.
Build the report template and action register: create the 4.4 sections in your ticketing or document tool, and link each action to a ticket so overdue items are visible.
Train facilitators: pick three to five people from outside the SOC, such as engineering managers or risk staff, and run a mock review on a past incident.
Pilot: run the process for one quarter on Severity 1 and 2 incidents only. Collect participant feedback, adjust timing, then extend to operational incidents.
Close the loop: feed findings into detection rules, runbooks, risk register and training. See the SOC Runbook Template for updating runbooks after a review.
Roll back if needed: if the backlog of reviews grows faster than they close, raise thresholds temporarily rather than skipping reviews informally, and record the change.

Small and large organisations

A small team can run a 45-minute review with the short form and a shared action spreadsheet; the key controls are the triggers, blameless rules and action tracking. Large organisations benefit from a central repository searchable by cause category, quarterly trend analysis across reviews, and cross-team reviews when an incident spans business units or suppliers. In both cases, a review that only one team reads changes little.

Common failure patterns

Stopping at the trigger: "a token was leaked" is the trigger. The cause is why it was long-lived, over-privileged and unmonitored. See the Leaked Credential Response Playbook.
Human error as the root cause: it closes the analysis and teaches people to hide mistakes.
Actions without owners or dates: they become a list of wishes and the same incident recurs.
Ignoring detection gaps: the State Department detected the Storm-0558 intrusion with a custom alert on mailbox access logs; reviews should ask what logging and alerting would have shortened dwell time.
Reviewing only security incidents: outages and failed changes share causes with breaches, such as unmanaged credentials and expired certificates. See the Major IT Outage Lessons Guide.

Framework mapping

Framework	Reference	What this policy provides
NIST CSF 2.0	RS.AN-03, RS.AN-06, RS.AN-07	Root cause analysis and protected incident records (4.2, 4.5)
NIST CSF 2.0	ID.IM-01, ID.IM-03, ID.IM-04	Improvements identified and incident plans updated (4.6, 6)
NIST SP 800-53 Rev. 5	IR-4, IR-8, CA-5	Incident handling including lessons learned, plan updates, plan of action and milestones
ISO/IEC 27001:2022 Annex A	5.27 Learning from information security incidents; 5.28 Collection of evidence	Review process and evidence handling

Related reading: the Incident Response Guide covers the wider life cycle, and the CWE Top 25 Guide helps classify software weaknesses found as root causes.

Standards and references

This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: Incident Response Plan Template · Incident Response Maturity Model · Digital Forensics (DFIR) Guide · SOC Guide

Post-Incident Review and Root Cause Analysis Template: Blameless Learning After Incidents