How to Prioritize Your DR Response Strategy

As a mid-size business owner, you fully understand the importance of disaster recovery planning. You have your backups scheduled like clockwork and stand confident that your data quickly recovers if the unthinkable happens. That sounds good, but are you truly ready to respond? Have you demonstrated that preparedness by ensuring your recovery objectives and business objectives are aligned on the same page? Hopefully so because if not, you could have a long, grueling path ahead of you. One of the most critical aspects of any disaster recovery strategy is prioritizing the order in which each system will be restored. How you approach prioritization is a multi-layered conundrum that largely depends on the crisis at hand. If you don't know what you're up against, here's a brief rundown of the threats that could have you one step away from a crisis:

•  Forces of nature. Earthquakes, tornadoes, and hurricanes have the power to turn the lights out for your business literally.
•  Human error. Mistakes happen, but a single mishap in the IT department can be akin to lowering your defenses and inviting trouble right through the door.
•  Insider threats. Unfortunately, not all employees mean well. From tampering to theft, inside jobs are a genuine threat.
•  Malware. Whether it's ransomware or the classic virus, malware can have a crippling effect on business operations.
•  Software failure. The prevalence of network-dependent systems increases the probability of software failure, especially for organizations that rely on hosted applications.
•  Hardware failure. Computers fail without the slightest warning, and when they fall, your data goes down with the ship.

Anyone of these scenarios could spell disaster. We're talking countless dollars in losses, reputational damage, regulatory penalties, and potentially much more. Should they strike, you must immediately shift into recovery mode and work to get your systems back online. Where do you start? What do you restore first? The truth is it depends, and it begins with prioritization.

Technology Matters

Prioritizing your recovery efforts can be as involved as any aspect of business continuity planning. At the same time, it can be a relatively straightforward process ― even when times are seemingly at their darkest. In fact, if you experience an outage at the network level, the most logical way to approach prioritization is often to lean on your infrastructure itself. The typical IT environment is made up of these four layers: 1. Data center 2. Hardware 3. Software 4. Data Think about it. Your data depends on your databases. Databases depend on your operating system. Operating systems depends on your hardware. Your hardware is dependent on the network, which is mostly dependent on the physical facility itself. Even if a disaster forces you to fail-over to a hot site, it's important to understand those specific components must be restored before the dependents they provide for. As the foundation of your business operations, your IT environment is fully capable of guiding your prioritization strategy.

System Recovery

Unfortunately, disaster recovery isn't always as simple as outlined in the above section. Your data center could be standing tall. Your network could still be online. However, if your systems are down, knowing where to begin your recovery efforts becomes a little more challenging. This is where your business impact analysis (BIA) comes in handy. In general, a BIA identifies the risks posed to each critical system. Additionally, it outlines recovery time objectives (RTO) and recovery point objectives (RPO) for each system that needs to be restored. The RTO, in particular, is essential to prioritization. To recap, RTO is the predetermined amount of time an organization establishes to restore systems following a disaster. Let's say you're MSP that lives and dies by your RMM tool. In this scenario, you have to ask yourself how long this system can afford to be inoperable until it starts to affect your bottom line. If you set your RTO at three hours, that is how much time you have to get your RMM system back online, functional, and available to end users. Defining RTO is often the first step in prioritizing system recovery. In most cases, your RTO will vary from one system to the next. For instance, an organization that relies heavily on database operations may give the shortest RTO to an application like SQL Server. On the other hand, your shipping software may be essential to getting a product out to customers, but not as critical to your overall operations. In this case, a longer RTO may be acceptable if it provides enough time to restore the system before orders are shipped the following day. RTO can take the guesswork out of recovery by merely prioritizing your system based on their order of importance. There is nothing fun about scrambling to restore your business to working order. On the bright side, if you plan and prepare ahead of time, a commitment to prioritization will put you on the road to a speedy recovery.