Post-Incident Review Template
Captures root cause, timeline, control failures and tracked improvement actions once an incident closes.
Available soon
- Format
- Word
- Size
- 64 KB
- Length
- 21 pages
- Version
- 1.1
- Updated
What's inside
What changed
- 1.1
Part L counts every open action past its due date in IMM-03, as the policy defines the measure, not only those more than 30 days late.
- 1.0
Published.
Preview
The document from section 1, as you will receive it. Highlighted [[text]] is for you to replace; shaded guidance boxes are for you to delete before approval. The cover and document control pages are in the file.
How to use this form
Use this form to record the review of a security incident after it closes: what happened, how the response went against its targets, why it happened, and what will change. The review looks at facts and conditions, not at people. Its output is a short list of actions with owners and due dates, and a fresh look at the risks the incident touched.
Every Severity 1 and 2 incident must have a post-incident review within 10 working days of closure; its actions must have owners and due dates, and the risks it touches must be reassessed (P05 RM-10) (IM-11). The rules are in the Security Incident Management Policy; the Incident Response Plan says how a review follows closure. The plan must be exercised at least once a year and reviewed after every Severity 1 incident (IM-12).
When a review is held
Incident | Review | Form |
|---|---|---|
Severity 1 and 2 | One review per incident, within 10 working days of closure (IM-11) | The whole form |
Severity 3 and 4, and near misses | Severity 3 and 4 incidents are reviewed together once a quarter | One form for the quarter: Parts A2, C, E, F and I, with a row per incident |
Any incident where a report is late, a target is badly missed, or the same cause has come back | A review of its own, whatever the severity, on the Head of Information Security's decision | The whole form |
Who attends, and for how long
- Facilitator: the Head of Information Security, or someone not involved in the response. The facilitator keeps it to facts and conditions.
- Always: the incident manager, the technical responders (including providers who took part), and the owners of the affected services.
- When relevant: the executive incident lead (always for Severity 1), the Data Protection Officer (personal data), the communications lead (anything said outside), the owners of the risks in Part H.
- How long: [[90]] minutes; [[120]] minutes for Severity 1. The incident manager fills Parts A to D from the Incident Case & Action Log before the meeting, so the meeting spends its time on E to J.
Steps
- The incident manager books the review at closure, inside the 10 working days, and fills Parts A to D from the case log.
- The meeting agrees Parts E to G: what went well and what did not, the why chain and root cause, and the impact.
- The owners of the risks named in Part H reassess them within the Information Security Risk Management pack's [[10]] working days (RM-10), counted from the incident.
- Each action in Part I gets an owner, a due date and a link, and is entered in the Incident Case & Action Log.
- The Head of Information Security approves the review; for Severity 1, the executive incident lead too. Changes in Part J are made to the documents they name.
- Part L is updated each quarter until every action is done.
Guidance — delete before approval
A blameless review is not a review without names: say who did what in the timeline, because that is the fact. What it avoids is judging people. Ask "what made that the sensible thing to do at the time?", and fix the conditions.
If an authority final report is due (NIS2 RD-04, DORA RD-12), hold the review in time to feed it: the final report needs the root cause and the mitigation, and this form holds both.
Field guidance
Field | What a good answer looks like | Common reason a review is sent back |
|---|---|---|
B Timeline | Times to the minute from the case log, including decisions and who took them. | Times from memory; decisions missing. |
C Measures | Each worked out from Part B, with the target beside it. | "Fast" or "within target" with no number. |
E What did not go well | A condition that can be changed: a missing step, a right not granted, a contact not known. | "User error": a person, not a condition. |
F Why chain | Each answer explains the one above it; the last is something the organisation controls. | Stops at the first answer. |
H Risks | Risk IDs from the Information Security Risk Register, each with who reassesses it and by when. | "Risk register to be updated" with no ID. |
I Actions | One change each, owned by a role, with a date and a link. | "Raise awareness" with no owner or date. |
The form
Guidance — delete before approval
Replace the placeholders with blank space when you adopt the form, or leave them as prompts. Keep the targets in Part C the same as the Incident Classification, Severity & Escalation Matrix and the Incident Triage & First-Hour Assessment Procedure.
Part A — The incident and the review
A1 Incident | |||
Case number from the case log | [[INC-YYYY-nnn]] | Category | [[IC-nn, name]] |
Title | [[Short title, as in the case log]] | ||
Severity at declaration, and any change with its reason | [[Severity n; changed to n on YYYY-MM-DD because …]] | ||
Incident manager | [[Name or role]] | Executive incident lead | [[Name or role, or not involved]] |
Summary what happened and what it affected, in three or four sentences | [[What happened, how it was found, what it affected, and how it ended]] | ||
A2 Review | |||
Review date | [[YYYY-MM-DD]] | Working days after closure IM-11: at most 10 | [[n]] |
Facilitator | [[Head of Information Security, or someone not involved in the response]] | ||
Attended | [[Names and roles]] | ||
Part B — Timeline
Key times from the case log. Each is a date and time to the minute.
B1 Key times | |||
Reported | [[YYYY-MM-DD HH:MM]] | Triage started | [[YYYY-MM-DD HH:MM]] |
Declared awareness: reporting clocks start | [[YYYY-MM-DD HH:MM]] | Contained | [[YYYY-MM-DD HH:MM]] |
Restored the service back in normal use | [[YYYY-MM-DD HH:MM]] | Closed recovery criteria met and monitoring passed | [[YYYY-MM-DD HH:MM]] |
The full timeline: every decision, escalation, report and turning point, with who did it.
When | What happened | Who |
|---|---|---|
[[YYYY-MM-DD HH:MM]] | [[Event, decision or report]] | [[Role]] |
[[YYYY-MM-DD HH:MM]] | [[Event, decision or report]] | [[Role]] |
[[…]] |
Part C — Measures against targets
Each measure is worked out from the times in Part B. Where a target was missed, say why in Part E.
Measure | Actual | Target | Met |
|---|---|---|---|
Minutes to triage report to triage started | [[n]] | 30 minutes in working hours, 60 outside (IM-02) | [[Yes / No]] |
Triage decision triage started to declared | [[n]] | [[30]] minutes (IM-02) | [[Yes / No]] |
Executive incident lead told from declaration | [[n]] | The severity's time (IM-05) | [[Yes / No]] |
Crisis team convened from declaration | [[n]] | The severity's time (IM-05) | [[Yes / No]] |
Board chair told from declaration | [[n]] | The severity's time (IM-05) | [[Yes / No]] |
Reporting screen complete from declaration | [[n]] | 4 hours (IM-06) | [[Yes / No]] |
Hours to contain detection to containment | [[n]] | [[24]] hours (IMM-01) | [[Yes / No]] |
Time to restore declaration to service restored | [[n]] | [[Recovery objective for the service]] | [[Yes / No]] |
Monitoring before closure restored to closed | [[n]] | 7 days (recovery criteria, IM-10) | [[Yes / No]] |
Review held closure to review | [[n]] | 10 working days (IM-11) | [[Yes / No]] |
Part D — Reporting duties screened and met
Every duty the reporting screen considered (IM-06), with its deadline and when it was met. A duty screened out is listed with the reason.
Duty | Report | Deadline | Made | On time |
|---|---|---|---|---|
[[RD-nn]] | [[Report]] | [[Deadline rule: date and time]] | [[YYYY-MM-DD HH:MM, or screened out: reason]] | [[Yes / No / —]] |
[[RD-nn]] | [[Report]] | [[Deadline rule: date and time]] | [[YYYY-MM-DD HH:MM, or screened out: reason]] | [[Yes / No / —]] |
Part E — What went well, and what did not
Facts and conditions, not people. Each point that did not go well leads to an action in Part I, or says why none is needed.
What went well | What did not go well | Action |
|---|---|---|
[[…]] | [[…]] | [[PIA-nn / none: why]] |
[[…]] | [[…]] | [[PIA-nn / none: why]] |
Part F — Root cause and contributing factors
Ask "why?" from the harm back, until the answer is something the organisation can change. The last answer is usually the root cause; the others are contributing factors.
Why? | Because |
|---|---|
[[Why did the harm happen?]] | [[…]] |
[[Why did that happen?]] | [[…]] |
[[Why …?]] | [[…]] |
F1 Root cause | |||
Root cause one or two sentences | [[The condition that, had it not existed, would have prevented the incident or kept it small]] | ||
Part G — Impact
G1 What the incident cost | |||
Service what stopped or slowed, for how long | [[Service, duration, who was affected]] | ||
Data what was taken, lost, altered or unavailable | [[Data affected, how many people or records, and the GDPR assessment]] | ||
Money cost of response, recovery and lost work | [[€ amount, and what it includes]] | ||
People told inside and outside | [[Authorities, customers, individuals, insurer, police, board, staff]] | ||
Part H — Risks to reassess
A trigger forces reassessment of the risks it touches within [[10]] working days (RM-10, Information Security Risk Management pack). An incident is such a trigger. Name each risk in the Information Security Risk Register the incident touches; its owner reassesses it and the new score is recorded here.
Risk | Why touched | Reassessed | Result |
|---|---|---|---|
[[R-nn title]] | [[How the incident bears on it]] | [[YYYY-MM-DD by risk owner]] | [[New score and band, or no change: why]] |
[[R-nn title]] | [[…]] | [[…]] | [[…]] |
Part I — Actions
Each action has an owner, a due date and a link to the risk, plan or playbook it changes (IM-11). The default due date is [[within 90 calendar days]] of the review; enter every action in the Incident Case & Action Log.
ID | Action | Owner | Due | Links to | Status |
|---|---|---|---|---|---|
PIA-[[nn]] | [[What will be done]] | [[Role]] | [[YYYY-MM-DD, default within 90 calendar days]] | [[Risk R-nn / plan / playbook / matrix]] | [[Open]] |
PIA-[[nn]] | [[…]] | [[…]] | [[…]] | [[…]] | [[…]] |
Part J — Updates to the plan, playbooks and matrix
Document | Change |
|---|---|
Incident Response Plan | [[Change and action ID, or no change: why]] |
Incident Classification, Severity & Escalation Matrix | [[…]] |
Incident Triage & First-Hour Assessment Procedure | [[…]] |
[[Playbook]] | [[…]] |
Part K — Decision and approval
K1 Approval | |||
Head of Information Security approves every review | [[Name, signature, date]] | ||
Executive incident lead Severity 1 only | [[Name, signature, date — or not required]] | ||
Actions entered in the Incident Case & Action Log by | [[Name, date]] | ||
Plan review needed? after every Severity 1 incident (IM-12) | [[Yes: … / No]] | ||
Feeds a final report? NIS2 RD-04, DORA RD-12 | [[Which report, and its due date — or none]] | ||
Part L — Follow-up
Completed after the review, at each quarterly report, until every action is closed. Every open action past its due date is counted in IMM-03, review actions overdue (target: none more than 30 days overdue), as the Security Incident Management Policy defines it.
ID | Status at [[YYYY-MM-DD]] | Against due date |
|---|---|---|
PIA-[[nn]] | [[Open / In progress / Done YYYY-MM-DD]] | [[On time / Late / Overdue by n days]] |
Worked example — the review of a ransomware incident
This is the review of INC-2026-014, held on 27 Aug 2026, for a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders, an important entity under NIS2 in its Member State. It is the incident the example board report in the Board Cybersecurity Reporting pack describes, and the trigger for the reassessment of risk R-04 in the Information Security Risk Management pack. The organisation, names and dates are fictional; replace them with your own.
Guidance — delete before approval
Status in Part I is as at the review: only PIA-03 was done by then, because the risk owner reassessed R-04 under RM-10 before the review met. Part L shows the same actions as at 30 Sep 2026.
Delete this worked example from your adopted form.
Part A — The incident and the review
A1 Incident — EXAMPLE | |||
Case number from the case log | INC-2026-014 | Category | IC-01 Ransomware or destructive malware |
Title | Ransomware on 14 office PCs at Warehouse 2 | ||
Severity at declaration, and any change with its reason | Severity 1 (Critical); unchanged throughout | ||
Incident manager | Information Security Manager | Executive incident lead | Chief Operating Officer |
Summary what happened and what it affected, in three or four sentences | The security monitoring provider alerted on encryption activity on one office PC at Warehouse 2. It had spread to 14 office PCs on that site's office network before the site was cut off. Ordering and dispatch were not affected. | ||
A2 Review — EXAMPLE | |||
Review date | 27 Aug 2026, 10:00 | Working days after closure IM-11: at most 10 | 4 working days after closure on 21 Aug 2026 |
Facilitator | Head of Information Security | ||
Attended | Head of Information Security (facilitator); Information Security Manager (incident manager); Chief Operating Officer (executive incident lead); Head of IT; Head of Logistics (owner of the Warehouse 2 office and of risk R-04); Data Protection Officer; Managed IT service provider (SUP-001); Security monitoring provider (SUP-006) | ||
Part B — Timeline
Key times from the case log. Each is a date and time to the minute.
B1 Key times — EXAMPLE | |||
Reported | 12 Aug 2026, 07:50 | Triage started | 12 Aug 2026, 08:05 |
Declared awareness: reporting clocks start | 12 Aug 2026, 08:25 | Contained | 12 Aug 2026, 13:50 |
Restored the service back in normal use | 13 Aug 2026, 14:00 | Closed recovery criteria met and monitoring passed | 21 Aug 2026, 09:00 |
The full timeline: every decision, escalation, report and turning point, with who did it.
When | What happened | Who |
|---|---|---|
12 Aug, 07:50 | Monitoring alert: encryption activity on one office PC at Warehouse 2 | Security monitoring provider (SUP-006) |
12 Aug, 08:05 | Triage starts (out of hours: within 60 minutes) | IT service desk |
12 Aug, 08:25 | Declared Severity 1, category IC-01; reporting clocks start | Incident manager |
12 Aug, 08:40 | Executive incident lead told | Incident manager |
12 Aug, 08:55 | Decision: cut Warehouse 2's office network off from all other networks (the incident manager's decision; the executive incident lead agreed, as it stopped office work at the site) | Incident manager |
12 Aug, 09:10 | Warehouse 2 office network isolated | Managed IT provider (SUP-001) |
12 Aug, 09:20 | Crisis team convened | Executive incident lead |
12 Aug, 11:30 | Reporting screen complete: NIS2 significant; GDPR breach to assess; DORA not applicable | Incident manager, Data Protection Officer |
12 Aug, 11:45 | Cyber insurer told | Executive incident lead |
12 Aug, 12:20 | Board chair told | Executive incident lead |
12 Aug, 13:50 | Contained: 14 PCs isolated, no activity on any other site | Incident manager |
12 Aug, 15:40 | NIS2 early warning submitted | Incident manager |
12 Aug, 17:10 | Crime reported | Legal |
12 Aug, 19:30 | Eradicated: the phishing email removed from every mailbox, its sender and attachment blocked, and the affected user's and Warehouse 2 administrator passwords reset | Managed IT provider (SUP-001), email provider (SUP-005) |
13 Aug, 14:00 | Office work resumes on rebuilt PCs; backups checked before restoring | Managed IT provider (SUP-001), backup provider (SUP-011) |
14 Aug, 10:00 | GDPR assessment: unlikely to result in a risk; recorded, not notified | Data Protection Officer |
14 Aug, 14:00 | NIS2 incident notification submitted | Incident manager |
21 Aug, 09:00 | Closed after 7 days' monitoring without recurrence | Incident manager |
Part C — Measures against targets
Each measure is worked out from the times in Part B. Where a target was missed, say why in Part E.
Measure | Actual | Target | Met |
|---|---|---|---|
Minutes to triage report to triage started | 15 minutes | 60 minutes (out of hours; IM-02) | Yes |
Triage decision triage started to declared | 20 minutes | [[30]] minutes (IM-02) | Yes |
Executive incident lead told from declaration | 15 minutes | 30 minutes (IM-05) | Yes |
Crisis team convened from declaration | 55 minutes | 1 hour (IM-05) | Yes |
Board chair told from declaration | 3 hours 55 minutes | 4 hours (IM-05) | Yes |
Reporting screen complete from declaration | 3 hours 5 minutes | 4 hours (IM-06) | Yes |
Hours to contain detection to containment | 6 hours | [[24]] hours (IMM-01) | Yes |
Time to restore declaration to service restored | 29 hours 35 minutes | [[48]] hours (the example's recovery objective for one site's office work) | Yes |
Monitoring before closure restored to closed | 8 days | 7 days (recovery criteria, IM-10) | Yes |
Review held closure to review | 4 working days | 10 working days (IM-11) | Yes |
Part D — Reporting duties screened and met
Every duty the reporting screen considered (IM-06), with its deadline and when it was met. A duty screened out is listed with the reason.
Duty | Report | Deadline | Made | On time |
|---|---|---|---|---|
RD-01 | NIS2 early warning | Within 24 hours of awareness: 13 Aug, 08:25 | 12 Aug, 15:40 | Yes |
RD-02 | NIS2 incident notification | Within 72 hours of awareness: 15 Aug, 08:25 | 14 Aug, 14:00 | Yes |
RD-04 | NIS2 final report | Within one month of the incident notification (a progress report then, and the final report within one month of handling, if still ongoing): 14 Sep, 23:59 | Not yet due at the review; being written from it | — |
RD-05 | NIS2 notice to recipients of our services | Without undue delay, where appropriate | Not needed: no customer's service was affected | — |
RD-06 | GDPR notification to the supervisory authority | Without undue delay and, where feasible, within 72 hours of awareness; later only with reasons for the delay | Not made: the breach was assessed as unlikely to result in a risk to individuals | — |
RD-08 | GDPR breach record | For every personal data breach, notified or not | Recorded 14 Aug, 10:00 | Yes |
RD-10 to RD-13 | DORA reports | — | Not applicable: not a financial entity | — |
RD-15 | Notice to the cyber insurer | [[as the policy requires, often within 48 hours]] | 12 Aug, 11:45. Insurer's incident line; its panel firm was not needed | Yes |
RD-16 | Crime report | [[as soon as practical for suspected crime]] | 12 Aug, 17:10. Reported to [[the national cybercrime reporting service]] | Yes |
Part E — What went well, and what did not
Facts and conditions, not people. Each point that did not go well leads to an action in Part I, or says why none is needed.
What went well | What did not go well | Action |
|---|---|---|
The monitoring provider alerted at 07:50, before working hours, and triage started 15 minutes later (limit 60). | The decision to cut Warehouse 2's office network off came 30 minutes after declaration and the isolation 45 minutes after; the steps to isolate each site were not written down, so they were worked out on the call. | PIA-04 |
Severity 1 was set at declaration on what the malware could do, not on the one PC it started on, and every escalation was within its time (Part C). | The ransomware reached 14 PCs before the site was cut off: the site's office network was not yet separated. | PIA-02 |
The reporting screen was complete 3 hours 5 minutes after declaration; the NIS2 early warning went 7 hours 15 minutes after awareness, well inside 24 hours. | The user whose account ran the malware had local administrator rights on the PC. | PIA-01 |
Backups were checked for integrity before they were restored (IM-10), and office work resumed 29 hours 35 minutes after declaration. | Out of hours the monitoring provider's analyst had no direct line to the incident manager, so the alert went through the service desk first. | PIA-05 |
Ordering and dispatch were never affected. |
Part F — Root cause and contributing factors
Ask "why?" from the harm back, until the answer is something the organisation can change. The last answer is usually the root cause; the others are contributing factors.
Why? | Because |
|---|---|
Why were 14 office PCs encrypted? | The ransomware spread from the first PC across Warehouse 2's office network before the site was cut off. |
Why could it spread? | That site's office network was not yet separated from the others, and the account it ran under had local administrator rights on the PC. |
Why did it run at all? | A warehouse office user opened a phishing attachment. |
Why did the user have local administrator rights? | Office PCs were set up with local administrator rights for their users, and nobody had reviewed or removed them. |
Why was the site not yet separated? | The separation of the warehouse networks (P05 TA-04) was being done site by site, and Warehouse 2 was still to come. |
F1 Root cause — EXAMPLE | |||
Root cause one or two sentences | A phishing attachment opened by a warehouse office user whose account had local administrator rights. That site's office network was not yet separated, so it spread to 14 PCs. | ||
Part G — Impact
G1 What the incident cost — EXAMPLE | |||
Service what stopped or slowed, for how long | Office work at Warehouse 2 stopped for 29 hours 35 minutes, from declaration until the rebuilt PCs were in use. Ordering and dispatch were not affected. | ||
Data what was taken, lost, altered or unavailable | Personal data breach (availability of shipping records on the PCs); restored from backup, no sign of data taken; unlikely to result in a risk, so recorded and not notified | ||
Money cost of response, recovery and lost work | [[Cost from Finance: the managed IT provider's rebuild time, overtime and lost office work]] | ||
People told inside and outside | The authority (RD-01, RD-02); the cyber insurer (RD-15); the police (RD-16); the board chair; staff at Warehouse 2. No customer or individual needed to be told. | ||
Part H — Risks to reassess
A trigger forces reassessment of the risks it touches within [[10]] working days (RM-10, Information Security Risk Management pack). An incident is such a trigger. Name each risk in the Information Security Risk Register the incident touches; its owner reassesses it and the new score is recorded here.
Risk | Why touched | Reassessed | Result |
|---|---|---|---|
R-04 Ransomware spreads from warehouse office PCs to warehouse systems | The incident was this risk happening at one site | 20 Aug 2026 by Head of Logistics: 6 working days after the incident (RM-10: [[10]]) | Score 9, High, while two sites remained unseparated; actions PIA-01 and PIA-02 |
R-01 Ransomware takes online ordering offline for more than 2 days | Ransomware again, but the ordering platform was not reached | Considered at the review | No change: nothing learned about how likely or how bad an outage of online ordering would be |
R-10 Backups cannot restore a critical system | Backups were used to restore the PCs | Considered at the review | No change: the backups were checked before use and restored as planned, which supports the current score |
Part I — Actions
Each action has an owner, a due date and a link to the risk, plan or playbook it changes (IM-11). The default due date is [[within 90 calendar days]] of the review; enter every action in the Incident Case & Action Log.
ID | Action | Owner | Due | Links to | Status at the review |
|---|---|---|---|---|---|
PIA-01 | Remove local administrator rights from all office PCs | Head of IT | 31 Oct 2026 | Risk R-04; the board's follow-up action in the quarterly report | Open |
PIA-02 | Finish separating the warehouse networks from the office network at all three sites (P05 TA-04; two were still joined on 12 Aug) | Head of IT | 11 Sep 2026 | P05 treatment action TA-04, risk R-04 | Open |
PIA-03 | Reassess the risk of ransomware spreading to warehouse systems (P05 R-04) | Head of Logistics | 26 Aug 2026 | Risk R-04 (P05 RM-10) | Done 20 Aug 2026 |
PIA-04 | Add site isolation steps for each warehouse to the Ransomware Response Playbook | Information Security Manager | 25 Sep 2026 | Ransomware Response Playbook | Open |
PIA-05 | Give the monitoring provider's out-of-hours analysts a direct line to the incident manager | Head of Information Security | 15 Sep 2026 | Incident Response Plan contact list; the monitoring provider's contract | Open |
Part J — Updates to the plan, playbooks and matrix
Document | Change |
|---|---|
Incident Response Plan | Out-of-hours contact list: the monitoring provider's analysts call the incident manager direct (PIA-05) |
Incident Classification, Severity & Escalation Matrix | No change. Severity 1 was set at declaration and never needed to change. |
Incident Triage & First-Hour Assessment Procedure | No change. Triage and declaration met every time limit; the incident manager's right to isolate without waiting is already in the procedure. |
Ransomware Response Playbook | Isolation steps for each warehouse site (PIA-04) |
Part K — Decision and approval
K1 Approval — EXAMPLE | |||
Head of Information Security approves every review | Head of Information Security: signed 27 Aug 2026 | ||
Executive incident lead Severity 1 only | Chief Operating Officer, executive incident lead (Severity 1): signed 27 Aug 2026 | ||
Actions entered in the Incident Case & Action Log by | Information Security Manager, 27 Aug 2026 | ||
Plan review needed? after every Severity 1 incident (IM-12) | Yes: Severity 1 (IM-12). The plan and playbook changes are in Part J (PIA-04, PIA-05) | ||
Feeds a final report? NIS2 RD-04, DORA RD-12 | Root cause, mitigation and actions from this review go into the NIS2 final report (RD-04), due 14 Sep 2026, 23:59 | ||
Part L — Follow-up
Completed after the review, at each quarterly report, until every action is closed. Every open action past its due date is counted in IMM-03, review actions overdue (target: none more than 30 days overdue), as the Security Incident Management Policy defines it.
ID | Status at 30 Sep 2026 | Against due date |
|---|---|---|
PIA-01 | In progress | Not yet due |
PIA-02 | Done 11 Sep 2026 | On time |
PIA-03 | Done 20 Aug 2026 | On time |
PIA-04 | Open | Overdue by 5 days: counted in IMM-03 |
PIA-05 | Done 10 Sep 2026 | On time |
The NIS2 final report (RD-04) was made on 11 Sep 2026, before its deadline of 14 Sep 2026, using Parts D, F and I. Part L shows the actions as at 30 Sep 2026, the example's quarter end. (EXAMPLE)
Related documents
Document | Relationship |
|---|---|
Security Incident Management Policy | The rule this form meets (IM-11), and the plan review after Severity 1 (IM-12) |
Incident Response Plan | Closure and the recovery criteria; how a review follows closure; the plan the review may change |
Incident Classification, Severity & Escalation Matrix | The severity and escalation times the measures in Part C are checked against |
Incident Triage & First-Hour Assessment Procedure | The triage and first-hour targets in Part C |
Incident Case & Action Log | The case log the timeline comes from, and where review actions are tracked |
Incident Communications Template Set | The final reports that use the review's root cause and actions |
Incident Response Readiness Checklist | The readiness checklist, which checks that open review actions are followed up |
Information Security Risk Register (Information Security Risk Management pack) | Where the risks in Part H are reassessed (RM-10) |
Adapting this template
Guidance — delete before approval
Small organisation: one form, filled in during a one-hour meeting, is enough. Parts A to D can be copied from the case log; spend the time on E, F and I. Where the incident manager is also the Head of Information Security, ask [[a senior manager or an outside adviser]] to facilitate and to approve, so nobody signs off their own review.
Regulated entity (NIS2, DORA, GDPR): a NIS2 final report must describe the incident, the likely root cause and the mitigation applied (RD-04, within one month of the notification): Parts F and I supply them. A DORA financial entity must identify, document and address root causes (Article 17(2)), and its final report (RD-12, no later than one month after the latest intermediate report) is made once the root cause analysis is complete; hold the review in time to feed that final report, and keep this form as the record of the root cause analysis. Under the GDPR every personal data breach is documented with its facts, effects and remedial action (Article 33(5), RD-08), whether notified or not: Parts B, G and I are that record.
IT run by a service provider: invite the managed IT provider and the security monitoring provider, and ask for their timeline before the meeting. Actions on a provider are owned by your contract owner for that provider, not by the provider, and may need a contract change. The review, its approval and the risk reassessment stay with your organisation.
Delete this section before approval.
Framework references
These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard. Editions referenced: ISO/IEC 27001:2022 incl. Amd 1:2024; NIST CSF 2.0; Directive (EU) 2022/2555 (NIS2) and Implementing Regulation (EU) 2024/2690; Regulation (EU) 2016/679 (GDPR); Regulation (EU) 2022/2554 (DORA), Delegated Regulations (EU) 2024/1772 and 2025/301, Implementing Regulation (EU) 2025/302.
Framework | Reference | Supported by |
|---|---|---|
ISO/IEC 27001:2022 | Annex A 5.27 — Learning from information security incidents | Whole form: knowledge from the incident used to strengthen controls |
ISO/IEC 27001:2022 | Clause 10.2 — Nonconformity and corrective action | Parts F and I: cause found, corrective actions owned, dated and followed up (Part L) |
ISO/IEC 27001:2022 | Annex A 5.28 — Collection of evidence | Part B: the timeline built from the recorded evidence and case log |
NIST CSF 2.0 | ID.IM-03 — “Improvements are identified from execution of operational processes, procedures, and activities” | Parts E, I and J: improvements identified from the response |
NIST CSF 2.0 | ID.IM-04 — “Incident response plans and other cybersecurity plans that affect operations are established, communicated, maintained, and improved” | Part J: the plan and playbooks updated |
NIST CSF 2.0 | RS.AN-03 — “Analysis is performed to establish what has taken place during an incident and the root cause of the incident” | Part F: root cause established |
NIST CSF 2.0 | RC.RP-06 — “The end of incident recovery is declared based on criteria, and incident-related documentation is completed” | Part C: closure on the recovery criteria, with documentation complete |
NIS2 — Directive (EU) 2022/2555 | Article 23(4) — an early warning within 24 hours of becoming aware of a significant incident; an incident notification within 72 hours; an intermediate report on request; a final report not later than one month after the incident notification (or a progress report, then a final report within one month of handling, if still ongoing) | Parts F and I feed the final report (RD-04) |
DORA — Regulation (EU) 2022/2554 | Article 17(2) — record all ICT-related incidents and significant cyber threats, and ensure root causes are identified, documented and addressed | Part F: root causes identified, documented and addressed |
DORA — Regulation (EU) 2022/2554 | Article 19(4) — an initial notification, an intermediate report, and a final report when the root cause analysis is complete and actual impact figures are available | Regulated-entity tailoring: the final report after root cause analysis |
DORA — Delegated Regulation (EU) 2025/301 | Article 5 — initial notification within 4 hours of classifying the incident as major and no later than 24 hours after becoming aware of it; intermediate report within 72 hours of the initial notification; final report no later than one month after the latest intermediate report | Regulated-entity tailoring: the time limit for the final report |
GDPR — Regulation (EU) 2016/679 | Article 33(5) — the controller documents every personal data breach: the facts, its effects and the remedial action taken | Parts B, G and I: the breach record of facts, effects and remedial action |
Definitions
Term | Meaning in this form |
|---|---|
Blameless | Looking for the conditions that made the incident possible or worse, not for someone to blame. Names appear in the timeline as facts. |
Closure | Recovery criteria met, the monitoring period passed without recurrence, and the case log complete. |
Containment | The incident can no longer spread or cause new harm, even though systems may not yet be restored. |
Contributing factor | A condition that made the incident more likely or worse without being its root cause. |
Recovery criteria | What must be true before a service returns to normal (IM-10), among them: backups or rebuild images were checked for integrity before they were used. |
Review action | A change agreed at the review, with an ID (PIA-nn), an owner, a due date and a link to the risk, plan or playbook it changes. |
Root cause | The condition that, had it not existed, would have prevented the incident or kept it small. |
Severity | How fast and how high we respond, 1 (Critical) to 4 (Low), set in the Incident Classification, Severity & Escalation Matrix. |
Why chain | A short run of "why?" questions from the harm back to the root cause. |