Write or Wrong: Five Common BCM Documentation Mistakes 

Having quality documentation is an important part of a sound business continuity management program, but it’s not the most important part. In today’s post, we’ll look at this and four other mistakes people commonly make in documenting their BC programs. 

Related on MHA Consulting: The Write Stuff: How to Create and Maintain Business Continuity Documentation

Five Ways BC Documentation Can Go Wrong 

An organization can reap myriad benefits by documenting its business continuity or IT disaster recovery (IT/DR) program in the form of written recovery plans. However, MHA has found in our work with clients that documentation is often created for the wrong reasons, at the wrong juncture, and in an incorrect manner, greatly undercutting the potential benefits. 

In today’s post, we’re going to lay out five ways BC documentation can go wrong.  

We’ll also share some ideas on how you can ensure that your documentation is not simply window dressing but is a real aid that can improve your company’s ability to recover in the event of a disruption. 

Common Mistake No. 1: Trying to document a recovery plan that does not exist. We are sometimes asked to produce recovery documentation for clients who lack the fundamental prerequisites for such written materials, namely a recovery strategy and plan. The strategy/plan and the documentation are not synonymous. The strategy and plan and have to come first. Only once a functional strategy and plan exist does it make sense to codify them. Usually, when MHA gets a request for premature documentation it’s from clients who need a written document to satisfy a regulatory agency or customer. We explain to them that we must first help them develop a functional plan and strategy, then we can document the plan for them.    

Common Mistake No. 2: Not figuring out and recording the proper order of recovery actions. This is typically an issue with IT due to the intricacies and dependencies for things like authentication, databases, middleware, data integration, and cloud-based environments. These relationships need to be sorted out and the recovery actions placed in the required sequence, with the proper sequence being clearly set forth in the recovery documentation. 

Common Mistake No. 3: Crafting documentation to satisfy auditors rather than deliver results. Too often organizations write their documentation with an eye toward placating their auditors or customers rather than producing material that codifies a validated and executable plan. Both sets of information are needed, one for external parties and one for internal use. The internal documentation needs to be practical, sound, and detailed so it will be functional if a disruption occurs.  

Common Mistake No. 4: Not figuring out and documenting the integration between the recovery plan and the organization’s other plans. The recovery plan does not live in a vacuum. It typically exists alongside plans for crisis management, security response, and other areas. Integration points and communcation needs among the plans and teams (e.g., “We need to check with the CM team before we start executing”) need to be worked out and written down.  

Common Mistake No. 5: Overlooking the difference between traditional recovery and cyber recovery. The steps for performing a cyber recovery usually differ in some respects from those used in executing a traditional recovery. Traditional recovery may require an alternate IT space or adjustment in work processes. Recovering from a cyber incident such as a ransomware attack will require recovery of data and/or data processing equipment and devices. While that is occurring, manual workarounds are being used to keep the functions moving along. These may be different than the workarounds used in a non-cyber application outage. The documentation needs to take these differences into account. The steps for recovering from a cyber event should be spelled out very clearly. Due to the intricacies of this type of recovery, doing it ad hoc is to be avoided. 

Additional Documentation Issues 

There are two more common documentation issues worth mentioning. There are not intrinsic to how the material is written; rather, they relate to how it is handled and shared. 

The first issue is that the content of the documentation—that is, the steps the organization must take to recover—is often not communicated to the people who need to implement it. If knowledge of how to execute the recovery is kept within the small circle of the primary team members, then the company’s ability to recover will be entirely dependent on those people’s availability, a potentially crippling bottleneck.  

The second additional issue relates to peoples’ access to the documentation files. We’ve seen cases where people can’t access the documentation because the place where it is stored is affected by the disruption. Critical documentation should be kept in a highly available state with the knowledge of how to access it being widely shared.  

The Benefits of Sound Documentation 

We started by saying that the documentation is not the most important thing. That being said, having quality documentation is still important.  

The process of creating, updating, validating, and sharing written recovery strategies and plans brings multiple benefits. It helps organizations identify gaps, train their teams, and respond effectively during outages. This is especially this case if the documentation is prepared in the recommended checklist format, with narrative content left out or confined to an appendix. The very first thing every organization needs is a sound recovery strategy and plan. But quality documentation is a close second. 

An Asset That Improves Resilience 

Documentation may not be the most critical aspect of a business continuity management program, but it plays an undeniable role in its success. Avoiding common mistakes in documentation is vital for ensuring that it serves its intended purpose.  

Mistakes such as attempting to document a recovery plan prematurely or crafting documentation to merely satisfy auditors can hinder the effectiveness of your BC program. Quality documentation, when done right, is a valuable asset that enhances an organization’s ability to recover from disruptions and improve overall resilience. 

Further Reading 

• The 4-3-3 Rule for Writing Business Recovery Checklists 
• Plan B: As the Recovery Plan Fades, What Will Take Its Place? 
• The Science and Art of Writing an IT/DR Recovery Plan 
• Taking Care of Business: How to Write a Business Recovery Plan 
• The Write Stuff: How to Create and Maintain Business Continuity Documentation