IT Disaster Recovery Plan (ITDRP) informs the relevant stakeholders how your organization will recover and maintain its operations dependent on the information technology during and after a disaster is declared. 

This short series provides you with some basic information on ITDRP, which you can use to develop a useful ITDRP. This article serves as an introduction to the process of documenting such a plan. It is not about designing your disaster recovery site but the right way of documenting your current disaster recovery strategy.

Why do businesses need an IT Disaster Recovery Plan?

In simplified terms, DRP is about knowing the technology’s recovery priorities supporting the business and a well-organized approach to recovering them. It has numerous business benefits attached to it:

• Contributes to the resiliency requirements of the business

• It prevents your organization from going out of business due to a disaster

• Provides a better understanding of the business

• Enhance the effectiveness of the IT and Corporate governance during an unexpected disaster

• Enhances the organization’s reputation with its customers by demonstrating its ability to uphold the availability of the services

• Reduces the uncertainty in prioritizing when restoring the information systems

• Provides agility in responding to the incidents by freeing the teams trying to structure their response and focus on restoring the IT services

Despite the numerous benefits of a well-structured and business-aligned plan, 75% of small businesses have no disaster recovery plan objective in place. Even the companies that do have a DRP in place lack confidence in their plan and often outdated to be reliable in a disaster.

A rather startling statistic will drive home the importance of IT DRP — 93% of companies without Disaster Recovery who suffer a major data disaster are out of business within one year. 

For the organizations that have an unreliable DRP, these are some of the common pitfalls leading to such failure:

• Not developed in conjunction with the Business Continuity Plan

• Developed in silos ignoring the rest of the business

• Not seeing value in the management processes in the DRP

• Failure to Identify and Understand Recovery Dependencies

• Failure to test and improve the plan continuously

The first two pitfalls are prevalent in organizations with BCP and IT DRP but are treated as separate plans. 

Developing the DRP in conjunction with the BCP is very important since it provides an alignment between business restoration and the dependent information systems. Also, involving the business when developing the DRP provides IT with the right priorities and understanding of the ground realities of business in a disaster.

ISO 27301:2011

Despite the existence of ISO 27301:2011, most organizations document their DRP the way they understand. Despite outdated, the ISO/IEC 27031:2011 Information technology — Security techniques — Guidelines for information and communication technology readiness for business continuity provide a framework for documenting your DRP. Also, the standard is currently being updated to stay current and relevant.

The ISO 27301:2011 standard also provides guidelines for designing your DRP, taking security into account. The standard can be split into six main categories:

If you do not want to follow the standard published by ISO, we recommend following the below approach outlined in documenting your DRP. The key here is to document a DRP that fits your organization, taking the stakeholder’s concerns into account and align with your BCP.

Our approach

We recommend the below as an approach to your IT DRP documentation.

Despite the approach looking complicated, you will find it simple and straightforward to follow, and we will discuss it in this series.

Plan

In this stage, you may have to establish the below:

• objectives

• scope

• dependencies

• stakeholders to your DRP and,

• prepare to conduct BIA

Some of these are discussed in our Business Continuity series, and they will serve as a foundation. In this article, we will summarize the above-listed activities.

Objectives - you must define objectives for your DRP. Although it sounds simple, you need to define the objective in discussion with your management. It should not be on your own, based on your understanding of the business. Not consulting with the business may lead to severe misalignment in your DRP objectives to the Business continuity.

Scope - This greatly depends on the business. While it sounds simplistic to say that the scope is all the technologies managed by IT, you may find it not to be the case after understanding your business. For example, despite using many cloud applications to conduct business, and they are operated and managed by the respective vendors, IT is still a custodian. Hence, you have to include them in your DRP.

Dependencies - you need to understand the business dependencies and the technology dependencies for your DRP. Understanding the business provides you with valuable insights on the right kind of dependencies covered by your plan leading to understanding the impact of the technology dependencies (such as software integration or underlying infrastructure) on the business.

Stakeholder - developing a DRP requires dedicated and part-time staff. Knowing the stakeholders and their roles will help you group them as a team and utilize their expertise accordingly.

Prepare to conduct BIA

Preparing to conduct BIA is covered in detail in our article here. However, we still need to provide you with few pieces of information that may apply to the context of your DRP.

Suppose you have already completed a BIA for your BCP within the past six months, and there is no change in business priorities. In that case, you can use the consolidated BIA as a starting point and skip the stakeholder interviews altogether.

Otherwise, you will have to conduct a BIA, albeit smaller in context. The BIA for DRP should cover these topics:

• Key business processes, their criticality to your business, and any alternative process that currently exists

• Technology dependencies to execute the key processes, their RTO and RPO requirements, and their integrations (obtain this from the IT stakeholders)

• Vital information to execute the key business processes

• Business impact over time due to the unavailability of the information system

The best way to collect them is to prepare a data collection spreadsheet, discuss with the business stakeholders, and use it for the stakeholder interview. Once we are ready with the template, it is now time to conduct the interviews.

Conclusion

IT Disaster Recovery Plan is a crucial but often overlooked document in a business. Whether used from your data center or the cloud, every business that uses information technology should have a documented plan to restore them when a disaster strikes. You should either follow the ISO standard such as the ISO 27031:2011 or adapt our approach to document the DRP and prepare to conduct the BIA to understand your business. Understanding your business and involving them to document your DRP provides you with the required business alignment that makes your DRP very effective.

We will discuss conducting and concluding Business Impact Analysis in the following article.