INC-008 Post-Incident Review
Description
A post-incident review is conducted following every significant incident. The review identifies root causes, assesses the effectiveness of the response, and produces documented recommendations. Corrective actions are tracked to completion. Lessons learned are incorporated into the Incident Response Plan and relevant controls. At planned intervals the incidents closed in the period are checked against the reviews held, and an incident that met the review trigger and produced no review carries a recorded reason and a corrective action.
Rationale
Incidents that do not produce learning repeat themselves. A structured post-mortem process is the feedback loop that drives continuous improvement of the security programme. This is a check on the rule rather than an output of any review, and it catches the failure the rule actually suffers: a review process that quietly lapses under load, when the incidents worth reviewing are most frequent. It reads the incident register against the review set, so it cannot be answered from inside a review.
Applicability (9 profiles)
Annex point 3.6.3 is now stated: at planned intervals the incidents closed in the period are checked against the reviews held, and one that met the trigger and produced no review carries a reason and a corrective action.
Framework Mappings (12)
| SEF-09 | Incident Records Management | partial |
| SEF-09 | Incident Records Management | partial |
| HIPAA-164.308.a.6.ii | Response and Reporting | informative |
| 5.27 | Learning from information security incidents | full |
| NIS2-Art.21.2.b | Incident Handling | informative |
| NIS2-CIR-3.6 | Post-Incident Reviews | full |
| IR-4 | Incident Handling | partial |
| GV-1.5-002 | Risk Management Monitoring and Review | GV-1.5-002 | full |
| MG-4.2-002 | Continual Improvement Integration | MG-4.2-002 | full |
| MG-4.3-001 | Incident and Error Communication | MG-4.3-001 | full |
| MS-2.7-006 | AI System Security and Resilience Evaluation | MS-2.7-006 | informative |
| CC7.5 | Identifies, Develops, and Implements Activities to Recover from Identified Security Incidents | informative |
Evidence (2)
Post-incident review reports for significant incidents, documenting root cause analysis, response effectiveness, and corrective action recommendations.
Example: Post-incident review report or post-mortem document for the last two significant incidents, showing timeline, root cause analysis, contributing factors, response gaps, corrective actions raised, and owners assigned
Test: Request post-incident review reports for the last two significant incidents. Verify: (1) a structured review was conducted for each significant incident; (2) reports include a root cause determination; (3) corrective actions are specific, assigned to named owners, and have due dates; (4) recommendations from prior reviews were incorporated into the IRP or relevant controls. (5) the check of closed incidents against the reviews held ran within the defined interval, covered every incident closed in the period and names each incident that met the trigger and produced no review, with a reason and a corrective action for each.
Corrective action tracking records showing post-incident recommendations were assigned, tracked, and completed.
Example: Jira or equivalent project management records showing corrective action items raised from post-incident reviews, with assignee, due date, and closure evidence (linked to a control update, runbook revision, or configuration change)
Test: Request the corrective action register for post-incident recommendations from the last 12 months. Verify: (1) all significant recommendations are captured as tracked items; (2) items have a named owner and target completion date; (3) completed items show closure evidence (e.g., updated policy, configuration change, runbook revision); (4) overdue items have a documented explanation or revised timeline.
Questions (3)
Is a post-incident review conducted after every significant incident?
Post-incident reviews should be conducted within a defined timeframe after the incident is closed (e.g. within 5 business days for high-severity incidents). Corrective actions must be assigned to named owners with due dates.
What is the defined timeframe for completing a post-incident review following a high-severity security incident?
5 business days is a widely accepted target for high-severity incidents. Reviews conducted more than 30 days after closure risk losing context and reducing the quality of root cause analysis.
Which of the following does the post-incident review process produce?
Options run from the most commonly produced to the least. A review that names a cause and changes nothing is a record of the incident rather than a control, which is what the fifth item separates. The last item is not produced by any one review: it reads the incident register against the review set and is what catches the process lapsing under load.