Classify disaster levels

I like it, Mr. Talon outlines a clear way to organize disaster responses, which can sometimes be a big problem. I intend to incorporate this breakdown into my own DRP. Thanks for the advice.

Mike's analogy to the British Army methods of attack is known as graduated response. Military organizations around the world have used this method for years to train soldiers, as well as using it now to respond to threats. It works. Applying it to the technical recovery field is a sure-fire way to illuminate and identify how to respond to disaster in an orderly fashion, reducing your downtime and accomplishing every IT technician and managers primary goal - maximize up time of your network and systems.

Mike,

Thanks for the insightful content. I will with out a doubt incorporate this approach into my company's DR plan. Currently they use scenarios, but I have never been a fan of scenarios because they usually are too specific. This method is a good combo of scenario and generality.

Well done article!

-Brad

Talk about punching a button!

My CEO asked us to do a Phase 1 DR plan, in preparation for a full Business Continuity Plan (kudo's to him for understanding the difference).

He gave me 5 scenarios he wanted in the Phase 1 DR Plan. Yet, our Service Desk (ITIL based) has Priority derivived from Impact and Scope.

Why isn't our DR plan setup this way too?

I'm rubbing my chin mapping and re-evaluating this right now.

An excellent wake up call.

Don

"By clearly classifying the level of the disaster ... you can immediately bring your entire staff up to speed..."

So much time is indeed wasted trying to explain what has happened and how it pertains to your certain area of the company/dept. If everyone has the foreknowledge of what the levels mean, then time can be spent on how it is affecting your area and what is being done or needs to be done.

I would recommend that he include a further classification in a matrix form that would provide some additional detail. There are times that hardware might not be impacted but software would by the threat. So maybe an additional word or phrase like:
Level 1 hard
Level 3 soft
Would elaborate where the focus might be. This could be expanded to include something like the machine threatened or impacted and the application. For example:

Achilles, hard 0, soft 3, OS

Someone would know that the server named Achilles has a level 3 impact to the OS that does not impact the hardware.

A great idea! Everything neatly explained in a small package. If only the industry would standardize to this concept!