Six Steps to Building Your Disaster Recovery Plan

fireman, firefighter, rubble-100722.jpg
A Disaster Recovery (DR) plan is like insurance, you hope you’ll never need to use but you’ll be thankful to have one if your business is hit by a catastrophe.  Much like a Business Continuity (BC) plan, a DR plan scripts the process of getting your business back up and running so you’re not left reacting to what happened.  Keep in mind when a catastrophe strikes you will not be in the best frame of mind to build an effective plan, and this will impact your customers and your recovery timeline.

To get you started, here are six key steps to building your DR plan:

  1. Put together your Recovery Team and Communication plan.  The Recovery Team will be responsible for executing the plan and communicating with the key stakeholders such as staff, clients, regulatory bodies, and vendors.  The DR plan should note the process that the Recovery Team must follow when decisions need to be made and resources are allocated.  Much like with the BC plan, the communication plan documents who will communicate with each stakeholder and how this will be done.  It’s critical that you build contingencies into the communication plan if a portion of your communication infrastructure has been destroyed.  For example, if a major ransomware attack has taken your IT systems offline, you likely won’t have access to e-mail and the contact information for your key stakeholders.

  2. Identify your critical infrastructure.  This extends beyond your technology and should include other critical parts of your business such as your office locations, key operating equipment, and your vendors.   A good exercise to go through is a typical month of how your business works and what do you rely on to service your clients.  In this exercise, start with a general outline of your business processes and the key infrastructure that support these processes.  When you’re going through this exercise, make sure you include atypical events during your year that would be severely impacted by a disaster such as budget preparations and servicing clients during a busy period.

  3. Determine your Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO).  This is applicable to any technology infrastructure that stores data such as an email system.  For each relevant piece of critical infrastructure, you need to determine how fast you will bring it back online (RTO) and how much data loss is acceptable (RPO).  The lower your RTO and RPO, the greater the investment you’ll need to make in redundant systems, data backups, and staffing to rebuild the impacted systems.  If you have a core business system that simply cannot be offline for more than a day then you will need a detailed plan to get it back online and resources to support that plan.  You must have RTO and RPO estimates for all of your technology systems so the Recovery Team knows where to focus their resources and the deadlines they are under.

  4. Develop some disaster scenarios.  Once you’ve identified your critical infrastructure and your RTOs and RPOs, you need to start thinking of scenarios where the infrastructure has been impaired or destroyed.  It’s best to think of general scenarios and over time break them down if it makes sense to do so.  For example, one scenario maybe that your head office location has been destroyed.  It doesn’t matter how it happened, but you need to execute the recovery of your business until you’re able to bring that office back online.  A key benefit of this exercise is that you will identify potential single points of failure in your environment and can then look at where to add redundancy to reduce risk.

  5. Communicate the plan to your staff.  A DR plan is a detailed document so don’t look to communicate the nuance of the plan to your staff but key elements such as: who is on the recovery team, the critical infrastructure you’ve identified, and what DR scenarios you’ve documented.  From this, your staff will get a sense of when a disaster occurs and who will lead the company’s recovery.  Your staff may also identify infrastructure you’ve missed and other scenarios you should add to the plan.

  6. Test your plan.  Testing a DR plan requires time and resources so is not an easy thing to do but it’s the only way you’ll know whether the plan is reliable or not.  As a start, look to test one scenario each 12 to 18 months.  After each test, you’ll come away with some plan updates and you’ll have the confidence that your DR plan can be relied upon when you need it.

Much like a BC plan, building an effective DR plan takes time and is an iterative process.  You’ll need to bring your team together to build the initial plan and then test it to verify its effectiveness.  Should the day come when you need to rely on your DR plan, you’ll be well-positioned to getting your business back online.