ISO 27001 Annex A 5.27

An incident is wasted if no one learns from it.

ISO 27001 Annex A 5.27 - Learning from Information Security Incidents

An incident that does not generate learning is a missed opportunity. The control closes the loop - after the response is complete, the organisation reflects on what happened, what worked, what did not, and what should change as a result. The output flows back into the policy framework, the risk register, the awareness training and the controls themselves.

The post-incident review should be honest. Looking for someone to blame discourages reporting and undermines learning. The focus should be on the systemic factors - what controls failed or were missing, what made detection slow, what made response harder than it needed to be. The aim is to reduce the likelihood or impact of similar incidents in future.

Learning takes different forms depending on what the incident revealed. A control gap leads to a new or strengthened control. A detection failure leads to better monitoring or alerts. A communication breakdown leads to changes in the response procedure. A pattern across multiple incidents may surface a deeper issue that needs strategic attention.

The most valuable post-incident reviews are the ones that do not just identify what to fix but actually change something. Findings that go in a report and never get addressed are worse than no findings, because they create the impression that learning has happened when it has not. The review should always end with named actions, owners and dates.

Practical Compliance Guidance

Post-incident learning is described in the IMS1 manual at section 8.2 alongside the incident management process. Findings flow into the risk register and into the management review process.

alphaZ document How to use it
ISO 27001 Toolkit The full alphaZ ISO 27001 toolkit covering manual, policies, procedures, registers and audit checklists.
F-Q109 Information Security Incident The incident form. Use the closure section to capture lessons learned, agreed actions, owners and target dates. Significant incidents should also feed into the management review and risk register.

Note - all the above files can be downloaded with an alphaZ subscription.

Frequently Asked Questions

Soon enough that the detail is fresh, but late enough that the immediate response is complete and the dust has settled. Two to four weeks after closure is typical for significant incidents. Smaller incidents can be reviewed more quickly. Very major incidents may benefit from both an early hot-wash and a more reflective review some weeks later.
The people who were involved in the response, plus the asset and system owners affected. For significant incidents, senior management or their nominee should also attend or receive the output. The aim is honest reflection rather than blame, so the atmosphere should support open discussion.
Through the documented review output, the agreed actions, evidence those actions were completed, and where applicable changes to policies, procedures or controls that resulted. Trends across multiple incidents should be visible in the management review reporting and in the risk register updates.

Further Resources

payment logos