This post is the first part of my Business continuity and Disaster recovery mini series.
You may wonder why I have chosen to open with a “keeping documentation up to date post”,
while logically and chronologically this part comes at the END of establishing a DR plan.
Well, I have found that the “fear of documentation” is something that stops many organizations from even starting to establish their own BC-DR plan.
In this post I will cover some reasons for this “fear” and how to address them.
For the purpose of this post I’m going to assume that you are well aware of some BC-DR concepts, and other terms like change management.
If you are not familiar with them, fear not. In future posts of my Business continuity and Disaster recovery mini series, I will explain them.
Anyway, it will not stop you from getting the gist out of this post.

Please note that this post is dedicated to the documentation part of keeping BC/DR plan up to date.

Other parts, such as the technical part or the process itself, will be covered in future posts.

Ready? Here we go.

[pro_ad_display_adzone id=”7142″]
So, you’ve done a great project and you’re DR plan is rock solid.
You’ve even went to the whole process of writing everything down, and your DR plan is nicely documented.
But as time goes by, your organization changes, and your IT services are (hopefully) changing with it.
Resulting, of course, the need to change your BC-DR as well.
Fast forward to one year later – it feels like you have to do write the documentation all over again…
We’ve all been there.
In fact, keeping a documentation up to date is often one of the major reasons that makes individuals and organizations avoiding it in the first place.
If it keeps changing all the time, whats the point in documenting it, right?


Documentation, if done correctly, will save you tons of valuable time,
especially when it comes to DR plans (that’s when disaster strikes…)

But first, let us review some of the reasons making individuals and organizations
avoiding documentation in the first place

  1. It takes a lot of resources (mostly time)
  2. No clear vision or understanding of what should be documented
  3. No clear vision or understanding of how to document
  4. Fear from high cost of ownership (COO).

Simply put,
the fear from being “enslaved” to an ongoing, unclear, resource consuming documentation initiative often keeps us away from it.

Fortunately, this really can and should be a lot easier.

Here are some tips that will address the drawbacks listed above and will greatly assist you
in keeping you documentation up to date
  1. Establish a baseline (template) for documentation right at the beginning,
    and document only what you really need.
    If you give it a thought, you will soon realize that all of your systems / IT Services
    are covered by a specific, limited, number of disaster scenarios.
    My experience says that the number is somewhere between 6 and and 10.
    Create a template including these scenarios, and for each system or IT service
    write down the steps needed in order to recover from each scenario.
    This systematic approach help a lot in speeding the documentation process.
  2. Set documentation goals based on the impact on business activity.
    Higher impact means more critical system and higher priority to document and update.
    Some IT services are more critical than others.
    If you rank each system on a scale of 1 to 5 (5 being the most critical),
    than you have prioritized the order of applications and IT services to be documented.
    Furthermore, you may also realize that for IT Services at a certain level or below,
    the process of documenting and maintaining the DR plan for each service costs
    more than the risk. You may find yourself aggregating several documents into one,
    or simply taking a calculated risk of not documenting certain low level IT services.
  3. Add documentation phase to each project.
    Simple solution, but often over looked, or simply forgotten.
    Project time-lines are always very stressed. No one wants to bate late on delivery.
    However there is no better time to document whatever it is you’re doing while you’re doing it,
    or immediately after, while everything is still fresh in your head.
    Adding a documentation phase at the end of every project (or depending on the project scale,
    every project phase) really helps dividing huge documentation tasks into a small manageable chunks.
    Keep in mind however that changes implemented in one project, may effect multiple systems or “areas” of documentation.
    It is important to make the necessary changes in all places.
  4. Add documentation part to your change management routine.
    The logic here, is very similar to the one behind documenting as an integral part of a project.
    Instead of going through all the documents and manuals at a specific time of the year (which makes
    a huge work load) divide it into small chunks. Update the documentation as part of the change itself.
    You might then ask – What is a change?
    That depends on the baseline you established (remember tip #1?)

Click here to download a free disaster recovery update showcase document.

Wait just a moment!
That last showcase example (delete the corresponding documentation,
and all other documentation depending on it) looks like a lot of work!
Well, it might be, but not necessarily. Read on!
  1. Avoid keeping the same information in multiple places, keep links and placeholders
    A common mistake is to keep the same information in multiple places, so each system manual,
    or document is “complete” by it’s own.
    While there is some vague sense about it (all you need is in one place), it will actually make you work hard, for no good reason at all.

    My rule of thumb
    Whenever certain piece of information needs to be written (or included) in more than one
    system / application / process documentation –
    write it once and simply include a link to the source document.

    Yes, it means that a some system or processes documentation will spread across multiple files,
    but it is so easy to do, so easy to maintain and saves so much time during updates!

  2. Group similar systems (or applications) in one document.
    Assuming that you have several SQL servers, all with the same or very similar topology.
    Instead of writing a document for each and every system, you can simply write one
    document called “SQL Systems DR plan”. By doing so you will reduce the amount
    of DR documents to update, and make the update process easier.
  3. Group process or business activity related systems in one document.
    Another approach for minimizing the amount of DR documents, is to group systems or applications
    according the their relation to business activity or processes.
    For example if you have several logistics application that share information you can create one
    document called “Logistics system DR plan”. By doing so you will, again, reduce the amount
    of DR documents to update, and make the update process easier.
    This method is extremely useful in cases where several application are sharing or exchanging information, as it allows you to also document the interfaces (web services, file transfers, etc…) all in one place, making it easier to see and document changes over time.
  4. Not everything needs to be documented.
    As strange as it may sound, it is true.
    There can be two levels of over-documenting

    1. Documenting low-impact systems or applications.
      This section is purely based on risk management.
      Assuming that not all the systems in the organization have the same impact on business activity,
      their impact can be ranked on a scale of 1 (lowest) to 5 (highest).
      Simply ask yourself, are the efforts and resources needed to document systems with an impact
      rank of 1-2 is greater than the risk?
      Often the answer is no, as the knowledge for recovering those systems can be found
      in other DR documents, or that the required RTO for them is so high, that you simply address
      the issue when (and if) disaster strikes.

      My rule of thumb
      Rank all your systems on a scale of 1-5 as described above.
      Only document system with a rank of 3 and above.

    2. Over-documenting the systems included in the DR plan.
      Even after you have established a clear baseline of the systems that you should document
      (and keep up to date), be careful not to over document.
      Over-documenting means including information which is subject to frequent changes.
      examples for such information are

      1. The amount of allocated RAM (especially in VMs)
      2. The amount of free space per HDD

Last but not least,
Keep an index of your documentation activities.
Set a goal of updating each document once a year.

This is, actually, a very important part of keeping your documentation up to date.
In order to be in control of the documentation process you should be able to tell in any given moment
which of your documents require update.
That means that every-time you update a document, whether it may be based on my tips above,
or by any other method, you keep track of the date.
Personally I found that the best method of keeping this index is using an excel spreadsheet with columns
such as System name, Original DR document date, last update (add additional columns according to your needs).
Then using a simple formula you can have Excel show you which documents requires an update,
for example, last updated more than a year ago.

You can find an example (image) of my index file at the image to your right (click to enlarge).
All technical information and values have been obviously removed.

My rule of thumb
Make sure each DR document is updated at least once a year.

You may choose to go for once every six months, or every two years,
all depending on your business and IT needs.
But IMHO reviewing and updating (or validating) each DR document once
a year, guarantees that your DR plan stays up to date.
Combined with the rest of the tips I described earlier in this post, you
should find out that it is not so difficult, nor resource consuming thing to do.

However you choose to keep your documentation up to date,
and how frequent you choose to keep it up to date,
I hope you find the tools and techniques informative to you.

Above all I hope that you will never have to put your DR plan to any use, except for testing scenarios.
Good luck!

If you’ve read all your way through this post, you may also want to take a look at my own, personal BC-DR project for IKEA in Israel.

Also, please check my other posts in the Business continuity and Disaster recovery mini series.

[pro_ad_display_adzone id=”7145″]
Would love your thoughts, please comment.x
[pro_ad_display_adzone id=8566]