When is a post-incident review needed, and what must it produce?

Start

An incident has closed

Closure means the recovery criteria are met, the monitoring period has passed without recurrence and the case log is complete. The review follows closure, so its clock starts there. The incident manager books it at closure.

• Then: Was it Severity 1 or 2?

Decision

Was it Severity 1 or 2?

Severity 1 and 2 incidents each get a review of their own, one per incident. The rule is the policy's, so it applies to every Severity 1 and 2 incident whatever its category. Severity 3 and 4 incidents are not left out: they are reviewed together each quarter.

• Yes: Book it at closure; hold it within 10 working days
• No: Severity 3 or 4, or a near miss: Was a report late, a target badly missed, or a cause repeated?

Decision

Was a report late, a target badly missed, or a cause repeated?

These are the pack's grounds for a review of its own whatever the severity: a report made late, a target badly missed, or the same cause coming back. If you cannot yet tell, for example because a similar incident is still being analysed, take the yes branch and ask.

• Yes, or not known: Does the Head of Information Security call a review of its own?
• No: Review it with the quarter's Severity 3 and 4 incidents

Decision

Does the Head of Information Security call a review of its own?

In the pack this is the Head of Information Security's decision. A report to an authority made late because the policy was not followed is itself reported to executive management with its cause. Whether a review of its own is the way to find that cause is your judgement; the pack does not require one.

• Yes: Book it at closure; hold it within 10 working days
• No: Review it with the quarter's Severity 3 and 4 incidents

Outcome

Review it with the quarter's Severity 3 and 4 incidents

Severity 3 and 4 incidents, and near misses, are reviewed together once a quarter on one form, with a row per incident: the review, measures against targets, what went well and what did not, root cause and actions. Look for repeated causes and for incidents that should have been rated higher. Five misdirected emails in a quarter point to one fix.

Step

Book it at closure; hold it within 10 working days

The incident manager books the review at closure and fills in the incident, timeline, measures and reporting duties from the case log, so the meeting spends its time on analysis. The 10 working days is the policy's rule for Severity 1 and 2; for a review the Head of Information Security calls, the pack sets no deadline. The facilitator is the Head of Information Security or someone not involved in the response.

• Then: Is an authority final report still to be made?

Decision

Is an authority final report still to be made?

A NIS2 final report is due within one month of the incident notification, and a DORA final report no later than one month after the latest intermediate report. Both need the root cause and the mitigation, which the review produces. If you are not sure whether one is still due, plan as if it is.

• Yes, or not known: Hold it in time to feed the final report
• No: Agree what happened, why, and what it cost

Step

Hold it in time to feed the final report

Schedule the review so the root cause, mitigation and actions are ready before the final report is due. In the pack's example, the review 4 working days after closure supplied the NIS2 final report, sent before its deadline.

• Then: Agree what happened, why, and what it cost

Step

Agree what happened, why, and what it cost

The meeting agrees what went well and what did not, the chain of 'why?' back to a root cause the organisation can change, and the impact. It looks at facts and conditions, not at people: names appear in the timeline because they are facts. 'User error' is a person, not a condition, and is the common reason a review is sent back. Attendees include the executive incident lead for Severity 1 and the Data Protection Officer where personal data was involved.

• Then: Name each risk touched, for its owner to reassess

Step

Name each risk touched, for its owner to reassess

An incident is a trigger for reassessing the risks it touches. Name each one by its ID in your risk register; its owner reassesses it within the risk pack's window, 10 working days by default, counted from the incident. 'Risk register to be updated' with no ID is sent back. If the incident came by a route no risk describes, ask whether a new risk is needed.

• Then: Give every action an owner, a due date and a link

Step

Give every action an owner, a due date and a link

Each point that did not go well leads to an action, or says why none is needed. One change per action, owned by a role, with a due date and a link to the risk, plan or playbook it changes. The pack's default due date is within 90 calendar days of the review. 'Raise awareness' with no owner or date is sent back. Enter every action in your incident case and action log.

• Then: Change the plan, playbooks and matrix where needed

Step

Change the plan, playbooks and matrix where needed

Name each change against the document it changes, or say why none is needed. After every Severity 1 incident the plan is reviewed, and the review is recorded in its revision history even if nothing changes.

• Then: Approved, then followed up each quarter until done

Outcome

Approved, then followed up each quarter until done

The Head of Information Security approves every review; for Severity 1 the executive incident lead approves too. Nobody signs off their own review. The actions are followed up at each quarterly report until closed. Open actions past their due date are counted in the quarterly report to executive management, where the pack's target is none more than 30 days overdue.