Principle: D1 Response and recovery planning

Overview

This contributing outcome relates to you having an incident response plan, or a suite of plans, covering an appropriate range of scenarios, informed by an understanding of your organisation’s risks.

In the scope of the Cyber Assessment Framework (CAF)-aligned Data Security 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 (NIS).

Incidents

In the scope of the CAF-aligned DSPT, 'incidents' refers to:

• personal data breaches – a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. This includes breaches that are the result of both accidental and deliberate causes
• breaches of confidence relating to other confidential health information – such as belonging to deceased people or the organisation 
• events which have an actual adverse effect on the security of network and information systems

As such, 'incidents' under the CAF-aligned DSPT comprise adverse events from across the domains of information governance (IG), cyber security, emergency preparedness, resilience and response (EPRR) and business continuity, bringing them under one assurance umbrella.

You may have separate mechanisms, and separate teams, for dealing with these incidents within your organisation. You're free to categorise and allocate responsibilities for incident response in whatever way works best, provided it's clear how the indicators of good practice of the CAF-aligned DSPT framework have been implemented.

It is essential that potential impacts of incidents on clinical activity and patient safety are considered and mitigated in incident response plans.

Incident response plan

Your incident response plans should support your incident management process. Plans should include, but not be limited to:

• key contacts - covering anyone who would need to be involved in the incident response process - for example, data protection officer, IT managers, senior information risk owner (SIROs) and senior management (in particular chief medical lead, chief nurse, patient safety lead, chief clinical information officer and chief operating officer, registered manager), legal teams, HR, comms, system partners. Consider the risk of people being unavailable and include back up contacts.
• roles and responsibilities - defining which groups or individuals are responsible for different elements of an incident response.
• escalation criteria - covering appropriate escalation routes along with a process for escalation and making critical decisions.
• alternative service provision – covering how safe care can be provided in an alternative way if an incident could potentially impact on the care or safety of patients and service users.
• flowchart or process - this should cover the full lifecycle of the incident (such as preparation, detection and analysis, containment, eradication and recovery, post-event activity).
• guidance on regulatory requirements - including the appropriate thresholds for external reporting and notifying impacted individuals.

This is a basic plan. NHS England has published a national incident response plan that may provide a useful reference point for how processes and responsibilities can be clearly set out within your documentation.

For more information on creating an incident response plan from a cyber security perspective, see NCSC guidance. For more information on incident response from a data protection perspective, see guidance from NHS England on personal data breaches and information risk and impacts to individuals following personal data breaches.  

Known and well-understood incidents and attacks

At the 'Partially achieved' level, your response plan(s) should be shaped with known and well-understood incident and attack scenarios in mind. Examples include: 

• Data breaches - incidents resulting in the confidentiality, integrity or availability of information being compromised. Data breaches are often a component of other incidents such as:
  • confidentiality breach - emailing files in error, failing to redact personal information from public disclosures, unauthorised access to information, devices being lost or stolen
  • integrity breach - editing a patient record in error, misfiling test results
  • availability breach - deleting information in error, being unable to access information in the aftermath of a cyber attack
• Phishing - emails attempting to convince someone to trust a link or attachment
• Malicious code - malware infection on the network, including ransomware
• Denial of service - typically a flood of traffic taking down a website, can apply to phone lines, other web facing systems, and in some cases internal systems
• Targeted attack - an attack specifically targeted at the business - usually by a sophisticated attacker (often encompassing several of the above categories)

You should also use knowledge you have gained from previous incidents, your organisation’s known risks, trusted professionals and open-source reporting to establish known and well-understood threats to the confidentiality, integrity and availability of data upon which your essential function depends, and shape your response plan(s) accordingly.

Suppliers and system partners

It is likely for third parties to be involved in the operation or maintenance of some of your essential systems. For example, suppliers who process data on your behalf, or system partners who share access to repositories owned by you for providing care.

Mounting a response to any incident where third-party supplied systems are affected, or where an incident originates with a supplier, will entail your incident response team working closely with those third parties to contain the impact and put appropriate mitigations in place. Your incident response plan(s) should show that you have appropriate measures in place to facilitate this, including requesting important information from the supplier where necessary such as log files.

Incident reporting

You should notify incidents via the DSPT incident reporting tool in accordance with the DSPT Incident Reporting Guidance.

If the incident meets the necessary thresholds, details will be sent to the Information Commissioner's Office (ICO) as the supervisory authority and, depending on impact and nature (such as a network and information systems incident), the DHSC or NHS England.

Your board (or equivalent) should be notified of the incident including any associated action plan, which should encompass dealing with the risks and impact of the incident and lessons learned.

Readily accessible response plan 

Your incident response plan should remain readily accessible, even when your IT systems are affected by an incident. 

You can make sure this happens by:   

• keeping controlled paper copies of your incident response plan in agreed locations
• storing copies of your incident response plan on offline devices or devices which are outside of your normal IT environment   

Not everyone involved in responding to an incident will be able to access your response plan from these locations. You should therefore have arrangements for sharing instructions and coordinating activities with key incident response stakeholders that don’t rely on methods of communication that would be impacted by your IT systems being affected. 

Obligations as a controller or processor

As a controller, you're legally obliged to notify personal data breaches to the ICO within 72 hours where the breach is likely to result in a risk to the rights and freedoms of individuals. This should be done via the DSPT reporting tool. You also have a legal obligation to inform the data subjects (such as patients or staff) who have been impacted by a breach which is likely to result in a risk to their rights and freedoms.

Processors also have a legal obligation to promptly notify controllers in the event of a data breach.

For more information, see NHS England guidance on personal data breaches.

Obligations as an Operator of Essential Services (OES) under NIS

Under the network and information systems regulations, operators of essential services (OES) have a legal duty to report any incident which has an adverse effect on the security of network and information systems and which has a significant impact on the continuity of an essential service within 72 hours. This should be done via the DSPT reporting tool.

For more information, see DHSC guidance on network and information systems regulations.

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 response plan(s)
• evidence of impacts to patient care being considered and mitigated where relevant 
• evidence of incident response plan being approved and distributed to relevant staff members 
• report of the latest incident involving personal data 
• evidence of communication plans / channels with system partners to coordinate incident response
• image of policy repository (shared on screen) 
• risk assessment for each essential function 
• evidence of cross-organisational understanding of the incident response plan(s)  

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

National services   

The following national services may help you meet the requirements of D1.a Response plan: 

Training services | Board training
Training services | SIRO training
Training services | Cyber Incident Response Exercise (CIRE)
Security services | Respond to a cyber alert
NCSC services | Exercise in a box 

Additional guidance

For additional guidance, see:

National Cyber Security Centre | D1 Response and recovery planning
National Cyber Security Centre | Incident management
NHS England | Personal data breaches
NHS England | Information risk and impacts to individuals following personal data breaches

Overview

To meet this contributing outcome, you need to ensure you have the capability to enact your incident response plan.

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).

Resources for response activities

As part of your planning for foreseeable incidents, you should designate clear roles and responsibilities. Formation of a capable incident response team with the necessary skills, tools, and reach within the organisation to mitigate the effects of incidents is critical. 

Given the unpredictable nature of incidents, you also need to make appropriate arrangements for how response activities should be coordinated out-of-hours.

Where relevant, the plan should also consider resources required for the likely continued demand on clinical services during and after the incident. For example, additional resources may be required to ensure temporary paper-based systems are managed appropriately, and that backlog loading to an EPR after the incident is handled with expertise to cause minimal disruption to ongoing clinical activities.

With advanced planning of the activities which fall under each person’s remit, your organisation should be able to practically assess its capability for responding to potential incidents.

Necessary information for response teams

Your response team may require access to several types of information during an incident, which include but are not limited to:

• incident response plans and supporting procedures
• contact details for other supporting teams and external stakeholders 
• monitoring and alert information
• detailed hardware and software engineering information, network diagrams, system descriptions and functional specifications 
• asset registers with lists of critical sites and systems
• authorisation requirements
• communication plans
• evidence of post incident analysis activities

You should consider how this information would be made available to your incident response team, including contingency plans if business-as-usual methods of communication and transferring files are compromised.

Skills and knowledge 

Your training needs analysis should identify any competency gaps within your teams which might impact:  

• your ability to limit harm during an incident
• the operation and recovery of your essential function during an incident 

Your training needs analysis should show how you plan to address these. 

For more information, see NCSC’s guidance on building a response team. Please note that NCSC guidance is written from a cyber security perspective. Your organisation’s response team should also include information governance specialists who know how to manage personal data breaches in line with ICO guidance. 

Sharing knowledge 

You must share knowledge across your incident response team, and duplicate key roles. For your organisation’s purposes, you should assure that your incident response team can perform its role with a reliable degree of confidence, regardless of whether key members of the team are unavailable (due to annual leave for example).

Back-up/fallback mechanisms

It is possible for your systems to fail during an incident, or for them to be intentionally restricted to contain the impact. This could be one system, several systems, or all of them (such as in the event of a power outage). Your risk assessments should evaluate the resilience of your existing systems under such conditions, and identify any back-up/fallback mechanisms or solutions that would be needed to deliver your essential service. These could be temporary solutions which keep your operations functioning at a reduced level.

Back-up/fallback mechanisms could be employed within your organisation, for example, moving to paper-based systems where online booking systems become unavailable. However, it is also important to consider whether and when you might ask for support from other health or care providers, in particular to ensure patient and service user safety, and factor this into your response capability planning.

The impact of network and system compromise should be considered from a time-bound perspective. If systems can be down for a significant time period without causing unacceptable consequences, or mitigations you already have in place mean that systems would be recovered before any unacceptable consequences could occur, you could rationalise a judgment that additional back-up/fallback mechanisms are not needed.

Augmenting incident response capabilities

You should identify sources of external support in your incident response plans such as NHS England central teams, specialist suppliers and law enforcement, and establish when, how and under what conditions they would be engaged. Where external specialists may be used, appropriate contractual arrangements should be in place.

You should also have arrangements pre-agreed with suppliers, vendors and any third parties on which your essential functions depend to ensure they are committed to providing support during times of incident response. 

Given the nature of incidents, your arrangements should cover out-of-hours scenarios as well as those that can be responded to within business-as-usual hours.

Supporting evidence

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

• Incident response plan(s) 
• Evidence of scenario planning 
• Latest tests of scenario plans 
• Documentation of the latest training attended by the response team 
• Skills analysis or training needs analysis 
• Evidence of established chain of command during incidents 
• Response team organisational chart 
• Documentation of information sources and methods of gaining access to information required for incident response 
• Evidence of back-up mechanisms being identified for continuation of services 
• Assessment of acceptable levels of operation of essential functions for example recovery time objective (RTO), recovery point objective (RPO) etc. 
• Agreement/contract with external support provider or process includes contacting NHS England for CIR services 

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

National services 

The following national services may help you meet the requirements of D1.b Response and recovery capability: 

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 | D1 Response and recovery planning
National Cyber Security Centre | Incident management
NHS England | Personal data breaches

Overview

This contributing outcome relates to your implementation of tests and exercises to assess the readiness of your people, processes and technologies for responding to incidents.

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 and care 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).

Incident response and recovery testing

Your organisation can conduct exercises to assess its readiness to respond to an incident, and improve its policies and procedures. Exercises could include:

• orientation/walkthroughs
• table-top exercises (TTX)
• live exercises
• functional testing of sections of your response plan
• full scale test of all elements of your response plan
• activation of disaster recovery plans
• communications tests – suppliers, emergency services, media, the public for example

The aim of these exercises is to test your communications channels, decision making, your incident response team’s composition and their technical capabilities to use tools and data in the event of an incident. The activity should help you identify any barriers to sustaining your normal business operations and minimising negative impacts.

Findings should be used to:

• reinforce roles and responsibilities
• identify gaps in your response plan
• agree and assign specific time-bound actions to address the gaps

For more information, see NCSC’s guidance on cyber exercise creation. 

Additionally, see NHS England’s cyber incident response exercises for pre-made practical scenarios which can be used to test your organisation’s response functions.

Using threat intelligence to design exercises

The tests and exercises you conduct should be informed by your knowledge of previous incidents, your organisation’s risk profile, and available intelligence from external sources on threats and threat actors in the health and care sector. As a result, you should be able to design your exercises to be practical, appropriately challenging to meet the complexity of threats you face and relevant to your operating environment.

Keeping a record of the information sources you use for intelligence gathering, as well as your engagement with professionals in your wider network, will better enable you to demonstrate how you acquire and use intelligence to support your designing of tests and exercises.

Organisations using the Cyber Incident Response Exercise (CIRE) training service will generally meet the requirements of:  

• D1.c A#1, which relates to using experience and threat intelligence to design exercises
• D1.c A#2, which relates to documenting, regularly reviewing and validating exercise scenarios 

Testing all parts of the response cycle 

You should test all parts of your incident response plan to ensure you would be able to restore business operations in the event of an incident. 

You will need to consider how to design exercises to ensure your people, processes and technologies have been tested. You do not have to test everything at once – it is sufficient to target specific areas with different exercises – but the overall result should be you having confidence in your organisation’s array of competencies, governance and tools for responding to incidents. 

Organisations using the Cyber Incident Response Exercise (CIRE) training service will generally meet the requirements of D1.c A#4, which relates to testing all parts of the response cycle. 

Supporting evidence

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

• Threat intelligence sources 
• Exercise scenario documentation 
• Schedule for testing and exercising activities 
• Evidence of lessons learned and actions taken following testing and exercising activities 
• Procedures for updating testing and exercising activities over time 
• Incident response plan(s) 
• Evidence of updated incident response plan being communicated to all relevant stakeholders

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

National services  

The following national services may help you meet the requirements of D1.c Testing and exercising: 

Training services | Simulated phishing exercise
Training services | Cyber Incident Response Exercise (CIRE)
Security services | Technical Remediation
NCSC services | Exercise in a box 

Additional guidance

For additional guidance, see:

National Cyber Security Centre | D1 Response and recovery planning
National Cyber Security Centre | Effective steps to cyber exercise creation