Good documentation is one of the pillars of a strong business continuity program, but it’s one that often gets left out.
In today’s post, we’ll look at how to create BC documentation, which parts of your program you should document, and how to keep your documentation up to date.
Business continuity documentation is like having a file card box containing the definitive recipes for all the treasured recipes that have been in your family forever. With it, any competent cook in the family can find the recipe for the desired dish and make it just the way it’s supposed to be at any time.
Without such a box—and the recipes inside it—good luck.
Companies with poor business continuity and IT/disaster recovery documentation are always operating in the dark and by guesswork. Maybe one person really knows what to do, two or three kinds of know, and everybody else has no clue.
Talk about a recipe for disaster.
On top of that, poor documentation makes it impossible for a company to be in compliance with any of the leading business continuity standards. It also might put the company out of line with its audit, insurance, and legal obligations.
It’s easy to scold people for having inadequate documentation. It’s much harder for a company to get its documentation where it should be.
However, I think that creating and maintaining adequate business continuity documentation might be easier than you think.
It starts with knowing the right way to create documentation.
After that, it’s all about understanding what needs to be documented and knowing how to keep your documentation up to date.
We’ll look at all three topics below.
Is there a right and a wrong way to create BC and IT/DR documentation? In my opinion, yes. And too many companies go about it the wrong way.
The wrong way, in my view, is for people to sit down and try to create their BC or IT/DR plan documentation as a thought exercise, out of thin air. We see this quite often—and then we see the people turn around and use that same documentation as a basis for their testing and recovery drills. The results can be interesting to say the least. For one thing, doing it this way is very hard. For another, there are invariably gaps between what the people thought of and wrote down and the reality of their plans and needs.
A better way is to create documentation while doing the testing or implementation activities. Doing it this way means your testing will take a little longer than it would otherwise, but it also means that when your test is done, so is the first draft of your documentation. This approach has two other benefits. The documentation produced from it tends to be more accurate and complete than documentation produced the other way. And this approach allows for the efficient use of the downtime that always occurs during exercises. People can work on the documentation rather than sitting and waiting for their next activity.
So which aspects of your organization’s BC and IT/DR programs do you need to document? It varies depending on the industry, the size of the organization, your regulatory obligations, and which BC standard you would like to comply with.
However, here is a core list of the program aspects that should generally be documented at most organizations:
So now you know how to document and what to document. The next challenge is keeping your documentation up to date.
BC documents that are out of date are great for wrapping fish in. They are not very good for protecting your company. It’s in the nature of process documents that as time goes on, reality leaves them behind. The only constant is change. All of your BC documentation needs to be regularly reviewed and updated.
In maintaining your BC records, you should first determine if your organization has a records and information management program. If so, you should work with your company’s records professional to determine how long you should retain your BC records.
Don’t be surprised if your company makes little to no reference to business continuity records in its record retention schedule. Most don’t.
However, you can use what the schedule says about other documents (such as risk assessments and other company policies and procedures) as a guideline to develop retention periods for your BC materials.
Whether you do or don’t work with an in-house record professional, you should determine the following for all of the documentation in your program:
Using this information, you should develop guidelines for how long you should retain different types of material.
Here’s an example of a set of documentation-retention guidelines:
Good documentation is an essential part of every organization’s BC and IT/DR program. Programs with weak or outdated documentation are compromised in terms of the protection they offer the organization. They are also unlikely to comply with BC standards or pass muster with auditors. For best documentation results, document while you exercise, learn what you need to document and keep your documentation current through regular review and updating.
For more on this on other hot topics in business continuity and disaster/IT recovery, check out these recent posts from BCMMETRICS and MHA Consulting: