Updating your old business continuance plan for the new year
Has your business continuity plan kept up with data center changes of the past year? If not, it may be time to revisit your plan's capabilities and existing recovery objectives.
Over the past decade, data centers have seen massive changes, but have the business continuance plans kept pace? It is easy for business continuity and disaster recovery plans to fall behind with what is going on in the data center. After all, an organization doesn't need to execute a business continuity strategy until disaster strikes, and since most organizations don’t experience a disaster every year, the need to keep plans up to date doesn’t seem as pressing.
Disasters and disruptive incidents can be impossible to predict, however, so having an up-to-date business continuance plan should be considered a priority. No one wants to wait until a disaster hits to realize that their plan needs work.
Business continuity (BC) and disaster recovery (DR) plans contain many facets and critical elements, so updating an existing plan can be a complex process. Whether the plan needs significant changes or to be replaced altogether, a new year is a prime opportunity for organizations to revisit their BC plan.
Update or start over?
The first step of updating a business continuance plan is to determine if the current plan is even worth updating or if starting over is a better course of action. Technology evolves quickly, so if the plan hasn’t had any substantive updates in the last few years, then it might make more sense to start over. Starting over isn’t necessarily hard, and in some cases starting from a blank slate can lead to a better quality plan. However, if IT has kept the current project up to date over the last couple of years, then a refresh may be all that is needed.
The best way to determine if an organization has to update an existing business continuance plan is to perform a disaster recovery test, using the plan in its current state as a guide. Any steps that IT takes to maintain business continuity that are not in the existing plan are steps that IT needs to add. These updates may include new applications the organization has taken on since the last update, as well as new steps that IT may take to recover already documented applications. The recovery team should then share the recovery results with the rest of the organization for comment on recovery times so that expectations are correctly set.
Revisit service-level objectives
Whether an organization is updating an old business continuance plan or starting over from scratch, an excellent place to start is revisiting existing service-level objectives (SLOs) with application stakeholders. It also makes sense to ensure that the plan covers new applications that IT deployed since the last update. Even if applications are not mission-critical, the plan needs to account for them so that they are not accidentally recovered during the early stages of plan execution.
The best way to determine if an organization has to update an existing business continuance plan is to perform a disaster recovery test, using the plan in its current state as a guide.
Since the plan was last updated, recovery point objectives and recovery time objectives have almost certainly become tighter. Tolerance for downtime has only gone down as time has gone by, and the lower the window of recovery, the more frequently data protection events need to occur and the more rapidly protected copies need to be made available.
For some organizations, meeting these tightening recovery objectives requires a new data protection application that can provide features like block-level incremental backup or replication. It may also require the organization to improve the data protection storage hardware so it can facilitate quicker restorations. Reducing recovery windows often requires recovery on data protection storage instead of waiting for data to copy across the network. If data protection storage is going to serve, temporarily, as production storage, then both its performance and reliability need to improve.
The tightening of SLOs may also force the organization to accept a lower level of recovery for some applications. It is essential to realize that not all applications and data sets are created equal, and not all need instant recovery.
Key updates may include ransomware protection, automation
IT typically writes business continuance plans so the organization can recover from natural or human-made disasters that have rendered the entire data center facility unavailable. While those are still important to plan for, older business continuance plans may not account for cyberattacks like ransomware. Ransomware is unique among potential causes of disaster because it targets a specific organization and specific data sets. Unlike a natural disaster, the latest ransomware variants also try to avoid detection.
Ransomware can often sit idle for weeks, if not months. Once triggered, they encrypt data gradually. As a result, the ransomware trigger file is on multiple backup copies, and different backup copies have different levels of encryption. Organizations need to plan and practice for a ransomware attack. They need to understand how their backup application can help identify which files to restore from which backup.
Several of the leading data protection vendors are also adding disaster recovery automation and orchestration to the business continuance process, bringing life to the plan. With DR automation, IT can pre-program the business continuance process and account for application dependencies.
The start of a new year is the ideal time to review and update an organization's BC/DR plans. The best place to start is to perform a disaster recovery test to document shortcomings in the plans versus the reality of execution. Short of a full test, IT should conduct a comprehensive assessment of a business continuance plan, review recovery commitments and compare those commitments to capabilities. In many cases, the existing software has the necessary updates to enable IT to keep pace with organizational expectations. Still, there may be some new or additional hardware requirements to make the unique features of the software live up to their recovery potential.
