two 300 word discussion and one 150 word response.APA format

Discuss documents that need to be included in recovery documentation.

The most important part of the documentation for a DR plan is step by step instructions on what to do and how to do it.  In the best of circumstances, you will have your top database administrator (or your only DBA) there to do the process.  In the worst of circumstances, you will have “Sam the Security Guard” doing the recovery.  This is important to take into account when documenting the plan. The disaster recovery (DR)/ business continuity (BC) process encompasses many different activities. One of the most important areas to be addressed often as a secondary activity is disaster recovery documentation. Naturally, BC and DR plans, exercises and a variety of analytical reports are likely to be documented. But what other important documents should you include in your DR/BC operation? This article provides several disaster recovery and business continuity checklists of important and useful documentation for your DR/BC program.

All the information needed to recover the database and application should be explained in such a way that anyone in the company could perform the recovery.  This makes the process much more challenging. Next you need to document which applications are critical to the business running and which ones can wait.  The documentation should be printed out and stored safely AWAY from the computer room and the production building.  The documented, thorough, “pretty” plans that failed to get outside of the PC in the computer room. Other things that you should document in your plan include:

Internal contact information (including cell and home phone numbers) for everyone that could, would, or should be involved in the recovery effort.

Copies of contracts with all your 1st, 2nd and 3rd level vendors.  For example, what is your relationship with your telephone company?  What is their guarantee to you for availability (this is your Service Level Agreement or SLA with them)?  What is your hardware DR plan?  Is your software support and DR planned the same as your hardware?

External contact information – is there someone specific at your DR site that you need to contact?  Do you just call the front desk and ask for Joe?  What if Joe is not there?  What is the process to get the ball rolling?

Specifications for all the critical resources – If you are failing over to a data center that is shared with others the last thing you want is to be in a position of having a generic system waiting for you that does not fit the OS/Java/HW requirements for the application to run.

Who pushes the button?  Who makes the decision to go to backup or failover to the DR site? 

Document this and have a chain of command for who is in charge if all the executives are out of town.  The Incident Command System (ICS) from FEMA is an excellent example of how to design your DR organization.  More importantly, get the executive team to commit – in writing

that the people that have been identified have the authority to make the decision to fail over.

There are many other things that could go into a plan. 

Reference:

J Schwab, KC Topping, CC Eadie, RE Deyle, RA Smith - 1998 - nehrpsearch.nist.gov

Bijan Khazai, Farnaz Mahdavian and Stephen Platt, Tourism Recovery Scorecard (TOURS) – Benchmarking and monitoring progress on disaster recovery in tourism destinations, International Journal of Disaster Risk Reduction