When an incident occurs, steps must be taken to understand its root causes and ensure appropriate remediating action is taken.
If an incident does occur, it is important your organisation learns lessons as to why it happened and, where appropriate, takes 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.
You should use all of the guidance points below to learn lessons and address shortfalls in:
Root Causes and Shortfall
Each incident or exercise should include assessment of root 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 root 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 Sections 3.1-2 of NIST Computer Security Incident Handling Guide, Part 5 of CREST Computer Security Incident Response Guide and parts 2-3 of ISO 27035.
You should use post-incident and post-exercise reviews to actively reduce the risks associated with the same, or similar, incidents happening in future.
Lessons learned can inform any aspect of your cyber security, including:
- System configuration
- Security monitoring and reporting
- Investigation procedures
- Containment/recovery strategies
- Governance and communication around incident management
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.
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).
NCSC 10 Steps: Incident Management
Chapter 8 of ENISA Good Practice Incident Management Guide
Section 3 NIST Computer Security Incident Handling Guide
Part 6 CREST Cyber Security Incident Response Guide
< Back to Principle D1 Forward to tabular layout >