So far in this series, we discussed the planning required to document your IT Disaster Recovery Plan, conducting BIA and Risk assessment. In this article, we discuss defining a strategy for your DRP.

Requirements for the DRP

By now, you should have all the required information to start designing a DRP strategy that balances between the business stakeholders’ availability requirements and the disaster recovery implementations by the IT.

You will need the below information to start designing the DRP strategy.

Stakeholders

List of business and IT staff essential to recover the relevant information systems after a disaster. They are identified at the beginning and kept updated. It is crucial to replace the primary stakeholder of the business functions (such as Finance and Procurement) with the department heads if it is not so during the BIA.

BIA Report

The BIA report specific to the IT DRP will have the list of information technologies prioritized as per criticality defined by the business. It will also provide you with information on the gaps (the next one in this section) and the locations where your business information is stored.

Gaps

While most of the gaps between the technology and the business priorities can be obtained from the BIA, the Risk assessment report will provide you with additional insight into risks that could ruin your disaster recovery. Also, both these reports contain plans to mitigate the gaps. Finally, these gaps will provide you with the next potential revision date for your ITDRP.

Technology

The list of technologies used to support your business is found in the BIA report and your IT service catalog (most organizations do not keep this information updated). You must also consider the information systems used by IT to maintain the systems’ availability.

DRP components

The IT DRP outlines our policies and procedures relevant to recovering critical technology platforms, including the telecommunications infrastructure. These are the major components of the IT DRP:

Organization structure

The structure for your disaster recovery organization must be tiered, allowing you to merge with your BCP (if it is available) when required. In addition, define the roles and responsibilities for each team in the organization. Disaster recovery organization structure helps to avoid confusion in a disaster when the teams scramble to find the root cause and try restoring the information systems.

Disaster classification

It is important to define classifications for the incidents to prevent launching into disaster recovery mode for the more minor incidents, resulting in an expensive recovery that is not required. The disaster classification could be between two and three. Classifications of less than two will not provide you with the flexibility to handle incidents small and medium within IT. Likewise, more than three classifications make the IT DRP unnecessarily granular and difficult to maintain.

Management processes

Management processes help retain control over the IT disaster from identification, stand down, to maintenance. These are some of the management processes that are important for the DRP.

• Activation process

• Internal and external communications

• Incident tracking and logging

• Invoking the external DR services

• Investigation and recovery processes per services

• Collection of feedbacks for analysis

• Stand down process

• Post-incident analysis and review

• Continuous improvement

It is not required to start your IT DRP with all the processes listed above. Instead, it would help if you started small and scale at a later stage based on the maturity of your organization.

Priorities

List of information systems prioritized according to the business requirements, reflecting the ground realities. However, suppose the implementation of your disaster recovery differs from the business requirements (especially in a negative way). In that case, you must discuss it with the business and reach an agreement before concluding the priorities for the information systems.

Individual service recovery plans

These are individual documents focused on the management aspects of restoring a particular service. This includes activities such as coordinating and the list of teams responsible for performing them. Avoid repeating the technical information you have in your Service Design documents. 

Instead, if you do not have a Service Design document, include the technical information such as installation & configurations, data integration testing, backup and recovery steps, and playbooks. If you have an updated Service Design document, provide a link to those documents for any technical guidance. Also, revise the Service Design documents to include the activities relevant to the disaster recovery.

Important contacts

All contact information required for the IT DRP must be listed as part of your plan or kept in a separate spreadsheet. In case of maintaining the contact in a separate spreadsheet, include a reference to the external spreadsheet in your DRP. These are important to keep track of to avoid confusion finding the right individuals in a disaster. In addition, contacts of your managed service or outsourced service support teams must be included in the contacts list.

Additionally, these are some of the additional components you should include in your IT DRP.

• Triggering events

• Communications

• Templates such as incident tracking and logging, communications, and feedback

Designing and presenting your strategy

You should conduct multiple workshops to identify the components listed above with the respective stakeholders. Then, when designing each DR component, you must discuss it with the relevant stakeholders involved to make sure they are correct.

Also, you must discuss with your Business Continuity and Crisis Communication teams to align the IT DRP processes with the BCP processes where applicable. Document the feedback you have received during these discussions to improve your DRP components and use them in your plan’s consecutive revisions.

Use the combination of diagramming tools (such as Visio or EdrawMax to design the processes), Presentations, Spreadsheets, Documents, and good old whiteboards to complete the brainstorming.

Once you have an agreement with the relevant stakeholders on the individual components of the recovery plan, consolidate them into one single presentation. Then, invite the senior management of the IT and select business to present the recovery strategy. Incorporate their feedback if they are relevant before moving forward with testing your strategy.

Closure

In this article, we discussed the required information and the components that are part of your IT Disaster Recovery strategy. You must also include the relevant stakeholders. Finally, when the relevant stakeholders accept your strategy, consolidate them into a presentation and present them to your senior management. You must plan to test your recovery strategy once your senior management accepts it.