Business continuity and disaster recovery - part 3 (7.2.1 - 7.2.2)

Testing the plan can generally be done in 2 ways - through live testing (simulation/active testing) or through desktop-based scenarios.

This can take the form of more active penetration test with a threat actor with a defined target, for example bring down a system.

The testing can take place in a live environment or sand pit. It is important that if undertaking the testing in a live environment that you are confident the live environment will not be negatively affected. Conversely, if using a simulated / sand pit environment, it is important that it is a true reflection of a live environment to be representative.

The person undertaking the role of the threat actor should not be the person who would normally be on the incident response team and would normally not have 'insider knowledge'. Unless the scenario is of a disgruntled former employee.

Any live test does have many limitations as it must occur at a known time when the response team is already gathered, and the effect would have to be detected by the team. In a real scenario the time of the event will be unknown, and effects may not be flagged.

This should form a realistic scenario and a frank and honest appraisal of your response. The goal of desktop testing if to identify gaps in your response in terms of people, processes and technology. These gaps should inform improvement actions that help your future response to any data security incidents.

These test(s) need to occur at least annually and have board level representation.

It is highly recommended that you utilise National Cyber Security Centre (NCSC)’ Exercise in a Box’ for desktop testing.

Exercise in a Box is an online tool from the NCSC that helps organisations test and practise their response to a cyber attack:

• it's completely free and you don’t have to be an expert to use it
• the service provides exercises, based around the main cyber threats, which an organisation undertake in its own time, in a safe environment, as many times as it needs to
• it includes everything you need for setting up, planning, delivery, and post exercise activity, all in one place
• to use Exercise in a Box you need to register for an account, which enables the provision of a tailored report, helping organisations identify their next steps and pointing toward guidance that is most relevant for the organisation

It is recognised that the exact makeup will vary and be dependent on the size and nature of the organisation. The table below makes some recommendations of the type of roles, with an understanding that some roles may be merged.

An example of an attendance sheet is shown in Useful resources.

Exercise scenarios should be based on incidents experienced by your and other organisations, or are composed using threat intelligence. 

This should be since 1 July 2021 with active board and business representation.

The type of scenarios should be related to the most likely data security incidents. Some suggestions for the type of incidents are included in Useful resources. Three of the most likely scenarios should be undertaken.

During the test, the scenario should be explained to the incident team with replies and queries logged. The chair should probe the answer, not taking the response at face value, and develop the scenario. The intention, like any testing, is to identify areas for improvement. An example of a log of test is shown in Useful resources.

Where you find gaps, you should log them (together with a name to look at them), however the exercise should not be overtaken by solutions analysis. The primary purpose is to identify a gap and then move on.

Post testing a full action plan should be drawn up with allocated names and dates. This should be followed up. An example action plan is contained in Useful resources.