In the previous article, we discussed the need for documenting your organization’s IT disaster recovery plan. Then we discussed the preparation required to conduct the Business Impact Analysis (BIA). In this article, we will discuss the BIA and risk assessment.

Conducting BIA

Once you have fine-tuned the data collection spreadsheet after the workshop, send out the invitations to the department heads (hereafter referred to as champions) for the formal interview sessions. The BIA interview session for IT DRP is very similar to the BIA interviews you conduct for developing your Business Continuity Plan discussed here.

If you are documenting your Disaster Recovery Plan without a formal BCP, then you will have to conduct a detailed BIA with the context of figuring out your recovery priorities. This BIA can be used to improve your disaster recovery capabilities which are outside the scope of this article.

Since your goal is to document DRP, it is common to get very technical during the BIA interviews. For example, you may be tempted to venture into multi-tenancy, latency, data replication, load balancing, and other technical aspects with the champions, leading to unproductive sessions. Resist such an urge to deep dive into technical aspects of your disaster recovery. Keep those discussions for the IT SME’s after the interviews.

While you should certainly ask questions when the champions provide extreme RTO’s and RPO’s, generally refrain from extensively challenging their business processes and priorities. The program steering committee will help resolve some of that dilemma for you at a later stage. After each session, go back to your team and discuss the findings with the respective application team if required.

Arrange follow-up interviews if you require clarification. Since the BIA for DRP is significantly smaller than BCP, it should not take more than two sessions per champion. If you need shorter interview sessions, there is one more trick you could use.

Generally, IT knows the information systems used by the respective business functions — at least the core ones. With that knowledge, you could summarize the business processes that fall under the same information system and discuss the rationale behind the RTO’s and RPO’s provided by the champions.

Post-interview analysis and discussion

Consolidate the data you have gathered per information system from your service catalog to determine the information system priorities. You should consider the most aggressive RTO and RPO processes to prioritize your information systems. If 98% of the critical processes that rely on an information system are not critical, you could discuss the possibility of reducing the criticality of the respective software application with the champions responsible for the 2% of critical processes. 

However, if it does not make a big difference for your IT disaster recovery because the information system is already part of the extreme reliability group, do not work to change the criticality of that software application. Your intent is to document the DRP that is aligned with the business and not to redesign your IT disaster recovery.

After the analysis, you should summarize the findings. If there are gaps such as the RTO for a particular software application cannot be achieved due to the way IT Disaster Recovery is set up (e.g., your backup on the tape per availability group, and restoring them will require more time, and hence you cannot meet the RTO requirements), you must discuss with both IT and the business stakeholders to reach a compromise based on the current realities. Mitigations for the gaps must be addressed and documented.

If you have a formal BCP, discuss with the Business Continuity manager or the team responsible for BCP to discuss the findings, and ensure you are aligned with the BCP.

After that, the analysis, gaps, issues, and mitigations must be documented as a report and presented to the steering committee. Once your steering committee accepts the report, you must initiate the risk assessment.

Risk assessment

Refer to this article on preparing for the Risk assessment and this article for conducting the risk assessment and reporting. We have summarized it for you in this article.

Usually, companies do not perform a risk assessment for documenting their DRP. However, we recommend using the below as guidelines to decide on conducting a risk assessment.

• If you are documenting the IT DRP for the first time (or updating it due to lack of satisfaction with your current one)

• If you have had a merger since your last BIA

• If you haven’t updated your BCP for a long time

• Your IT DR is not designed based on BIA

When you decide to conduct a risk assessment, follow the below recommendations from us;

• The risk professionals must do the risk assessment

• You must use the ERM framework rather than using something specific to IT

• The scope for the risk assessment is the IT Disaster Recovery Plan (and not the IT disaster recovery implementations)

• BIA and the current IT disaster recovery capabilities are the inputs for this phase

• After the completion of this phase, your IT or the ERM will be responsible for tracking the mitigations (depending on your ERP framework)

If the risk assessment findings are different from the BIA report, discuss it with IT and the relevant business stakeholders. Make changes to your risk assessment or even BIA findings based on the outcome of the discussion as required. If mitigations to the risks are discussed and agreed upon, document them before presenting the report to the steering committee.

After concluding the risk assessment, you should start defining the strategy.

Conclusion

Conducting BIA for documenting your IT Disaster Recovery is relatively easy compared to the BCP. Avoid the common BIA interview pitfalls and document the interviews using a template you have already prepared. Once done, analyze the interview data and discuss the champions, IT, and BCP team. Optionally, we recommend conducting a risk assessment based on certain circumstances listed in this article.

Discuss the risk assessment results with the stakeholders if they reveal findings that are not already discussed during the BIA (sometimes the findings between BIA and RA overlap). After the discussion, present the report to your steering committee.

In the next article, we will discuss the defining strategy for your IT DRP.