Understanding BCP, DRP, and COOP ◾ 313
© 2011 by Taylor & Francis Group, LLC
Where your end-to-end business process is complex, you may nd that while
the individual components have developed BC and DR plans, there has never been
an opportunity to test multiple component failure. e results of conducting such
an exercise can be very revealing. Each component lead will vie for priority restora-
tion, not fully understanding where their component ts into the end-to-end busi-
ness process. Further, your RTOs for each component may not be realistic. Using
project management tools for dependencies and critical path analysis will reveal
the actual maximum downtime, which is clearly not the sum of all RTOs, as some
components may be recovered concurrently while others have dependencies and
can only be recovered consecutively or contiguously.
Tracking and mapping the component recovery during the test will provide you
with valuable information to update your BC and DR plans.
Realistic Testing
Realism refers to the degree to which you are performing exactly the procedures
that you would during a disaster—a classroom role-playing test in which you talk
through steps without actually doing them is one extreme and a full execution
is the other. In both cases, one side of the spectrum tends to be less expensive and
less disruptive to day-to-day operations, but also less reliable in its results.
In general, it is a good idea to do a mix. Less disruptive tests can be carried out
more often. Problems found and xed that way avoid the typically higher impact
and cost of nding the issues during a live test. e NIST guide states, “It is impor-
tant that a test never disrupts normal operations.” We would modify that. If never
disrupting normal operations means never performing a full disaster recovery exer-
cise, then it is necessary to occasionally disrupt normal operations. Such disruptive
tests should be kept to a minimum, perhaps once or a few times a year, as long as
component and subsystem testing are carried out more regularly. It is important to
remember that it is always less expensive to expose yourself to the cost of a full test
in a planned way than to discover during a disaster that a subtle missed dependency
leads you to being unable to recover at all. I should note nally that it is important
to be thinking about the testing side of your plan throughout the previous steps,
since testing represents a signicant part of the total cost of your disaster recovery
plan. In particular, when considering particular solutions and vendors, make test-
ability part of the evaluation process.
Proper training is equally vital. Training in disaster recovery procedures should
be considered part of the regular orientation of new hires if they have any role at all
in implementing the plan. Key disaster recovery personnel should undergo frequent
enough training that they are intimately familiar with the procedures that they will
have to carry out under the plan. As noted in the NIST guide, ideally they should
be trained well enough that they can execute their responsibilities without the aid
of the actual disaster recovery plan document.