Now we're moving into section 13 where we are going to plan to test the disaster recovery plan itself. So in this section, we're going to examine various types of testing strategies and the process to maintain and keep the plan fully up to date and accurate. Now the testing strategies are many and various. The point of them, of course, is to make sure that we have a proper scope set on the plan the way it's been constructed and that all the members who will be directly involved in the plan's execution know what to do, where to go, etc. So the objective of the testing program is to ensure that the business continuity planning process has done a proper job in preparing the plan and that the plan itself outlines the things that we do in fact need to do and that everybody involved knows what they need to do.

As we do so much of the time, we begin with writing a policy. Doing so sets expectations for different lines of business and support functions to follow. The testing cycle should increase in scope and complexity over time. As we mature in the process, we need to measure our maturity. To incorporate a business impact analysis and a risk assessment should be part of any business continuity and disaster recovery planning cycle. Now the testing policies vary depending upon size and risk profile of the organization and they should reflect the more conservative or the less conservative position that the organization puts itself in.

So the testing strategy types are these. We begin with a desk check. This is, essentially, a completeness check of documentation, supplies, etc. In this kind of a test, no active performance other than a checklist takes place. It should be mentioned that this should not be the final form of the testing that is done, of course. And this should be done, in fact, during the process of building the plan to ensure that nothing has been overlooked. A common form of doing this is a tabletop exercise, also known as a structured walkthrough. This is a facilitated discussion of an event scenario to confirm familiarity with the plan so that, as the facilitator drives the discussion, the plan members are able to walk through, state what they know, confirming or affirming their lack of familiarity with the plan so that those gaps and weaknesses can be addressed. Now following this, should become a simulation of actually executing in a live, but what you might call, a false execution of a real disaster. This guided execution of a chosen scenario should involve varying degrees of actual task performance, but to this point, no attempt has been made to turn any systems off or close a building or any of that. Because at that point, we're probably not ready to do it yet. We can have the next step, a parallel, which is a functional operation of various portions of the plan, the resources and the various systems that may be involved. And then, ultimately, we have the full-interruption, where things are turned off and then the actual restoration is conducted. Now the way to look at this testing strategy is to look at it as a progression. As we build the plan, we do desk checks periodically, again, to make sure we don't miss anything. Then, as we get a portion of the plan complete, conducting a structured walkthrough of that portion would be appropriate to ensure that as the plan takes on more and more complexity, more and more activity, we confirm that people are more and more familiar with the plan as it is building. Various portions of the plan, as it's being built, may need to be simulated to ensure that we actually understand how it would happen. Doing a parallel test would be testing a system that would serve as a backup to an actual system should the actual operational system be taken out of service. And then, as we confirm that the plan is indeed ready for primetime, so to speak, we then conduct a full-interruption test. In this, we simulate the actual real thing in all of its scope. Turning everything off and going back to a full operation through the steps that we've outlined in the plan.

This is all part of updating and maintaining the plan current and accurate. The plan, of course, is a living document and must be maintained and encompass many of the changes that occur normally in an organization, changes in personnel, the comings and goings of people into and out of roles, the changing of technology, the changing of locations. Things of this nature affect the plan and how it will work and they must be accounted for in the management and update process of the plan itself. The procedures need to be reviewed periodically to make sure that they remain accurate and updated, whenever necessary. There is oftentimes a regulatory requirement to audit the procedures, audit the plan, audit the process and this will need to be performed to ensure that we are compliant, should there be regulations demanding that we do this. And then the simple matter of making sure that we do proper versioning so that everybody knows that they have the most current or that it's out of date and they need to obtain the most current.

We've come to the end of our next section. We're going to stop here and we will pick up again with Domain 7 with section 14 and the participation in business continuity planning. Please be sure to return and join us for that. Thank you.