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.
[vc_row][vc_column][vc_message icon_fontawesome=” fa fa-book”]Related on BCMMetrics: Once Upon a Time: Organize Your BC Data So It Tells a Story[/vc_message][/vc_column][/vc_row]
A RECIPE FOR DISASTER
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.
EASIER THAN YOU THINK
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.
THE RIGHT WAY TO CREATE BC DOCUMENTATION
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.
WHAT TO DOCUMENT
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:
- The business continuity strategy.
- The scope and objectives of the BC and IT/DR program and procedures.
- The BCM policy.
- The resources allocated to the BC program (e.g., staff, space, budget).
- The business impact analysis (BIA).
- The risk assessment.
- Business continuity plans and incident management plans.
- The incident response structure.
- Drills and training that have been conducted.
- BC exercises that have been conducted (e.g., dates, duration, scenario, participants, results, follow-up).
- Arrangements that have been made for the use of alternate workspace and similar resources.
- Past audits, outcomes, and remediations.
- Management reviews of the program.
- Preventive and corrective actions that have been taken.
KEEPING UP TO DATE
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.
WHAT TO KEEP AND WHAT TO TOSS
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:
- What specific documentation do you keep in each of the categories mentioned above?
- What does your maintenance schedule say about the documentation?
- How often do you create new content and supersede the old (for example, quarterly or annually)?
- Is there a legal or compliance-based rationale to retain the documentation once it is no longer active or in use (for example, to prove that training or testing took place and what the results were)?
- Is there a legal or compliance requirement to retain the document for a specified period of time?
- Does lasting value exist in old versions of the document?
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:
- Plans: Retain for one year after superseded (replaced).
- Governance-related documents (e.g., policy, standards, charter): Retain based upon the maintenance schedule.
- If you update standards annually, keep on file for one year after you update them.
- Retention schedules should take into consideration “exception” documentation when documents need to be kept for a longer period of time in response to an item from an exercise, the steering committee, and/or an auditor.
- Retention schedules should take into consideration any legal or litigation holds that have been issued in response to actual or pending litigation. These may suspend destruction of certain information until the hold is released.
FOR BEST RESULTS
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: