All businesses, regardless of size, should have some sort of Disaster Recovery Plan (DRP) in place. Even a sole trader will be in trouble if his/her computer goes down, denying all access to programs, outstanding order details, billing and shipping addresses.
Having a DRP in place is only Half the Battle
Having a good DRP in place is only half the battle. Knowing how to implement that plan, and making sure that the plan works as it is meant to, are both equally important factors too – in fact more than that – they are essential. Finding out that the plan cannot be deployed for any reason, or that it has failed to take some important aspect into consideration, may well prove to be as bad as not having a plan in situ in the first place.
In fact, in 2011 it was found that only 57% of companies have DRPs in place, something that could prove, well, disastrous for them in terms of loss of business and assets. Indeed, according to IBM: “[E]ven among those who do have a plan in place, 75 percent report that efforts are likely to be ‘haphazard’ and ‘untested’”.
DRP Testing is Essential
The IT department cannot afford to take any chances. It’s the business’s very existence that could be at stake. The only way companies can be sure, is to test out both the integrity and the practicality of actually implementing its DRP.
Managing Change
One of the most common problems when it’s comes to actually implementing a DRP is finding out that a change in circumstances (whatever those changes are – be it in personnel, system infrastructure, software, or programming) has not been reflected in the DRP.
The Change Control Process
Every DRP should therefore have a Change Control Process in place too, and this process must be bought into play when any circumstances change. It not only helps to keep the DRP current, but it also clearly shows to any interested parties, exactly what the current status is. This is particularly important if there are any changes in personnel, especially if those changes involve IT personnel, IT management, or anyone else involved in the DRP deployment process.
The Importance of DRP Testing
DRP testing should be thought of in the same way as carrying out a fire drill. It’s absolutely essential; in this instance, not for the health and safety of the staff, but for the health and safety of the company itself.
Interval and Frequency
Fire drills are often considered to be an inconvenience, and so too are DRP tests. However, that is no excuse to avoid them. Carrying out a full DRP test can usually only be done periodically due to the disruption that it causes. It is therefore recommended that companies should do part system testing, at least at quarterly intervals, with a full DRP check on an annual basis. It’s also something that can be outsourced to a consultancy service and controlled by them at a time when there less impact on normal working hours.
Multi-site Locations
Many organisations have multiple locations, whether these are all independent entities at various locations across the country, around the world, or whether they are remote data storage facilities and/or disaster recovery facilities. Where this is the case, each location must be independently tested in its own right.
The Difference between a Disaster Recovery Plan and a Business Continuity Plan
A comprehensive Disaster Recovery Plan must leave no stone unturned in terms of the infrastructure of the IT setup. But it should be clearly borne in mind that the Disaster Recovery Plan is about recovering from a disaster that has taken place, whereas a Business Continuity Plan (BCP) is all about anticipating and mitigating the threats that could cause a business disaster, but before they happen. BCPs are preventative, while DRPs are reactionary.
The DRP is focused on IT recovery strategies in terms of networks, servers, Personal devices (including PCs, Laptops Tablets and Smartphones) and data and connectivity.
The Importance of Back-ups
One of the most critical parts of any IT DRP is ensuring that a stand-alone independent backup is made of all data. This backup should ideally be kept offsite in a remote location, or at least in a fireproof safe on the premises and there really should be more than a single copy.
Back-ups should be run, in a worst-case scenario, at the end of each working day.
Any critical software applications need to be clearly identified as does any essential data, and the hardware needed to run. The software and data should be replicated and kept in a safe place. Replacement hardware should be available which can then be reconfigured with this information, thereby replicating the existing setup “as was” before the disaster occurred.
Remote Disaster Recovery “Hot Sites”
Some companies prefer to outsource their disaster recovery programs, thereby keeping copies of the appropriate software and data at specified “hot sites “provided for this purpose by an outside vendor.
In such an out sourced DRP scenario, the service provider often monitors the integrity of the service users IT infrastructure. In the event that an outage is detected, the vendor will automatically retain data until the client’s IT system is fully recovered, and or made ready to receive the data back to enable full system restoration.
The DRP Deployment Team
The final piece of the implementation process of the disaster recovery plan is to ensure that members of personnel who are actively involved with any component of the DRP and its deployment, are kept fully up-to-date. They must be au-fait with any changes that have occurred to the DRP via the change control process procedure mentioned earlier, and must also fully briefed with regard to the nature of the current disaster.
Chain of Command
Authority to put the DRP into action should only come from one person within an organisation. A chain of command will need to be established is in the event that anyone is absent or incommunicado
A recovery plan is essential for every business and whilst they can be somewhat of a headache in the planning and implementation stage, can your company afford not to have one?
