Checklist: How to Create a Disaster Recovery Plan

How to Create a Disaster Recovery Plan Checklist

With disaster recovery plans, we highlight five key steps for creating and maintaining a disaster recovery (DR) plan: 1) identify, 2) define, 3) document, 4) test, 5) repeat. All are critical elements of a successful DR approach.

Step 1 – Identify

Locations
Identify the locations for all systems, equipment, employees, and services per department.

Assets
Assets for a disaster recovery plan may overlap with a business continuity plan, but it is critical to document hardware, software, application/workloads, and stakeholders by department. Be sure to include any special hardware or software requirements, such as a licensing dongle for a particular application. One thing many businesses overlook is the grouping of servers or assets to provide a single application.

Network configuration
Recording network hardware and software types and configurations will assist during disaster recovery and in the event of a malware issue, hardware failure, or replacement. Network configurations are essential for proper application communications.

Recovery strategies and sites
By identifying locations for assets, you can accurately define recovery strategies and recovery locations for each site in your organization. Depending upon the type and length of potential disasters and regulatory requirements, your organization’s needs will vary.

Step 2 – Define

Risk assessment
Risk assessments should flow top-down and back to the top. Each department owns its asset list and reports based on criteria determined by the business. The first of these is disaster potential related to location and impacts, then determining what constitutes a necessity to activate a DR plan.

Business impact analysis (BIA)
A BIA varies based on the type of business you have, so determine the critical revenue or performance indicators and then distribute those based on the bottom line, shareholders, customers, and employees, as appropriate. Having thousands of hourly employees without work and no plan is not a good outcome and could affect business reputation.

Tiers for applications
Without identification, analysis, and a BIA from each department, you will not be able to identify tiers for applications effectively. Closely aligned with RTO/RPO, defining tiers allows disaster recovery processes to recover systems (by application group, if applicable) in the correct order according to business objectives.

RPO/RTO
Determining the recovery point objectives and recovery time objectives, per application and department, is essential to disaster recovery overall.

Application key players
No one knows if applications are functioning better than their developers, owners, and users. Identify and engage these people as part of your regular DR testing.

Failover plan
When you define locations, tiers, and risks, determine your failover plans. They put everything into action. Then consider a failback plan—how to get back to your production environment. The failover plan may be the most important “do this, now” part of any disaster recovery plan. Communicate these steps to your DRaaS provider, executives, or anyone who needs to know.

Response operations
During a crisis, having a central location/entity for all recovery operations enables better communication, reduces duplications, makes checklist communications more efficient, and streamlines communications to executives and the public. Dedicate a person or a team to facilitate this role, and use it.

Step 3 – Document Your Disaster Recovery Plan

Document everything
Sections 1 and 2 gather and define information. You must document all items during these phases of creating a disaster recovery plan and do so with the mindset that it will be read during a crisis and potentially by anyone. Avoid using slang, acronyms, or familiar jargon.

Contact information
Assume no one has access to the team, department head, or executive contact information. This information is helpful for cross-organization communication, new employees, or third-party assistance. Set up call trees for each department so each person knows who is responsible for contacting whom. Include hardware, software, and application vendors and support numbers, as well as those for any contractors currently working with your organization.

Access Control Lists (ACL)
Generally, systems will maintain ACLs when recovered from a backup or as a replicated workload. During a crisis, administrators and employees may need additional permissions to assist with recovery or reduced permission to remove risk. Additionally, consider physical access needs with relation to buildings, servers, and IT equipment.

Recovery checklists
Create checklists for each department or application for use during disaster recovery. Response operations team members may complete these lists as part of crisis management, but checklists are crucial to ensure you do not miss items.

Store offsite, provide copies to DRaaS provider
Giving a current copy of your DR plan to your DRaaS provider solves two problems at once. You will always have a copy of it offsite in an accessible location, and you will be updating your provider regularly, ensuring the best response possible.

Step 4 – Test

Critical to test the disaster recovery plan
Testing the disaster recovery plan is critical. Testing is the only way to know if your documentation and processes make sense and are complete and if backups and replications are reliable. You should test quarterly, annually, and possibly whenever any significant changes occur.

Peer testing
Allow others to perform tests or at least review the documentation and processes. Doing so will prevent confusion and find anything potentially overlook or skipped because it makes sense to the person writing the documentation but may not to the person executing the plan. App owners, users, public Have different groups of users perform acceptance testing, as experiences and expectations vary.

Step 5 – Refine/Revise/Repeat

Refine steps as necessary
Disaster recovery plans should be living documents. Make it a routine procedure to update the plan. Continue to update regularly Employee turnover, changes to the environment, or even overall business objective changes will affect your disaster recovery plan.

Repeat the DR plan review
When making significant changes to the plan, be sure to have someone review it again. Accidentally deleting a paragraph could have a substantial impact on the overall process.

Let’s Talk Disaster Recovery Planning!

Regulatory mandates, customer demands and today’s risk landscape mandates businesses maintain advanced Business Continuity Plans (BCP) and IT Disaster Recovery Plans (DRP). Dataprise’s Strategic Consultants can assist you in developing a BCP that ensures business as usual operations always. Learn more here!