Many organizations know the importance of having a disaster recovery plan and are investing in creating such a plan to bring more uptime.
Two aspects that often are neglected in the Disaster Recovery plan are the proper and full documentation of the recovery steps and testing. These are critical because the robustness of the plan, such as processes, roles and recovery steps are put to the test. Once the outcome of the DR plan test is successful, it’s imperative to organize and document the recovery steps and testing outcomes. The success of these two aspects of the plan could mean the difference between rapidly restoring uptime or missing the recovery time objective; therefore, not meeting SLAs.
Testing the technical component of your DR plan is imperative, but don’t forget to also test the people responsible for the recovery. Test how they will respond under stressful situations because in the event of a disaster or even when IT systems go down unexpectedly, these stressful conditions will test how well your IT team will react to quickly restore uptime. This means, they will need to quickly access the recovery information to know what to do. Therefore, having a well-documented and accessible disaster recovery run book is essential during these unexpected situations.
A DR run book can be a working document and many organizations use different solutions; from a word document or spreadsheet to a full suite of crisis management software to document and store the DR plan and recovery steps. These options could work fine for many organizations; however, a word document could not be the ideal way of keeping a DR run book.
First, it can be very cumbersome to create and update. Knowing the dependencies and sequence of recovery steps are an important part of the recovery process and critical for a successful outcome; therefore, using word or excel could make it hard to create and track dependencies between IT services, applications and infrastructure.
In addition, the word or excel document could be difficult to access by the IT team, especially when networks are down.
A solution would be the use of BC/DR applications, but they come with some disadvantages. For example, applications such as crisis management software could be costly, complex and could have a long learning curve when their complexity forces you to develop it in multiple layers and modules. Therefore, it is important to evaluate the complexity of the application you want to implement and if it fulfills all DR requirements of your business.