When things go wrong... Stemming the effects of disaster within the enterprise

By Bill Raschen

It’s been suggested that the opening years of the 21st century have provided the worst start to any century within the last millennium. The sheer number of large-scale disasters in swift succession over the past five years, ranging from the man-made horrors of 9/11 through to natural disasters such as the south east Asian tsunami and the recent US hurricanes has been remarkable. Under these circumstances, it is perhaps no wonder that disaster recovery plans (DRPs) (otherwise referred to as business continuity plans) have become a hot topic within many organisations in recent times.

From the outset, it’s worth stressing that despite the examples given above, most ‘disasters’ will be localised and much smaller in scale. This is not to underestimate their effects on those involved. Earlier this year, I visited an office that had lost all of its e-mail data, courtesy of a server failure. There was no back-up and the loss of client correspondence, contact and project data was little short of catastrophic. And, of course, disasters are not limited to the workplace. My computer at home is protected by an array of firewall and anti-virus software, which (I speak in smug mode) is updated regularly. Pride goes before a fall – I hadn’t banked on a member of my household deliberately (if unwittingly) downloading a particularly pernicious piece of software that replaced my desktop with a series of intriguing icons for online gaming and Viagra stores. Clearing it up was worse than removing bindweed from the garden.

DRPs have to address the three stages to an emergency: prevention, continuity and recovery. The first of these, prevention, can be summarised in the context of intranet management (and web systems in general) by making sure that proper maintenance and security mechanisms are in place. This will mean the application and maintenance of appropriate firewalls and anti-virus software, while also ensuring that there are rigorous controls on who can access data (something that might have prevented the ‘domestic’ disaster cited above!). In addition, there will need to be a regular maintenance schedule, providing for potential server downtime and system back-ups. Quite simply, you’re taking steps to protect the data on the intranet should the worst happen.

This leads to the ‘continuity’ stage: how to try and keep services going during the incident itself. This will mean the maintenance of core systems, and making sure that continuity measures can be maintained from secondary sites. A list of useful websites discussing this ‘continuity’ stage (and the devising of DRPs in general) can be found at: http://www.londonprepared. gov.uk/business/businesscont/contacts.htm

Finally, the ‘recovery’ stage of a DRP will detail the measures necessary to restore all services to the status that they held prior to the disaster. Although this may just involve the resumption of online services, it could involve a much wider set of contingencies: for example, measures to take when communication facilities, work premises or key personnel are lost.

If these are the main criteria to cover in a DRP, then how should you write the plan itself? According to Paul Chin’s ‘Introduction to Disaster Recovery Planning’ (http://www.intranetjournal.com/articles/200503/ij_03_24_05a.html) the main emphasis is on keeping it as simple and concise as possible. The people who may normally conduct certain tasks might not be available following a disaster, so it makes sense to make reference in the plan to job titles, rather than the names of your colleagues. Also, remember that the individuals who are carrying out the disaster-recovery measures may be acting under extremely stressful circumstances and you may not be on the scene to help them. The timeliness of the measures will also be important: ensure that they are revised regularly and that hard copies of the plans are kept securely at more than one location.

It might seem slightly ironic that the measures for resurrecting potentially mission-critical IT systems such as intranets or extranets should rely so strongly on paper-based DRPs, but there is good sense in so doing. Beyond the formation of the plan itself, there’s also sense in having an in-house disaster recovery steering group comprising colleagues who would contribute to the plan’s development. These colleagues should also be involved in arranging and participating in ‘practice runs’ for any potentially dire situations that might crop up. Of course, when the worst happens, it will be of a nature that you hadn’t anticipated (and at the worst possible time). Nonetheless, the holding of ‘rehearsals’ for catastrophes will almost certainly reveal new issues or problems that you can investigate and resolve in far less stressful circumstances than the real thing.

The moral behind DRPs is, of course, ‘be prepared’. You’ll spend a lot of precious work time devising the plan and then, like any insurance policy, a long period (hopefully indefinite) will go by without you having to use it. But, life being what it is, you can guarantee that if you don’t have back-up measures in place, a catastrophe will strike. No one had anticipated the server failure that resulted in the wiping of an entire office’s e-mails, as mentioned above. Prior creation and application of a DRP might, just possibly, have helped. And, if I’d been more on the case with regards to password control on my PC at home, I wouldn’t have lost an entire Sunday trying to clear up the problem. It is these small but painful examples, that underline the need for DRPs. By spending time on them, you’ll be helping your organisation and making life much easier for yourself.