How to plan a Disaster Recovery Plan engagement

 This blog post is focused on how to plan and scope out a disaster recovery plan. It looks at the objectives, work packages or deliverables and the acceptance criteria. It is more focused on how a client might engage a vendor to conduct a disaster recovery plan. The structure outlined could be used for inclusion in a statement of work. This is a business focused post and not technical.
 

​A disaster recovery plan (DRP) is a documented process or set of procedures to recover and protect a business IT infrastructure in the event of a disaster.
 
Planning and testing a disaster recovery plan is a prudent part of business continuity planning.

---

This post is part of a number of articles on projects, you can read more here.

• Video: How to price your project
• Project delivery checklist
• PMO Project checklist​
• Starting up a project a checklist of 101 things to think about

Are you enjoying this blog? If so, please forward this to a friend or colleague and suggest that they sign up here. It is free and you will receive a coupon code to allow a free download from our store + regular updates on tools, templates and interviews to help get it done !
 
You may also find some of the tools and templates that I have used to deliver projects for startups here, including the most popular item in the store, a project quote tool that helps you build a fully costed project commercial model. You can find it here.
 
All products are offered with a money back guarantee.

ID	Deliverable	Description	Acceptance
1	​Conduct threat analysis	​Identify the likely sources of threat to the system - for example, loss of critical data storage and processing through massive device failure, loss of facilities, loss of power, equipment or network communications, or loss of data integrity. For each of the identified threats, identify the cost of deprivation associated with that event. That is, how much is the business affected by the loss associated with that threat. This allows the threats to be prioritised and allows the plan to address them in a manner proportional to the cost of the loss.	DR Feasibility & Design document
2	​Establish Disaster Criteria	​For each of those events that are to be considered a disaster to the system define: How to identify that the disaster has occurred. Who will declare the disaster. Who will respond to the disaster	​DR Feasibility & Design document
3	​Define the DR Plan	​​Prepare a plan. For each threat, define the procedures to respond to its occurrence. Identify: The staff who are responsible for responding, how they are organised, what each has responsibility for, and what resources they have access to. The actions to be taken, including transfer of processing to other sites, changing of procedures to handle limited resource availability (for example, the alternate site may have to restrict non-critical functions to handle the extra system load), critical functions and how they are to be carried out, and critical data. Procedures to recover to full capability. An escalation process if the primary recovery methods fail. Whether rehearsals of the disaster recovery plan are required for that threat.	​DR Plan document (key artifact that will be used if there is actually a disaster)
4	Identify Support	​Identify the support required for the disaster recovery plan. Recovery Sites. Hot and cold backup sites and the location of off-site storage of data. Hot sites are those that are kept current with data and equipment so that transfer can be done with minimal delay. Cold sites can be brought up using backups of data within a couple of days. Hardware Support. Spares of components and test equipment to support the recovery plan.	Included in the DR Plan document
5	DR Evauluation	Describe scenarios to simulate disasters and invoke the disaster recovery plan. Establish evaluation criteria to determine how well the plan works. Present an evaluation of the results for each simulation. Describe any conclusions or recommendations arising from the execution of these tests and disaster simulations.	Test Plan
6	​Perform test drill for the Disaster Recovery Plan	Create suitable test enviornment Run Simulation	Execution of the plan
7	​DR Test Report	Test report describing what was tested What was not tested, and why What issues / defects were reported Suggestions/ mitigations	​Presentation of report to DR steering team and submission of final report

Objective
 
Disaster Recovery Plan Execution and Validation involves executing the Service or Business Continuity Plan in the event of a disaster or any other disruption where normal restore procedures cannot be used to recover the application within an acceptable period for the business.
 
Objective of the engagement
 
Develop and provide a Disaster Recovery Implementation Plan and Disaster Recovery Plan, execute the plan in a controlled manner, provide a report on the annual disaster recovery test conducted.
 
Environment Scope

• System 1
• System 2
• System 3

 
It is important to specify the scope of the environments to be tested whether it be production, development or test or a combination of all three. For example it may not be necessary to conduct a disaster recovery plan on the TEST environment because the business impact is so low, it could be restored from a back up in a few days with little impact to inflight projects.
 
Disaster Recovery Services (typical)

• Maintain Disaster Recovery Plan
• Test Disaster recovery plan
• Execute Disaster Recovery Plan if disaster occurs.
• Disaster Recovery Tests

 
Project Deliverables
 

 
Project exclusions

• Project will only perform a DR test and will not fail over a full production environment

 
 
Project Assumptions

• Sufficient resources from the client/ vendor are available
• A maintenance window will be available to conduct the DR test
• It is assumed that Disaster Recovery is based on an application restore process using the regular backup processes.
• 
  
  
  
  
  
  
  

 
 
Project Dependencies

• Resources
• Customer will validate the results of the disaster recovery test

 
 
Risks
 
The criticality of the Business Process or System is determined by the Business Impact should a critical incident be experienced. This result is then tied into the Risk Disaster Recovery criteria such as:

• Revenue loss,
• Regulatory impact,
• Public confidence,
• Share price impact,
• Commercial contract impact and
• Closely tied to the level of support and availability of the system

 
The risk can then be included in a table and expressed in the following way.

• There is a risk that…..
• There is a risk that…..
• There is a risk that…..
• 
  
  
  
  
  
  
  

 
This should give you a good basis for engaging a vendor or supplier to conduct a disaster recovery plan on your behalf.
 
Thanks for reading
 
Andrew Everett