How to create a disaster recovery plan

Meredith Kreisa headshot
Meredith Kreisa|September 12, 2023
Illustration of computer with shield and lock that represents security
Illustration of computer with shield and lock that represents security

An information technology disaster recovery plan (IT DRP) is part of a business continuity plan (BCP) that outlines strategies to recover resources if a system loses necessary hardware, software, data, or connectivity. An effective disaster recovery plan can allow you to continue normal business operations (and rake in moolah) instead of sitting on your hands and regretting every life choice you ever made. But then the obvious question arises: How do you create a comprehensive disaster recovery plan?

That’s what we’re here for. We’ll break down the best practices for how to create a disaster recovery plan as part of your business continuity planning. Prepare for a potential disaster so you can return to normal operation as quickly as possible. 

An estimated 60% of SMBs go out of business within 6 months of a cyberattack. Meanwhile, 25% never reopen after a natural disaster. And yet only around 54% of businesses have a documented DRP. That seems unwise.

Inventory assets 

In order to protect your environment, you need to learn more about it. Compile an inventory of hardware, software, and data before crafting your DR plan. If you spot unnecessary or redundant data during this step, you might consider consolidating it to simplify your backup and recovery processes.

Identify critical resources

Any critical system or resource needs to be your highest priority in a disaster to resume business operation as quickly as possible. But to prioritize the right hardware, software, and data, you need to know what your organization really needs and what is more of a nice-to-have. Once you’ve prioritized, you may need to back up critical data more frequently or even implement a backup production server.

Clarify your recovery objectives 

We know, we know. Your ultimate goal is to avoid disaster altogether. But hear us out. You should also set recovery objectives based on the assumption that, at some point, you’ll experience a disaster. Setting these goals now helps meet relevant compliance requirements while guiding your strategy, including the frequency of your data backups and your failover and failback processes. Two metrics stand out for goal setting: 

  • Recovery point objective (RPO): Maximum data loss 

  • Recovery time objective (RTO): Maximum downtime 

Assess risks 

Perform a risk assessment and business impact analysis to identify potential threats and predict their consequences. Depending on the results, you might create multiple disaster recovery plans to better address more specific scenarios, such as the following: 

  • Natural disaster 

  • Human error 

  • Data breach 

  • Hardware failure 

  • Software failure 

  • Malware 

  • Hacking 

Establish a data backup plan

Establishing a data backup plan improves data security and allows data recovery should a disaster occur. Since you rely on data to conduct day-to-day operations, data loss could disrupt business. A data backup plan gets you back on track if hardware fails, a user accidentally deletes something important, or your office is overtaken by a Sith army hellbent on stealing your staplers (even lightsaber-wielding antagonists have significant collation needs). 

Cloud computing is increasing, so it can be tempting to assume that anything on the cloud is inherently secure. However, cloud providers could still theoretically be hacked, so you may want to consider a separate cloud DR plan. 

One big benefit of physical backups is that you can take them offline to isolate them, which may be a more effective approach if other systems are infected with malware. That said, recovery from on-site backups is usually more time consuming. Plus, if your office experiences a natural disaster and you only have on-site backups, there’s a very real risk that you’re completely out of luck.

Your disaster recovery plan should spell out backup strategy, storage methods, frequency, validation procedures, and recovery process.  

Determine key team members

Detail the responsibilities of your disaster recovery team members so that in the heat of the moment, everyone is ready to act quickly. You should also designate substitute recovery personnel in case a key player is out of the office. After all, you don’t want your disaster recovery to fail just because Alex couldn’t resist the allure of chugging drinks with tiny umbrellas on a distant beach. 

Make a communication plan 

If disaster strikes, you’ll need to act quickly. Include who to contact and their contact information. Also detail which situations require communication with other stakeholders, like employees, customers, vendors, and (of course) your favorite regulatory agencies. Remember that any computer-based communication tool, including your VoIP system, may be offline, so you’ll need an alternative form of communication and continued access to contact information. 

Document your network infrastructure 

Keep an up-to-date blueprint of your network infrastructure as part of your disaster recovery plan so that you can rebuild quickly if necessary. Include each asset’s level of importance and dependencies. 

Set disaster recovery procedures

Your disaster recovery procedures are like your cool wizard friend that charts your path to Mordor. Keep in mind that the clearer that roadmap, the less risk you’ll end up surrounded by orcs.

To that end, use plain language. Yes, your IT team can handle more complex terms, but the middle of a crisis is not the time to increase their cognitive load.

Your disaster recovery strategy should provide step-by-step directions on how to respond to different types of emergencies to limit downtime. Incorporating separate recovery strategies for different types of disasters makes your plan even more actionable and less open to interpretation. 

If you have a specific DR site you can use in the event of a disaster at your office, make sure it is noted in your procedures along with the process for transitioning over.

Test your plan 

While your DR planning may seem flawless on paper, you should test it to verify that you’re ready for an actual disaster. Simulate different disaster scenarios to see how they might affect your systems and assess how your recovery effort plays out. Pay particular attention to RTO and RPO, and watch for single points of failure that could derail your recovery process.

Update your plan 

Revisit your plan at least every 6 months and after any disaster. Continue to update your DRP based on evolving threats, changes to your systems and processes, and lessons you’ve learned from testing and real-life disaster recovery.

Keep up-to-date copies of your plan 

Just one copy of your DRP is never enough. Remember that you might not have access to your local network or physical office depending on the type of disaster. Keeping a copy in the cloud and in a safe in your office gives you more options. After all, having a well-crafted DRP but not being able to access it during a crisis would be a cruel, cruel irony.


If you just don’t have the bandwidth for in-house disaster recovery planning, a managed IT service can provide additional resources and support.

You can also free up more of your IT team’s time with PDQ Deploy & Inventory and PDQ Connect. These flexible solutions allow you to manage inventory and deploy packages seamlessly. And by maintaining visibility and up-to-date systems, you can also avert many disasters. You’ll definitely still need to keep a disaster recovery plan handy, but with any luck, it can stay out of sight and (somewhat) out of mind. Sign up for a free trial of PDQ to savor the instant calm of streamlined device management.

Meredith Kreisa headshot
Meredith Kreisa

Meredith gets her kicks diving into the depths of IT lore and checking her internet speed incessantly. When she's not spending quality time behind a computer screen, she's probably curled up under a blanket, silently contemplating the efficacy of napping.

Related articles