“Organizations do not do a good job with documentation” is a generalization, but one that we have experienced is often true. There are some who like and are good at documentation and, more importantly, at keeping that information current, but they are in the minority.
Some larger organizations have staff dedicated to various documentation efforts, but most do not have staff in place to concentrate only on that task. When it comes to business continuity related documentation, it can be even more difficult since it requires effort to be spent on something we do not want to think about and that will probably not occur.
Why spend the time when there are many other “more important” activities?
In the BCP field we often work to create dr plan documentation first and then test based on that information, or put in technology first and then document procedures after implementation. We have been changing that paradigm with organizations that have limited time or human resources to perform documentation activities. Rather than trying to create documentation and then use it in the testing, we are using the testing or implementation activities as time to also generate the documentation. This works very well with technical recovery and business recovery plans. While it does take a bit more time during the exercise, the benefit of getting the majority of the content generated in this way outweighs the time.
Also, it allows for efficient use of downtime during exercises. People can work on documentation rather than sitting and waiting for their next activity.
Steps are documented as executed rather than the procedures being a thought exercise that is often rushed through to check a box as complete.
People can work on documentation rather than sitting and waiting for their next activity. Another benefit is that the initial version of the plan is more accurate. Steps are documented as executed rather than the procedures being a thought exercise that is often rushed through to check a box as complete.
Establish a strategy for DR plan documentation, and you’ll thank yourself for it later.