If you have not read our previous articles on developing the IT Disaster Recovery Plan series, we recommend you do so. In the last article, we discussed testing your IT Disaster Recovery strategy in detail. In addition, we discussed setting test objectives, selecting the testing method, and preparing and facilitating the testing.

In this article, we discuss documenting, presenting your strategy for approval, and operationalizing it.

Documenting your strategy

You need to select or create a template for documenting your strategy. In addition, you need to consider splitting your DRP as a master document outlining all the managing aspects of your DRP and a technology-specific recovery plan for the respective team to use. Such segregation help preventing the DRP from being updated frequently since any change that affects the management aspects of the IT DRP requires review and approval. 

Leave the frequent changes to the technology-specific recovery plan that does not require re-approval from your executive team or involving your business users. If you choose to use a single document, set a policy stating the changes in the ITDRP that require review by the executive and business stakeholders. Summarize approval requirements for the updates in your IT DRP document. Your maintenance plan must provide more details regarding the approval requirements of the ITDRP when it’s updated.

The IT DRP template should have sections that you have defined in your strategy as a minimum. Therefore, we recommend a minimum of the below sections in your template:

• Introduction — outlining the purpose of your DRP, and its scope

• Classification of disasters — provides a mechanism to determine the severity of the disaster and activate the relevant DRP management process.

• Organization structure — we recommend two types of org structures depending on the incident classification — one, providing alignment with the BCP to manage major disasters.

• Management processes — outline the incident classifications that trigger the ITDRP, guidelines to classify an incident, communications, and working with CAB.

• Disaster recovery — lists the prioritized information systems, their recovery requirements,  high-level disaster recovery plan, and links to the detailed plans and other technical documents.

• Appendices — provide any additional information such as terms and definitions. In addition, include templates to capture information during the disaster recovery process.

It is important to keep the documents accessible to different teams. You should maintain multiple copies in other locations and make sure your staff is aware of it. Consider storing one copy of the documents outside your infrastructure to ensure you have access to them when your on-premise technologies fail. 

However, make sure you have visibility over the individuals accessing them since some documents contain information about the technology you use, their configuration, and even the personal information of your staff.

Review and approval 

Once you have documented your strategy, send a copy of the document to your peers, and select business stakeholders for the initial review. Keep the conversation focused on the review unless revisiting some of the underlying information adds value to your DRP. Having acceptance from your peers and the business stakeholders makes it easy to get the documents approved.

Send it to the executive team or the appropriate management team for approval. The delegation of authority document outlines the approval requirements for critical documents that affect the organization. When you wait for approval, prepare to conduct awareness to the IT and the management teams — we will discuss this in the next section.

The approval of the IT DRP should be easy, depending on the bureaucracy of your organization. Changes requested by your executives or management will be simple unless there is a strategic change that requires you to rethink your IT DRP. Once approved, start rolling out your awareness and training before operationalizing your plan.

Awareness training

You need more emphasis on awareness for now. Further, you should make plans to test and provide training on different aspects of your IT DRP to your IT and business stakeholders as part of maintenance. In general, we suggest the below topics for your awareness training:

• Understanding of the classification and guidelines to classify incidents

• ITDRP activation process

• Organization structure during disaster recovery

• The location where the ITDRP and the dependent documents, and the access required to access them

• Do’s and Don’t when managing a technology disaster

• Information system’s priorities in a disaster

Awareness of your various IT teams is vital since they are the critical resources in recovering your information systems.

Operationalize

Operationalize your IT DRP and hand over the plan to the relevant stakeholders after at least one awareness training is provided to your IT staff. Though the word operationalizing sounds sophisticated, it is simply announcing that your ITDRP is official, and it can be relied upon in a disaster (whatever incident that impacts access to the technology). Usually, the announcement is limited to your IT department and the department heads. Also, make sure there is a maintenance plan to ensure that your IT DRP is updated regularly to be effective. Finally, your IT operation plan must include activities to test the IT readiness to handle disasters.

This article concludes our series on IT DRP. Sign up to receive a notification when our IT DRP toolkit is released.

Conclude

Once the relevant stakeholders are on board with your IT disaster recovery strategy, document them as a plan. We recommend a master document and sub-plans specific to the technology to ensure that any changes in your technology-specific plan do not require a full review of your IT DRP. Alternatively, In your IT Disaster Recovery Policy, you could set up some guidelines for approval of your ITD RP depending on the change.

After documenting your plan, send it for the management approval, summarizing the acceptance from the relevant stakeholders. Finally, provide awareness training to the IT and non-IT department heads before operationalizing your plan.