Should It Be In The Plan?

A question which confuses many people is whether a document, data, or procedure should be included in the business continuity or disaster recovery plan, or should it simply be referenced by it. As so often is the case, it's a trade-off...

When writing a plan you are often faced with a choice: should I include this in the plan, or should I reference it? As with so many good questions, the answer is “it depends”.

The advantage of including data as part of the plan is that it makes the plan self-contained. Conceptually you can grab the plan as you leave the burning building and you have all the information you need to recover the organization's business functions. There's nowhere else to look: everything is there.

The disadvantage, of course, is one of maintainability. Will the data in the plan be kept up to date? There's an old joke told by David Allen, author of Getting Things Done: a man with one watch knows the time; a man with two watches is never really sure. If information is duplicated, sooner or later one copy will disagree with the other.

So the real answer is that this is a trade-off between convenience in an emergency and the maintenance headaches of the planner.

You should therefore put the item in the plan if:

  • It's needed immediately: you can't afford to waste time looking for it. (e.g. emergency telephone numbers of contractors, methods of contacting staff.)
  • There's no other sensible place for it. (e.g. recovery resources, hot site information.)
  • The data is not being actively maintained elsewhere. (If it is included in the plan, it will at least be subject to regular review with the business continuity plan).
  • The data is not in a place where it can always be retrieved in a timely manner following an incident.
  • Confidentiality constraints dictate that the information can't be readily accessible elsewhere. (e.g. home phone numbers and addresses).

You should keep your item out of the plan if:

  • The data is actively maintained and is accessible elsewhere. (IT recovery procedures frequently fall in this category.)
  • The data can be recovered before it is needed. (e.g. if you can recover the list of key customers or suppliers before you need to contact them following an incident, it doesn't make sense duplicating it in the plan).
  • Confidentiality constraints mean that it can't be in the plan. (e.g. computer, bank, alarm passwords — you need to keep these in a safe place somewhere else.)

In both cases, the secret is to put procedures in place to make sure that updates to any external data that is included in the plan or may affect the plan will trigger corresponding updates in the plan. This will nearly always include procedures to track staff changes and reassignments: these will typically affect the choice of recovery team leaders and key team members.

23 February 2007

To get notified when new articles appear, subscribe to the Risky Thinking Newsletter. It's low volume: we don't send out an issue unless there is something interesting to say. You can also subscribe to our RSS Feed

Recently published articles can also be found here.

Agree or disagree? I'd like to hear your thoughts. Please initially use the contact form to get in touch.