Skip to main content

Part of Objective D - Response and recovery planning

Principle: D2 Lessons learned

Current Chapter

Current chapter – Principle: D2 Lessons learned


D2.a Post incident analysis

“When an incident or near miss occurs, your organisation takes steps to understand its causes, informing appropriate remediating action.”

Overview

This contributing outcome relates to your organisation conducting thorough analysis in the aftermath of incidents and near misses.

In the scope of the Cyber Assessment Framework (CAF)-aligned Data Security and Protection Toolkit (DSPT), 'incidents' refers to personal data breaches, breaches of confidence relating to other confidential health information, and events which have an actual adverse effect on the security of network and information systems (see ‘D1.a Response plan’ for more information).

'Near misses' are events which expose breakdowns in your organisational controls, but where an incident is prevented from occurring by fortunate circumstances. 

Near misses

'Near misses' are events which expose breakdowns in your organisational controls, but where an incident is prevented from occurring by fortunate circumstances. 

In information governance (IG), these would be scenarios where no data breach ultimately occurred, but there was a high risk of one happening due to human error or failure to follow protocols. For example: 

  • where patient records have been left unsecured in a public hospital corridor, but a member of staff notices and retrieves them before they can be seen by anyone else 
  • where confidential patient information is sent to the wrong recipient, but it's password protected so the unintended recipient cannot access it

In cyber security, these would be security events which did not ultimately cause an adverse effect on the security of networks and information systems. For example:

  • where a wrong person is given privileged access rights, but the problem is identified and fixed before the person uses them
  • where an administrator accidentally issues a delete command on important information that fails because the target happens to have an open file lock

There is room for your organisation to use its own judgment to determine what it categorises as a ‘near miss’. The important thing is that you widen your scope beyond incidents alone to improve your controls where there are clear indications that you need to do so.

Post incident analysis

During a live incident, the top priority of your team should be resolving the problem and ensuring that any information which has been compromised, whether in electronic or paper form, is secured and its integrity preserved. However, after an incident or near miss, analysis should be undertaken to establish what happened, understand the causes and improve future resilience.

Where you have judged an incident or near miss, there are key areas which your analysis should cover but not necessarily be limited to, which include:

  • determining an overall view of the incident or near miss (what led to it, how it was contained)
  • identifying the organisational, technical and human factors that contributed to the incident or near miss
  • identifying actions to take forward, based upon your findings, that reduce the likelihood of recurrence

Your findings should be communicated to relevant areas of the business so that follow up actions can be considered, with any financial and resource implications they might entail.

Not every incident or near miss requires detailed analysis. In some cases, the lessons and necessary control improvements may already be well understood, meaning further investigation is unlikely to add significant value. Reviews should be proportionate to the potential of the incident or near miss to deliver meaningful insights and lead to tangible improvements.

Post incident analysis for cyber attacks

For cyber incidents, there may be more areas to cover such as: 

  • the weaknesses (both technical and non-technical) that were exploited prior to and during the incident
  • how long any attacker was present within the environment
  • the efficacy of existing tools or processes designed to detect and prevent security incidents
  • appropriate enhancements of your networks and systems that could be made to increase resilience

Additional considerations before investigating

Before conducting your investigation, you should also consider whether it's necessary to:

  • have call off contracts in place with external specialists to lead or augment your investigation
  • involve your equipment manufacturers to assist the process
  • appoint an independent team (if appropriate)
  • keep evidence in a state where chain of custody is maintained (where it's required by law enforcement entities)

‘What if’ / ‘if only’ scenarios for cyber security incidents 

For cyber security incidents, your analysis should consider what could have happened under plausible, alternative circumstances. 

The purpose is not to predict unlikely events, but to assess whether existing response and resilience arrangements would remain effective in a range of scenarios. 

This could include situations where: 

  • the incident was detected later
  • additional systems or information assets were affected
  • key personnel or suppliers were unavailable
  • other disruptive events occurred at the same time
  • existing controls failed or were unavailable 

You could embed ‘what if’ / ‘if only’ thinking into incident review processes by, for example: 

  • holding scheduled ‘what if’ / ‘if only’ team discussions to review recent incidents and near misses and record the findings
  • adding prompts to your post-incident review template that encourage reviewers to consider other scenarios arising from the incident or near miss which has taken place

The examples in the table below show how this type of thinking can be applied in practice. Additionally, see Using ‘what if’ / ‘if only’ scenarios for lessons learned for how these examples should be used to drive improvements.

Actual cyber incident or near miss outcome ‘what if’ / ‘if only’ scenarios to consider
Ransomware affects a small number of administrative systems

What if the attack had spread to clinical systems across multiple sites?

What if national infrastructure or a key supplier had been affected simultaneously?

If only we’d enforced MFA on those systems, would that have prevented them from being compromised?

A critical vulnerability is identified in an internet-facing system and patched before any evidence of exploitation is found

What if the vulnerability had been discovered and exploited by an attacker first?

What if the system contained large volumes of patient information?

If only patching had been delayed by a few weeks, how significant could the impact have been?

Electronic patient record system is unavailable for 2 hours

What if the outage had lasted 2 weeks?

What if it had coincided with severe weather, industrial action or a major incident?

What if backup arrangements had failed or been unavailable?

Supporting evidence

To support your response, you can upload (or link to) evidence which best demonstrates your achievement of the contributing outcome. Examples include:

  • evidence of lessons learned being documented as part of incident management processes
  • list of incidents and near misses from the past 12 months or incident review logs
  • documented lessons learned and post incident analysis activities
  • evidence of methodology and considerations for undertaking post analysis exercises

This is not an exhaustive list. You're welcome to provide other types of evidence if you feel they are relevant to the contributing outcome.

Your supporting statement should cross-reference how each piece of evidence provides justification for your achievement of the contributing outcome, including relevant page numbers where appropriate.

Interpreting indicators of good practice

Indicator(s) of good practice Term Interpretation

A#2

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

‘organisational factors […] technical factors […] human factors […] changes to threat’

Organisational factors include:

  • were relevant policies and procedures available, understood and followed?
  • were escalation and reporting routes effective?
  • were risk assessments accurate and up to date?
  • did supplier management arrangements operate as expected?

Human factors include:

  • did staff have the necessary training?
  • were warning signs recognised and acted upon?
  • did workload, fatigue or competing priorities contribute?
  • did staff feel confident raising concerns or reporting mistakes?

Technical factors include:

  • were there technical weaknesses or vulnerabilities that contributed to the incident?
  • were security controls operating as intended and were they effective in preventing, detecting or containing the incident?
  • did backup, recovery or resilience measures operate as expected?
  • did dependencies between systems contribute to the incident or affect recovery activities?

Threat factors include:

  • has the nature of the threat changed?
  • are new attack techniques being used?
  • have supplier dependencies increased risk?
  • does the incident indicate a trend that wasn't previously recognised?
  • do threat intelligence sources suggest wider sector implications?

National services

The following national services may help you meet the requirements of D2.a Post incident analysis:

Security services | Microsoft Defender for Endpoint (MDE)

Additional guidance

For additional guidance, see:

National Cyber Security Centre CAF guidance | D2 Lessons learned
Site Reliability Engineering: Google | Postmortem Culture: Learning from Failure


D2.b Using incidents and near misses to drive improvements

“Your organisation uses lessons learned from incidents and near misses to improve your security measures.”

Overview

To meet this contributing outcome, you need to demonstrate that your organisation conducts lessons learned exercises after incidents and near misses to reduce the likelihood of recurrence and improve your future response capability. 

In the scope of the Cyber Assessment Framework (CAF)-aligned Data Security and Protection Toolkit (DSPT), 'incidents' refers to personal data breaches, breaches of confidence relating to other confidential health information, and events which have an actual adverse effect on the security of network and information systems (see ‘D1.a Response plan’ for more information).

'Near misses' are events which expose breakdowns in your organisational controls, but where an incident is prevented from occurring by fortunate circumstances (see 'D2.a Post incident analysis' for more information).

Lessons learned

For all incidents and near misses, your organisation should evaluate: 

  • the causes of the incident or near miss (technical and non-technical)
  • the adequacy of your response plan (if relevant)
  • the remedial activities you undertook
  • the competency of your personnel

You should use this analysis to arrive at lessons learned. These lessons learned should be used to assign specific actions, with deadlines and responsible owners, which your organisation implements to improve its resilience going forwards. Lessons learned can be documented together with your post incident analysis exercise or done as a separate activity. 

Your lessons learned exercises should also support collaboration with other organisations in your networks. Sharing information on incidents you have responded to and the effectiveness of your controls with other professionals helps achieve a better cross-sector awareness of threats.

Improving security measures 

Your lessons learned exercises should involve people at every stage of your incident response, and identify opportunities for continuous improvement across your people, processes and technology.  

Aspects of your response capability which should be informed by your lessons learned exercises include, but may not be limited to:   

  • policies, processes and procedures
  • roles, responsibilities and training for personnel
  • system configuration
  • security monitoring and reporting
  • investigation procedures
  • containment and recovery strategies
  • governance and communication around incident management
  • interdependence of systems
  • reliability of measures enacted when demanded including backup systems  

For improvement actions identified in your lessons learned exercises, you should assign priorities, responsible individuals and appropriate timescales for completion.  

Reporting to senior management

For incidents only (not near misses), you should make an overall assessment of your organisation’s incident response and recovery capability, based on: 

  • the type of incidents experienced
  • frequency of the incidents experienced
  • nature of the incidents experienced
  • key performance indicators from incident response processes

This analysis should be fed into your risk management processes and reported to the senior information risk owner (SIRO), allowing them to make informed judgments about your organisation’s incident response capability.

Your reporting to senior management should be seen as a way of formally documenting opportunities for continuous improvement. You should be able to take forward actionable improvement activities and integrate them into your future resilience plans.

Using ‘what if’ / ‘if only’ scenarios for lessons learned 

For cyber incidents, you should use ‘What if’ / ‘if only’ scenarios identified in your post-incident analysis to drive improvements.   

The examples in the table below show how this might work in practice. 

‘What if’ / ‘if only’ scenario Potential improvement to consider

Ransomware affects a small number of administrative systems.

What if the attack had spread to clinical systems across multiple sites?

Implement regional partnership arrangements with other care providers to support continuity of care during widespread disruption.

Implement network segmentation and strong boundary controls.

A critical vulnerability is identified in an internet-facing system and patched before any evidence of exploitation is found.

What if the vulnerability wasn’t patched for weeks and the system contained large volumes of patient information?

Review asset management processes to ensure vulnerable internet-facing services are identified quickly and included within patching programmes.

Reduce the volume and sensitivity of information stored on publicly accessible systems where possible.

Electronic patient record system unavailable for 2 hours.

What if it had coincided with severe weather?

Review severe weather plans and include extra contingencies in them so they remain viable when key digital systems are unavailable.

Learning from reported incidents

On top of your own incidents, you should use your knowledge of other reported incidents to drive improvements. You might learn about these through: 

  • threat intelligence and alerts received from NHS England’s CSOC, including via Microsoft Defender for Endpoint
  • NHS England’s Cyber Associates Network
  • NCSC reports and advisories
  • system supplier bulletins and notices
  • industry publications and threat intelligence reports from reputable security companies

Supporting evidence

To support your response, you can upload (or link to) evidence which best demonstrates your achievement of the contributing outcome. Examples include: 

  • incident review process/policy
  • documented lessons learned and post incident analysis activities
  • evidence of methodology and considerations for undertaking post incident analysis exercises
  • list of incidents from the last 12 months
  • evidence of actions take following lessons learned activities
  • evidence of planning to re-test response plans or evidence that re-testing has occurred
  • evidence of policies, processes and systems being updated following lessons learned activities
  • terms of reference and minutes of relevant groups
  • evidence of risk management processes being updated following lessons learned activities

This is not an exhaustive list. You're welcome to provide other types of evidence if you feel they are relevant to the contributing outcome.

Your supporting statement should cross-reference how each piece of evidence provides justification for your achievement of the contributing outcome, including relevant page numbers where appropriate.

National services   

The following national services may help you meet the requirements of D2.b Using incident and near misses to drive improvements: 

Training services | Board training
Training services | SIRO training
Training services | Cyber Incident Response Exercise (CIRE) 
NCSC services | Exercise in a box

Additional guidance

For additional guidance, see:

National Cyber Security Centre CAF guidance | D2 Lessons learned


Last edited: 26 August 2026 12:59 pm