Part of Objective D - Response and recovery planning
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:
Human factors include:
Technical factors include:
Threat factors include:
|
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