In our previous instalment of the Disaster Recovery (DR) Plan series we detailed the vital importance that a DR plan plays in ensuring the continuity of an organisation’s key operations in the event of a disaster striking. This article aims to establish and outline the procedures which should be followed and the questions which should be answered through a robust DR Plan. Before beginning the planning process, there are a few simple questions to ask oneself which help highlight the strengths and weaknesses of the DR Plan (or lack thereof!).

• Is there even a DR plan in place?
• When was the backup last tested?
• Is the plan trusted?
• How long can the system realistically be down for until it becomes financially ruinous?
• What is the financial cost of downtime (for every hour, every day etc)?

Define the Disaster
The first stage of the process needs to be to accurately assess the nature of the problem/disaster. Each disaster will be accompanied with a different set of circumstances, each of which may need to be addressed differently. The extenuating circumstances of an unplanned power outage, for example, would need to be addressed in a separate fashion from a full-fledged malicious ransomware attack. To accurately define the disaster you first need to be able to define the following:

• Is the issue local to one machine or does it impact the entire system?
• What Indicators of Compromise (IOCs) are used to determine whether a machine has/has not been compromised?
• What systems/workstations are compromised?
• If the issue is local to a certain number of machines, do these machines need to be immediately isolated from the system?
• Have any files been deleted? If so, when were they last backed up? Where are the backups being stored?

Define the Disaster Recovery Team

Before a disaster strikes, there needs to be a team in place with clearly defined roles and objectives ready to be implemented in the event of an incident. Taking the time to ensure that there is a team prepared who are all aware of their respective roles will prove critical during the initial stages of the disaster as it minimises the risk of losing precious minutes through uncertainty and duplication. Within the implementation team the following information should be available:

• Who is responsible for ultimately initiating the DR Plan? Are they aware of the various criteria which need to be met in order to invoke the DR Plan? It is vital that redundancies are built into this stage of the process.
• Is there a clearly defined out of hours (OOH) process in place to contend with the likely event that an incident will occur OOH?
• How & when will you engage with your MSP as part of the process? Are there contingency plans (names, contact numbers, email addresses etc) in place for contacting your MSP OOH?

Establish Recovery Goals
Remember, from our last article (link), a defining feature of a Disaster Recovery Plan differentiating it from being merely a data backup is that it establishes a roadmap for returning business operations to their standard capacity as quickly as possible. With this definition firmly in mind there are several considerations which must be taken into account:

• Do you prioritise restoring the system, the data or both simultaneously? Should resources be devoted to recovering files and folders before system recovery? The ordering of events will differ depending on the type of disaster; for example, a ransomware attack would require a separate procedure from an unexpected power outage.
• Has a thorough inventory of business essential applications and users been conducted? Have steps been taken to prioritise the restoration of this crucial data when setting the Recovery Point Objective (RPO) and Recovery Time Objective (RTO)?
• What is the overall RPO and RTO?

Select the Appropriate Recovery Type
To embark on your road to recovery, the appropriate recovery procedure must be followed. There needs to be plans in place for recovery for each type of disaster envisioned. The varied circumstances and desired end goal will influence the best approach used:

• File recognition OR
• Local virtualisation OR
• Off-site virtualisation.

Verify the Recovery – Confirm Functionality with End Users
Once recovery has been verified (in the event of malware intrusion verification involves ensuring that the virus has been totally excised from the system) the penultimate step in executing the DR Plan is to confirm that functionality has been restored to end users. By definition, once functionality has been restored to the workforce the organisation can return to its standard operating capacity. Verification of functionality can include:

• Testing network connectivity.
• Ensuring all users can access the required resources and applications.

Assessment
An important, yet often overlooked, component of the DR Plan procedure is evaluating the efficacy of the plan when everything has been said and done. This is an excellent opportunity for improvement for any future disasters. How well did the team perform? Were sufficient resources correctly allocated to the right people to enable a swift rollout of the plan? What weakness in current security processes precipitated the failure? Ultimately, what can be done better in future DR scenarios?

Pamela Keane, Service Delivery Manager, Datapac.

Follow us on Twitter and LinkedIn to stay updated