Key Points for Good Disaster Recovery Planning

In some of the previous articles we’ve looked at disaster recovery planning, and I pointed out that there are four distinct areas of planning:

  • mitigation
  • planning
  • response
  • recovery

We took a decent look at mitigation, which we said was eliminating or minimizing the impact of a threat. Now we’re one hundred percent into planning.

Planning is taking all the stuff we normally carry around in our heads and put it on paper. And because technology is a changing process, your plan will also change constantly. The first thing to decide on is how often do you need to update the plan.  It’s recommended to revise the plan twice a year, though some companies do it quarterly or whenever there’s a major change in architecture.

The worst thing you can do is have a great plan, and then let it go out of date. So, you will need an update sheet to keep track of the revisions and mark the changes. Here’s an example:

1

The next part is a good table of contents. This, not unlike everything else, is a subject for update. Here’s a list of things you’ll probably need.

  • Statement of intent. Sounds easy, but in addition to providing guidance on how and what to recover, it should also mention the update schedule.
  • Key personnel. A contact sheet of employees will probably be one of the things that changes most frequently.
  • External Contacts. Another thing that might change quite often are folks like your ISP carrier, vendors, consultants, etc.
  • Triggers and explanations of emergency alerts. Not everything is a disaster: if a non-mission-critical server goes down, that certainly doesn’t demand the same trigger and alerts status of a mission-critical box. This is something you need to decide, having determined what is and what isn’t an emergency.
  • Mitigation. This section should mention what security threats you could face. It doesn’t need to be much longer than a paragraph. List the ways of how they can impact you, and what, if anything, you’ve done to minimize the risk. This might also be a good place to mention backup strategies.
  • Planning itself. In most cases, recovery might be rather simple, but you still need to look at recovering things like files and have a process for database restores. Something that always seems to cause problems is email. More often than not, it seems that someone has lost an email, and they want it recovered. This is often easier said than done and requires restoring entire email databases, mounting drives, and basically doing hours’ worth of work for a few emails. Many companies have adopted a policy of “Unless it’s vitally important to the survival of the company, forget it”. Still, you need to have the process written down.
  • Exercises. A plan is worthless without you at least knowing it stands a chance of working. You should test the plan every once in a while, just to find out what works and what doesn’t.
  • Media. Very few instances that IT might be involved with should require speaking with the Media, and truthfully, it isn’t our job. Media should be handled with no more than a basic guidance (i.e. the contact name and a number in question).

You can read more articles on the topic of disaster recovery in our blog! These posts regard patching,  data loss caused by power outage, four main parts of disaster recovery, most common reasons for a disaster, and reasons of DR plans failure.