D1. Response and recovery planning

Created:  28 Jan 2018
Updated:  31 Oct 2018


There are well-defined and tested incident management processes in place, that aim to ensure continuity of essential services in the event of system or service failure. Mitigation activities designed to contain or limit the impact of compromise are also in place.


Incidents will invariably happen. When they do organisations should be prepared to deal with them, and as far as possible, have mechanisms in place that minimise the impact on the essential service.

The particular mechanisms required should be determined as part of the organisation's overall risk management approach. Examples might include things such as DDoS protection, protected power supply, critical system redundancy, rate-limiting access to data or service commands, critical data backup or manual fail-over processes.

The NIS Directive has mandatory reporting requirements around cyber security incidents that have the potential to affect essential services. As well as NIS, organisations will typically have many other internal and external reporting obligations.


NCSC's 10 Steps: Incident Management is the most concise guidance here, but organisations should use other more detailed guidance as and when appropriate. Other authoritative guidance pieces are referenced below.

Preparation - An Incident Response Plan

In addition to meeting the expectations of 10 Steps: Incident Management, you should ensure that your organisation's incident response plans are grounded in thorough and comprehensive risk assessments. Response plans should prioritise essential services along with the assets and systems that are required to ensure their delivery, such as operational technologies, or key datasets.

The business continuity implications of any compromise should also be taken into account and your cyber incident response plans should link to other business response functions. You should form a cyber response team that is capable of implementing the plan, with the appropriate skills, tools and reach into other parts of your organisation, such as security monitoring and business continuity. 

In practice, the Incident Response function should interoperate with the security monitoring function. The Incident Response Function needn't be a dedicated team and some members may have non-response related roles. Collectively, the team should have knowledge of IT security, IT infrastructure and Business Management, any specialist technologies (e.g. Operational Technologies or datacentres), incident reporting requirements, and Communications plans. 

Your plan should cover all relevant potential incidents. It should be auditable and testable (via exercises) across a range of incident scenarios and should encompass all realistic descriptions of what might constitute an incident and its severity. Your test scenarios should draw on threat intelligence, past incidents, exercises and the ways in which security capabilities (e.g. security monitoring and alerting) would feature in your response options. Your scenarios should also consider incidents that involve suppliers and your wider supply chain (e.g. incidents arising through supplier relations, or relying on suppliers as part of your response).

These scenarios could include, but is not limited to: 

  • malware infection
  • denial of service
  • hacker infiltration
  • an Insider Incident
  • an inability to view status of the network or operational system
  • emergency patching or antivirus signature roll-out
  • system backup and restore
  • confirmation of normal operations

Your plan should work seamlessly with other system management and security functions, such as security monitoring. Changes and improvements to response plans should reflect changes to these functions and vice versa, where appropriate.

Plans should articulate clear governance frameworks and roles with procedures for reporting to relevant internal or external stakeholders, such as regulators and competent authorities.

Your plan should also set out a comprehensive range of containment, eradication and recovery strategies, specifying how and when they should be used.

Your organisation should be able to describe its own state of readiness, using any criteria or expected standards from regulators or competent authorities, or from your internal governance arrangements, where appropriate.

You should run exercises to test your ability to respond to incidents that could affect the delivery of essential services. These exercises should reflect past experience, red-teaming/scenario planning, or threat intelligence and should draw heavily on your risk assessment, considering all relevant assets and vulnerabilities, especially where they relate to essential services. 

Exercises should record lessons learned, covering governance, roles and internal communication, quality of network and security monitoring data, containment and recovery strategies, or any other factors relevant to their effectiveness. This should integrate with lessons learned activities (see D2 Lessons Learned).

In order to report coherently on incidents when required, your plan should set out reporting thresholds (i.e. what does and does not need to be reported) and standards (i.e. the level of detail that should be reported) and which authorities to report to.

More detailed guidance on developing an incident response plan, and the underlying capability to implement it, can be found in Section 2 of the NIST Computer Security Incident Handling Guide, Part 4 of CREST Cyber Security Incident Response Guide or the Prepare section of ISO 27035.

Response and Containment

Your organisation's security monitoring function should be capable of alerting with enough detail for a response team to triage and determine the most appropriate response, which might be to investigate further, to take predetermined action, or to take no action. Eventualities not covered in the plan should be dealt with by risk-based decisions, taking account of factors like potential disruption, cost-effectiveness of response and the need for evidence preservation.

The resilience measures your organisation has in place should support incident response (see B5 Resilient Networks and Systems).

Incidents should be reported to the appropriate internal and external authorities, in line with the relevant reporting thresholds and standards. The response team should be capable of prioritising incidents, according to the potential consequences and disruption to essential services, using risk-based methods. These events should be documented, including alerts provided, information passed and decisions taken.

In addition to adhering to mandatory reporting requirements, organisations should seriously consider voluntarily reporting cyber security incidents to the NCSC, who may be able to provide situational awareness, drawing on incident reporting from other victims, as well as response and protective security advice.  Assistance may also be sought from Cyber Incident Response (CIR) companies - see CIR scheme

Further guidance is found in Section 3 of NIST Computer Security Incident Handling Guide, Part 5 of CREST Computer Security Incident Response Guide or Part 4 of ISO 27035.

Physical resilience (Advice supplied by DCMS)

Your organisation should have a strategy for ensuring the continuity of essential services in the event of a physical failure in the network and information systems. This can be achieved through measures such as contingency plans for critical systems, including clear steps and procedures for common threats, triggers for activation, steps and recovery time objectives.

Your organisation should also consider having documented policies or procedures for coping with major disasters and recovery of capabilities. This could include plans for alternative solutions such as mobile equipment, mobile sites, fail-over sites, etc.



10 Steps: Incident Management

NIST Computer Security Incident Handling Guide

CREST Cyber Security Incident Response Guide

Prepare section of ISO 27035

CIR scheme

ENISA Good practice guide for incident management

ISO/IEC/27001:2013 A.17.1

CCS: 5.12 Backup, 7.2 IT Service Continuity Management

ENISA Technical Guidelines for Digital Service Providers: SO17, SO18



< Back to Principle C2                 Forward to Principle D2 >

Was this guidance helpful?

We need your feedback to improve this content.

Yes No