Writing your organizations Disaster Recovery Plan (DRP) can be an overwhelming task. Many IT managers and business leaders do not know where to start, especially if they have dozens of potentially critical business processes. There is a process to follow that will help ease the feeling of being overwhelmed, but do know it is a process that you will have to approach with patience and endurance. In many cases most organizations hire outside professional services companies that are very experienced and knowledgeable to layout the DRP roadmap and help implement the plan.
Does your organization have any form of a Disaster Recovery Plan (DRP) today? If your organization has no DRP today you may be thinking that it could take a year or two to write the plan, which will leave your business exposed to a disaster event. This may be true and a way around this is to write a lightweight interim plan that provides some DR procedures to the organization while you complete the full DRP.
We know that the full DRP will take a year or two to complete, but the interim DRP can be completed in about 1 week. The way to write the interim DRP is to identify three to four of the most knowledgeable subject matter experts in your organization and hold scheduled meetings all week to draw out the interim DRP. Usually, these individuals that you assign to write the DRP are managers and senior engineers that are most familiar with both the critical business processes and the supporting IT systems. You may have to lock them in a meeting room and order lunch and perhaps dinner but if determined, you can complete the interim plan.
As soon as you develop the interim DRP, you need to get the real DRP project started. The time you need to develop the full DRP will vary, based on the size of your organization, the number of critical business processes, and the level of commitment your organization is willing to make.
It is estimated that the smallest organizations of 100 employees or less could require 3 months to complete a full DRP and large organizations with thousands of employees could take at least 1 year to complete. There really isn’t a formula to calculate how long your organizations DRP will take but know there will be a commitment required to develop the plan.
So here we go! Start your DR project with a kickoff meeting which can last a few hours. The attendees of the meeting should be the entire DRP project team, the members of the DR steering committee, executive sponsors and any other involved parties should attend. The steering committee should state that they support the DR project.
After the kickoff meeting, the DR project team should have a PM lead weekly meetings to discuss the progress of delivery dates and any changes that need to be made. The project manager should also publish a weekly status report that can be reviewed in the meeting by the DRP team.
The first major step in any Disaster Recovery Project is to identify the business functions/processes in the organization that require DR planning. You will also need to conduct a risk analysis for each critical business process to measure the effect on the organization in the event of something interrupts each of these business processes for a long period of time (also known as a disaster event). This activity is known as the Business Impact Analysis (BIA). The BIA will analyze the impact each business process has on the business.
For each critical business process, the DRP team will need to determine a measurable know as the Maximum Tolerable Downtime (MTD). The MTD measurable for a given business process means that this is the maximum amount of time that this process can be down before it will threaten the survival of the business itself. It will be important to get the DRP steering committee, business owners and senior management together to determine what the MTD is for each business process. There are several workshops and questionnaires the team will need to go through to achieve an MTD measurable for each business process.
After you set the MTD for each critical business process, you need to set some specific recovery objectives for each process. The two primary recovery objectives that you usually set in a BIA are the Recovery Time Objective (RTO) and Recovery Point Objective (RPO).
The RTO is defined as the maximum period of time that a business process will be unavailable before you can recover it. So for example, if a disaster strikes at 1pm, and your RTO is set for 24 hours, you are saying that you have a redundant solution in place which will allow you to recovery the business process by 1pm the following day.
It is very important that the RTO for a critical business process is always less than the MTD for the process. For example, if you have an MTD for a given process to be 3 days you need to set the RTO to something less than 3 days, perhaps 2 days. Also, Something to note is that you need to make sure you have a redundant DR infrastructure in place or plan on engineering one that will allow you to support the RTO measurable you have assigned to the given business process.
The RPO is defined as the maximum data loss that your organization can tolerate for a given critical business process. So for example, if the business owners for a process assign an RPO of 2 hours; when you restart the process, users lose no more than two hours of work or data.
Once you have identified the MTD, RTO and RPO for all your business processes you will be able to see which ones need to be recovered with highest priority and essentially what the organizations most critical business processes are. It is a good idea to create a spreadsheet with all the business processes shown and columns for the MTD, RTO and RPO. This will allow you to sort and filter through all your business processes and identify those with the highest priority.
In the next blog post I will go through the next step in the DRP process which is the “Risk Analysis”. This is where you will determine likely disaster scenarios for your business processes, probability of occurrence, Vulnerabilities and Mitigation steps.
Lastly, as you go through the process of producing a DRP for your organization, it will also help you see more clearly the gaps you have in your business process technology platforms and determine ways to improve them. So the exercise of producing a DRP does more than just allow you to create disaster recovery processes and procedures, it also will help you improve your organizations technology processes as a whole.
Dean Carrera of Sozo Hosting provides Disaster Recovery hosting and consulting services, which include full Disaster Recovery Planning and implementation, system hosting and management of data continuity backups. Feel free to reach out to us with any questions you have on this subject matter. Dean.email@example.com, 1-800-640-4892.