DRP Crisis assesment my view

[Mariole]

White Papers on DRP recommends to assess the crisis before invoking the DRP, But none give the detailed list of elements to be assessed,

My approach to close that gap is to create the DRP plan as set of books, each covering DRP elements: procedures, steps, etc... thus providing DRP metrics

Book #1: Scope and principles: To describe the list of services include in the DRP with their associated RTO and RPO, for each service, the capacity rate: we provide 100% of the service feature or 75%... and the principles of the DRP: Data copy, Wan copy, etc.. This section provides RTE: Recovery time Expected and RPE: Recovery Point Expected
Book #2 : Run the DRP : The steps to be followed to activate the DRP. I recall that as the plan needs to be tested, this book will provide the following results: RTA: Recovery Time Actual and RPA: Recovery Point Actual. These metrics are the time taken from the "ground" used to activate the DRP.
Book #3: DRP resumption: The steps to be followed to resume operation as nominal. We calculate the Recovery Elapsed Time: The time used to restart on the nominal state and the Recovery Data Gap: The amount of data that could have been lost when the service has been
Book #4: DRP Crisis assesment: That's the book that deals with the decision to invoke or not the DRP: The purpose is to get answers to these questions:
Is the service to the customer affected by the outage?
Is the service from the current location unlikely to be restored within the contractual RTO
Can the service be restored at a Disaster Recovery location more quickly than in the problem location?
Will the total down for invocation: invoke the DRP+restore back to normal be less than the downtime to restore at the original location?
In it we evaulate the RTO/RTE/RTA/RET and RPO/RPE/RPA/RDP values to detemine if we got to trigger or not the DRP.

Your take dear community?

[grewjac]

Mariole:

It is not necessary to have separate books to determine whether to declare (execute the recovery plan). First, bear in mind this decision is one that will spend a LOT of the company's money very rapidly, mostly dependent upon the recovery solutions that are in place, and how many people have to be dispatched to the recovery site (airfare, hotel, rental car, per diem, as applicable).

But the MOST important question to be answered before a declaration decision is: Based on what is known about the impacts to business operations due to this event (the BIA data: RTO's and RPO's provide this and should be available to the recovery management team), is it better to declare or accept the downside risks of letting critical business operations continue to be shut down? The answer will have to stand up the the post-event scrutiny of the Board of Directors and perhaps the stockholders as well. And let's not forget the market(s) for your company's products and/or services. Those are (or should be) part of the BIA data used in making the declaration decision.

This can all be captured in a single recovery management procedure with references to the source data mentioned above, and it needn't be lengthy. THe most recent one I did was about ten pages, including contact tables for the teams. I also sis a Visio flowchart of the process from "something bad happens" to declaration and team deployment. Also, there's a lot of coordination neccessary between the CIO/IT staff and other departments who have emergency resonse and recoverysupport functions. Your plan MUST address these interfaces, because your teams will probably not be allowed to enter a building until it is deemed safe and your teams have been furnished suitable safety wear and equipment.

Hope this helps.

[JohnGlenn]

I'm easily confused by buzz words and alphabet soup.

For me, when to declare is very simple: Whenever a <whatever> is unable to meet its Service Level Agreement (meet customer expectations), declare an event.

It could be that IT guarantees to provide a 98% up-time during normal working hours.
Let's say that 98% equates to 15 minutes.

A server that holds a database used by profit center staff fails.

If IT is 101% confident it can restore the server within 15 minutes, no declaration.
If IT is NOT absolutely certain the server can be restored within 15 minutes, an event is declared - not waiting for the deadline to arrive.

The same applies to all functional units, both profit center(s) and profit center resources.

If the building cannot be occupied, probably it's time to declare.

If the CxO absconds with the corporate kitty, it's probably time to declare an image event (but we know that since the CxO has an alternate, the job functions will continue as before - the CxO DOES have an alternate, right?).

These declaration triggers - mostly they are common sense - need to be included in the enterprise plan and relevant functional unit plans - an If This - Then This table works for me.

What I do NOT like is having critical related information scattered over hither and yon so the responders have to seek out information where no man has -- sorry, that's Star Trek - anyway, all related information should be in one indexed document and easy identified and accessed.