So let’s review how we have come to this point in the process. In Part 1 we discussed the general strategy of the BCP program and the IT participation in the process.
In Part 2 we moved into the definition of the BCP Tiers and the factors involved to begin mapping our systems and requirements.
Then in Part 3 we built the BCP Recoverability Matrix. In Part 4 we need to delve into the applications and detailed documents associated to them.
The Application Recovery Document
It cannot be restated enough that the key feature of an effective BCP program is effective documentation. The Application Recovery Document (shortened to ARD for ease of writing) is going to be the most important of the overall document store.
What I mean to say that the ARD is the most important, is that it is designed to be a self-contained recovery instruction set for each individual system. For this reason, the ARD is also the most challenging to put together.
In an article I wrote about Writing for your Audience I brought up that we often refer to having to “write it so a monkey could do it based on your instructions”. This is one instance where you will need to the level of detail is critical. We have to assume that in the event of a disaster event that we may not have our key resources our Subject Matter Expert (SME) for each system to perform the recovery.
To get you started, I’ve uploaded an ARD template here which should be a good baseline to work from. I encourage you to read it through thoroughly and add any customizations which will make the readability, and usability as best as possible to suit your needs. Ultimately, this is the crust to your finest pie. Foundation is everything.
Inch by Inch, Row by Row
Much like a the nursery school rhyme about a garden, you will build the ARD for each system/application listed in your recovery with detail and order. Each section of the document clearly defines the point in the recovery process and the specific steps will be listed throughout.
Most of this portion of the BCP program must be flavoured to taste based on your specific business requirements, technical requirements and ability to capture and convey clear instructions and process flow.
You will include every relevant piece of information including batch processes, backup processes, operational details, data management requirements, dependencies (this is very important!) and line by line detailed steps to complete a full system recovery.
Dependencies are particularly important because as you build the detailed recovery timeline, you will have full details about recovery order based on dependencies and requirements of your systems.
As you can see, there is a section called Return to Normal/Home Phase which is also an absolutely important detail in the recovery process. Remember that BCP recovery isn’t just a one way trip. You will at some point be recovering your environment again in the primary data center.
During BCP tests you will also follow the recovery to home process, and in fact you may have specific instructions for test recovery which differ from normal production recovery because you may have data used for test fail-over which is not necessarily designed to be brought back over to production whereas during a true fail-over you will want to preserve changed data and bring it back to your primary site.
Storing the documents
Another important part of your BCP program is the storage of your recovery plans, BIA, contact lists and fundamental information required to complete the secondary site recovery. There are numerous systems which are available to store, replicate and manage your documents to have them available during test and real recovery scenarios.
You are encouraged to look an many alternatives, and if you have a vendor of choice for your BCP site recovery, you should work with them or an appropriately skilled team to manage this part of the overall program.
Please also be aware of any legal requirements and limitations for information storage, and specifically on contact information. Your legal department and Human Resources will inevitably be involved in the BCP program, and you should ensure that they are fully aware of the details being held in your document repository. There may be regulations based on your geography or industry that will differ from others.
I love it when a plan comes together
John “Hannibal” Smith couldn’t have said it better. While the ARD and the infrastructure components are important, they are of little value unless you can piece together the recovery sequence with a plan. Your BCP coordinator will either be, or work closely with your Project Management Office (PMO) for designing and maintaining the recovery test plans and the full fledged recovery plan.
We speak of the “test plan” versus the real plan, but in fact they should be one in the same. The only difference with the test recovery is some of the data recovery processes which will be clearly documented in the ARD for each system.
Please excuse the vagueness of this as the template for a BCP recovery plan can differ greatly from organization to organization. If you would like some samples I would be happy to provide some if you Tweet me.
This portion of the post series was lighter on detail because at this point it will be very organization-specific with the high level details such as vendor choices, recovery site layout and other personal choices in the BCP program. It is also heavily affected by budget constraint. Now that we have built the fundamentals of what goes into the BCP design, you are able to apply your own organizational detail based on your requirements, ability, vendor choice and vendor involvement level.
The final post in the series will talk about the BCP recovery test process and bringing all of the steps together. We’ve built a great foundation of detail, documentation, knowledge capture and increased familiarity of our systems. Now we just have to put the plan to the test to validate what we’ve done.
And finally on to Part 5!