Learn from a security incident
Reconstruct what was known, examine contributing conditions and turn an incident or exercise into owned improvements with verifiable outcomes.
A post-incident review should explain what happened, how the response worked and what the organisation will change. Its value comes from completed improvements, not the length of the final document.
Separate review of the response from any specialist investigation or employment process. The learning discussion needs an accurate timeline, visible uncertainty and enough trust for participants to describe difficult decisions honestly.
The NCSC Cyber Assessment Framework's lessons-learned principle considers technical, organisational and human factors and expects improvements to be implemented. The approach below is an original practical format for that work.
Collect a record of what was known at the time
Bring together the incident log, evidence references, significant decisions, communications and recovery checks. Ask participants for corrections before drawing conclusions. Keep restricted evidence separate from the wider review paper.
Record at least three kinds of time where relevant: when an event occurred, when someone observed it and when a decision was made. A later investigation may reveal that an event happened hours before the team could see it. That does not mean the team had the later information when it made its first decision.
Worked timeline: a fictional account incident
| Point in the incident | Known then | Learned later | Review question |
|---|---|---|---|
| First report | An employee saw an unfamiliar account-setting notification | The underlying rule was confirmed in the administration record | Was the reporting route clear and easy to use? |
| Initial escalation | The lead was unavailable; the deputy could be reached | The deputy had no documented authority to restrict the service | Which decision rights were missing? |
| Coordination | Several responders could not access the normal meeting channel | The alternate channel used the same identity dependency | Had the alternative been tested under the relevant failure condition? |
| Containment | A restricted account interrupted a booking task | The manual workaround omitted reconciliation after recovery | Was the operational consequence assessed and managed? |
| Recovery | Technical access was restored | A business validation step found a missed booking update | Which acceptance criteria should have preceded normal operation? |
These are invented events for illustration. Their purpose is to show how a review can connect observations to improvements without claiming that a single mistake explains the whole incident.
A 60-minute review agenda
- Five minutes: agree purpose and boundaries. State what is known, what remains under investigation and which information cannot be shared in the meeting.
- Fifteen minutes: reconstruct the sequence. Walk through significant events and decisions, resolving discrepancies or marking them for follow-up.
- Fifteen minutes: examine contributing conditions. Consider architecture, ownership, access, supplier arrangements, workload, procedures and available evidence.
- Fifteen minutes: select improvements. Choose changes that address the conditions identified, including things that worked and should be preserved.
- Ten minutes: assign ownership and checks. Confirm actions, target dates, evidence of completion and the person who will review progress.
Adjust the time to the incident. A serious or complex event may need several focused sessions; a minor event may need only a short documented review.
Ask questions that produce useful changes
Instead of “Why did the responder fail to call the right person?”, ask “What contact and authority information was available at that point?” Instead of “Why was this not detected sooner?”, ask which records existed, who monitored them, what they could establish and whether anyone could act on the result.
Do not stop at a convenient single cause. A configuration problem may have combined with unclear ownership, a missed review and limited logging. Record the evidence for each contributing condition and the uncertainty around it.
Also ask what limited the harm. A staff member's prompt report, a well-maintained asset record or a readily available specialist may be worth supporting and repeating.
Completed action-register example
The targets below are illustrative internal planning choices measured from the review, not legal or sector deadlines.
| Action | Accountable owner | Target | Evidence required to close |
|---|---|---|---|
| Document the deputy's service-restriction authority | Service owner | Within one week | Approved delegation and a scenario in which the deputy can use it |
| Establish an alternative coordination channel with independent access | IT manager | Within two weeks | Agreed participants successfully join during a controlled identity-outage exercise |
| Add booking reconciliation to the manual workaround | Operations manager | Before the next recovery exercise | A test booking is traced from the workaround into the recovered service |
| Confirm useful audit retention and access | Technical lead | Within two weeks | A sample authorised export covers the required period and records its limitations |
| Update the customer-statement approval route | Communications owner | Within one week | Named approver and deputy confirm a draft through the agreed process |
Avoid actions such as “improve awareness” without a defined outcome. If training is needed, state the behaviour or decision it should improve and how that will be checked.
Verify the improvement, then close the action
Publishing an updated procedure is a milestone. The stronger evidence is that the relevant people can use it under the conditions that previously caused difficulty. A focused tabletop exercise may check authority and communications; a technical or business recovery test may be needed for an operational claim.
NIST's current incident-response publication includes an after-action record covering the incident, response, recovery and lessons. Keep that record linked to the action register so later teams can see which improvements were verified and which remain open.
Finish with an honest account of the unresolved risks and an agreed owner for each. Feed relevant changes back into the response plan, the evidence process and any continuing remediation work.
Sources and further reading
- NCSC Cyber Assessment Framework: Principle D2, Lessons learned — checked 2 November 2026
- NIST SP 800-61r3: full publication — checked 2 November 2026