Lessons learned

NIST SP 800-61 Rev. 2 (§3.4.1) placed the lessons-learned meeting in the post-incident activity phase, to be held within several days of the end of a major incident, and suggested questions that are still widely used: exactly what happened and at what times, how well staff and management performed, whether documented procedures were followed and adequate, what information was needed sooner, which actions inhibited recovery, what would be done differently, how information sharing could be improved, what corrective actions could prevent similar incidents, which precursors or indicators should be watched for, and which tools or resources are missing. Revision 3 (2025) moves improvement into the Cybersecurity Framework 2.0 Identify function's Improvement category and treats it as continuous, so lessons can be captured during an incident and after exercises and assessments, not only at the close.

The blameless post-incident review, popularised by site reliability engineering practice, assumes that people acted reasonably given the information and pressures they had at the time. The aim is to explain why decisions made sense then, avoiding hindsight bias and a search for a single root cause. Complex incidents usually have several contributing factors, such as an unpatched system, a missing alert, an unclear mandate and a stale contact list, and naming only one of them leaves the others in place. Techniques include timeline reconstruction from logs and chat records, five whys, fishbone diagrams and structured frameworks for contributing factors.

The output is a written report with a factual timeline, impact, what went well, what did not, and a list of actions, each with an owner, a deadline and a way to verify completion. Actions typically change detection rules, playbooks, contact lists, architecture, training or contracts with suppliers. Tracking closure is the step most often skipped; organisations that report the same finding across several reviews have documented rather than learned. The report can also supply material for the NIS2 final report on root cause and mitigation, but the two have different audiences and should not be the same document.

In ISO/IEC 27001:2022 the practice is required through Annex A control 5.27, learning from information security incidents, and connects to clause 10 on continual improvement and corrective action, which is why the term maps naturally to the Act step of the PDCA cycle. Lessons learned differs from incident reporting in purpose and timing: reporting passes facts to others during and shortly after the event, while lessons learned is an internal analysis aimed at change.