Disaster Recovery (DR) and Business Continuity (BC) are very different areas within an organization. While some organizations have them under one group, others have done much to separate them. However, without BC, you really cannot have DR. There is a definitive tie that binds the two together.
BC can be defined as a set of plans, procedures, processes, and controls that allow an organization to operate despite some sort of interference, whether man-made or otherwise. The BC organization attempts to have processes set up to allow for the business to carry on despite something interfering with the normal day-to-day functioning of the organization.
But what does DR have to do with that? Well, first off, there is the disaster that impacts the Data Center of an organization. This disaster should be at least mentioned as a potential BC impact. However, the plans, processes, and controls that allow an organization to operate are generally owned by DR instead of BC for these types of situations. So, then, why do we think that these two different organizational groups are somehow tied together?
Good BC planning will take many things into account that will operationally assist DR planning. A good BC plan and process will ensure that such things as Critical Applications, RTOs, RPOs, etc. are properly addressed. During the Business Impact Analysis (BIA), the BC team will ask which applications the business deems Critical. They will document such things as RTO and RPO for all the applications within the organization so that the DR team has access to this information. This will allow the DR team to properly plan exercises, perform testing, and be ready for an unforeseen catastrophe that requires recovery of the Data Center at the colocation.
One thing to be careful of during the BIA process is that almost every business area will deem the software and applications they use to be Critical. The BC and DR teams should work together with upper-level management to define what the appropriate measures are for determining Criticality of applications within the organization. This could be monetary implications, reputational losses, statutory requirements, and other such items that are important to the organization. It could also include something that I referred to in a previous blog that outlined how to incorporate DR Guarantees into determining Criticality of applications in the IT landscape. Only after these measures are set for determining Criticality can the DR team adequately and accurately determine the plans and processes necessary to recover the IT components to carry on the business.
It is also vital for BC and DR to communicate on a regular basis to make sure that both entities within the organization are on the same page. Things can change in either area of the company, and when they do, there could be an impact to the other. Take, for example, the introduction of Minimum Control Standards within DR. This could require DR asking BC to ask different questions for them during the BIA process. It could require training individuals within the organization differently on the expectations of taking computer hardware home daily. The point is that changes should always be communicated between these two areas to keep an open line of communication to ensure that if something happens within the organization, both BC and DR are ready to implement their plans and processes.
Hopefully a disaster never occurs where you are required to recover your data center. In most organizations, this is a last line of defense and one that is preferably never completed. However, to be ready for any situation, it is imperative to make sure you are aware of the importance of the ties that bind BC and DR together.
Great content! Keep up the good work!