Here are seven things you must include in your disaster recovery plan to ensure your business continuity.
i. Know Your Critical Business Operations
First, establish which business operations are critical to your business. A good DRP focuses on getting critical services up and running in the shortest time possible.
ii. Know Your Business Threats
Secondly, get an understanding of the history of your business, the industry and the region, and map out the threats the business is likely to face as a whole and specific assets. For instance, based on past known events, what is the likelihood/frequency of the following threats affecting your type of business?
• Natural disasters such as floods, hurricanes and other extreme weather conditions
• Political violence, wars or civil unrest
• Failure of critical servers, internet connections, applications and software. For this, you can engage your IT staff in this discussion.
• Cyberattacks. Engage your IT staff in this discussion.
For example, businesses in the technology industry may be at a higher risk of cyberattacks. Compile a comprehensive list of potential threats to your business operations.
Once you have identified and listed your threats, ensure your disaster recovery plan is effective against all or at least the most likely or most significant threats. Develop clear DR guidelines for specific types of disasters.
iii. Know Your IT Assets
Secondly, get your disaster recovery team together and make a list of all your business-critical assets, i.e., the assets that are important for the day-to-day running of your business. This may include servers, critical business applications, networking equipment, cloud services, critical data, and so on. For each item, note its physical or virtual location, vendor, version details, networking parameters and relation to other assets.
Document how your assets aid in the running of your business. Establish what impact they will have on the organization if they are unavailable for one reason or another. Then, organize your list into three as follows:
• Critical assets your business cannot operate without – for example, an email server.
• Important but not critical assets that can seriously hamper some activities – for example, a projector for making presentations.
• Other assets that will not have a significant effect on business operations – for instance, a system used by staff for recreational activities during their breaks.
iv. Define Your Recovery Goals (RTO and RPO)
The third key feature is to establish how quickly your company should be able to recover from a disaster (recovery time objective) and how much data you can afford to lose (RPO) in case of a disaster.
Define your RTO for critical assets. RTO refers to what period of downtime (maximum number of minutes, hours or days) you can survive an outage. Your disaster recovery plan must incorporate these strict timelines into its protocols. For example, a high-traffic eCommerce website may result in major financial loss for every minute of downtime. On the other hand, an accounting firm may be able to sustain a day or two of downtime and resume normal operations, provided there is no data loss. Define a clear step-by-step procedure of how you will bring operations back online within the RTO.
Then, define your RPO. RPO refers to the maximum age of transaction data your organization can afford to lose during an outage and survive. The business must recover from backup storage to resume normal operations after a disaster. Companies use RPO to determine the minimum frequency of backups. For example, a four-hour RPO requires backing up at least every four hours.
Establishing accurate and reliable RTOs and RPOs is how you set the limits within which your recovery plan will have to operate.
v. Set Up Disaster Recovery Sites
Apart from just backing up data, we recommend that you continuously replicate data and/or full systems/applications from your primary business environment to an alternate system.
Using your knowledge from the steps above, visualize your final DR setup. Determine whether you will have a hot or warm DR site. Decide on its location – and whether it shall be cloud-hosted or self-hosted, and which vendors (if any) you will need to deliver on this.
For instance, you may replicate to:
We recommend remote backup/replication. This would be more useful in case of disasters such as fire, floods, or theft in the primary location. Remote backup/replica solutions may be cloud-based, i.e., replication or backup is automated. The benefits of automation eliminate the challenges of manual backups. Manual backups are cumbersome and more likely to be forgotten as they require a user to initiate the backup/replication. It is quicker to recover from cloud backups than from manual backups.
vi. Set up a Disaster Recovery Team
After identifying potential disrupters, determine how your company will respond in each scenario.
Define roles and responsibilities for each expected response and ensure each person has an assistant. This ensures that all actions and details are covered. Your DRP should also include details regarding communication, such as who will communicate with whom in specific situations. When everyone knows what to do in response to a disaster, your DRP will be more effective and efficient.
vii. Regularly Test Backups/Replicas and Restoration of Services
And finally, just as your primary business systems can fail in a disaster, so can your backups!
There are several horror stories of organizations that had a backup system in place, but discovered too late that their backups were not working correctly.
Backups and replicas may be rendered useless owing to a configuration problem, software error or equipment failure, and you may never know that they won’t work unless you test them. Therefore, an inseparable part of any disaster recovery plan is testing that data is being backed up or replicated correctly to the target location.
Additionally, it’s just as important to test that restoring data and normal business operations within perceived/planned timelines is feasible. These tests must be conducted when you first set up your disaster recovery systems and then repeated periodically to ensure the setup remains reliable.
Some factors to consider here are:
• Are there any systems that lack redundancy in your disaster recovery plan? Can you continue with your recovery plan if these single points of failure encounter a problem?
• Are you meeting your set RTOs in your tests? How long is it taking to restore operations?
• Are you meeting your set RPOs? How much data has been lost when switching over to the failover environment or backup? Is the data lost likely to affect your operations, and if so, how?
• Are you running tests that assume that data on your network is corrupted, or is it inaccessible because of damage to the data center? Consider how different disasters may affect your recovery options and whether you have covered all the likely scenarios.
Test your plan (Drill)
And finally, test your disaster recovery plan to make sure it works. Carry out drills and check whether your staff and disaster recovery team's actions meet those in your plan. If not, make changes as necessary.
Review the plan every 6 months
Periodically review the plan – at least every six months – and continuously update it to ensure it stays relevant and reflects your company’s current structure and IT setup.