Guidance

Cyber Assessment Framework

The CAF is a collection of cyber security guidance for organisations that play a vital role in the day-to-day life of the UK, with a focus on essential functions.

Page 21 of 25

Principle D2 Lessons Learned

iStock.com/studioU

Principle

When an incident occurs, steps are taken to understand its causes and to ensure remediating action is taken to protect against future incidents.

Description of principle

If an incident does occur, it is important your organisation learns lessons as to why it happened and, where appropriate, take steps to prevent the issue from reoccurring. The aim should be to address the root cause or to identify systemic problems, rather than to fix a very narrow issue. For example, to address the organisation's overall patch management process, rather than to just apply a single missing patch.

Guidance

You should use the guidance points below to learn lessons and address shortfalls in:

your overall protective security (see Objectives A - C) and
your incident response plan (see Response and Recovery Planning)

Post Incident Analysis

Each incident or exercise should include assessment of its causes and any other factors that obstructed the required standard of recovery. You should consider what measures would need to be in place to prevent similar incidents in the future or to improve your response capabilities. This might mean improving the quality or timeliness of detection, or designing the system so that simpler or more effective actions can be taken more quickly, or introducing mitigations to reduce the likelihood of such incidents occurring.

Your organisation should produce good quality reporting during incident response and exercising. Factors that affect the quality of reporting include information sharing, governance or processes, or clearly defined roles, responsibilities and training.

You should keep sufficiently detailed records to show how information was used to make decisions, so that the causes of an incident can be identified and any shortfalls in response and preventive strategies can be assessed. These might include gaps in security monitoring, poor understanding of networks, insufficient business continuity planning, or inadequate internal communication.

These lessons should be clearly and comprehensively documented and fed into your protective security as well as your response plans. Further details can be found in NIST Computer Security Incident Handling Guide and ISO/IEC 27035-1.

Reduced Risk, Driving Improvements

You should use post-incident and post-exercise reviews to actively reduce the risks associated with the same, or similar, incidents happening in future.

You can also develop your understanding by assessing how an incident might have been more disruptive by considering ‘what if’ scenarios and / or assessing how it might have been mitigated by considering ‘if only’ scenarios.

Lessons learned can inform any aspect of your cyber security, including:

System upgrades
Security monitoring and reporting
Investigation procedures
Containment/recovery strategies
Governance and communication around incident management

Reporting

Lessons drawn from incidents or exercising should be shared with all relevant internal and external stakeholders e.g. regulators and competent authorities, as and when required, but also to internal governance, who can approve new preventive/responsive measures, or to organisations such as NCSC, who can provide insight around incident trends.

Data Retention

Many incidents go undetected for long periods. You should consider your organisation's data retention policies, especially the retention period and quality of historical data (e.g. any data aggregation performed after a time may restrict investigation), in order to ensure that incidents detected several months after they occurred can still be analysed adequately.

In determining adequate retention periods, you should consider how effective your monitoring capability is (i.e. how long might an incident go undetected), experience of past incidents and any examples available in threat intelligence. Ensure that, if an incident occurs, your organisation would have sufficient data to perform the required level of post-incident analysis, learn lessons from the analysis, and report the right details to the right people (e.g. internal decision-makers or external regulators or competent authorities).

D2.a Post Incident Analysis

When an incident occurs, your organisation takes steps to understand its causes, informing appropriate remediating action.

Not Achieved	Achieved
At least one of the following statements is true:	All the following statements are true:
You are not usually able to resolve incidents to a root cause or identify the contributing factors within a broader systems context. You do not have a formal process for investigating causes. Investigators form theories early in the process and only seek evidence that affirms their belief. Investigations are solely focused on identifying the person(s) who can be held responsible for the incident.	Post incident analysis is conducted routinely as a key part of your lessons learned activities following an incident. Your post incident analysis is comprehensive, considering organisational factors (e.g. policies, processes and procedures), technical factors (e.g. system design, vulnerabilities), human factors (e.g. training, security culture) and any changes to threat. All relevant incident data is made available to the analysis team to perform post incident analysis. Your analysis considers what could have happened under plausible, alternative circumstances (e.g. ‘what if’ / ’if only’ scenarios).

Not Achieved

Achieved

At least one of the following statements is true:

All the following statements are true:

You are not usually able to resolve incidents to a root cause or identify the contributing factors within a broader systems context.

You do not have a formal process for investigating causes.

Investigators form theories early in the process and only seek evidence that affirms their belief.

Investigations are solely focused on identifying the person(s) who can be held responsible for the incident.

Post incident analysis is conducted routinely as a key part of your lessons learned activities following an incident.

Your post incident analysis is comprehensive, considering organisational factors (e.g. policies, processes and procedures), technical factors (e.g. system design, vulnerabilities), human factors (e.g. training, security culture) and any changes to threat.

All relevant incident data is made available to the analysis team to perform post incident analysis.

Your analysis considers what could have happened under plausible, alternative circumstances (e.g. ‘what if’ / ’if only’ scenarios).

D2.b Using Incidents to Drive Improvements

Your organisation uses lessons learned from incidents to improve your security measures.

Not Achieved	Achieved
At least one of the following is true:	All the following statements are true:
Improvements arising from lessons learned following an incident are not implemented or not given sufficient organisational priority. Changes are made as a ‘knee jerk’ reaction to an incident without proper analysis and testing to ensure the change is appropriate. You wait until a severe or high-profile incident has occurred before you take steps to improve.	You have a documented incident review process / policy which ensures that lessons learned from each incident, including near misses, are identified, captured, and acted upon. Lessons learned cover issues with reporting, roles, governance, skills and organisational policies, processes and procedures as well as technical aspects of network and information systems. You use lessons learned to improve security measures, including updating and retesting response plans when necessary. Security improvements identified as a result of lessons learned are prioritised, with the highest priority improvements completed promptly. Analysis is fed to senior management and incorporated into risk management and continuous improvement. Your organisation maximises the lessons learned by using the analysis into ‘what if’ / ’if only’ scenarios. Your organisation learns from reported incidents in your sector and the wider national infrastructure.

Not Achieved

Achieved

At least one of the following is true:

All the following statements are true:

Improvements arising from lessons learned following an incident are not implemented or not given sufficient organisational priority.

Changes are made as a ‘knee jerk’ reaction to an incident without proper analysis and testing to ensure the change is appropriate.

You wait until a severe or high-profile incident has occurred before you take steps to improve.

You have a documented incident review process / policy which ensures that lessons learned from each incident, including near misses, are identified, captured, and acted upon.

Lessons learned cover issues with reporting, roles, governance, skills and organisational policies, processes and procedures as well as technical aspects of network and information systems.

You use lessons learned to improve security measures, including updating and retesting response plans when necessary.

Security improvements identified as a result of lessons learned are prioritised, with the highest priority improvements completed promptly.

Analysis is fed to senior management and incorporated into risk management and continuous improvement.

Your organisation maximises the lessons learned by using the analysis into ‘what if’ / ’if only’ scenarios.

Your organisation learns from reported incidents in your sector and the wider national infrastructure.

Additional information

Also see

Blog Post 6 Aug 2025