Understanding BCP, DRP, and COOP ◾  307
© 2011 by Taylor & Francis Group, LLC
Preparing this section is simple because it is essentially the planning policy
statement that you prepared in Step 1. You may as well just include its contents ver-
batim here. is is also an appropriate place to include the record of changes made
to the plan whenever it is updated.
Plan Section 2: Operational Overview
e purpose of this section is to provide a concise picture of the plan’s overall
approach. It contains essentially two types of information:
1. A high-level overview of the systems being protected and the recovery strate-
gies employed
2. A description of the recovery teams and their roles
e section provides a context for understanding the plan as a whole. It should
be possible to read just the introduction and this section and have a good idea of the
overall approach to disaster recovery for all the systems involved.
Once again, you have already prepared the rst type of information in this sec-
tion during the previous steps: the business impact analysis and the development of
recovery strategies. An easy way to do this part of this section is simply to include
a copy of the Master System Information Form (SIF), which lists all the major
systems with individual SIFs and annotates them with recovery priority, maximum
outage time and business impact, major dependencies on other systems, and a brief
description of the recovery strategies employed. It is recommended that you include
all the individual SIFs in an appendix of the plan as well. ese serve as a useful
reference during reviews of the plan and ensure that all information is together
during future updates.
e operational overview should also contain a description of the teams that will
be responsible for activating and carrying out the plan. Detailed information on the
teams and the succession plan will be prepared in the next section, so the informa-
tion here should be brief, probably no more than a list of key teams and roles together
with a few words describing their role in the overall recovery plan. It is probably best
to develop this part after completing all of this phase of the work to ensure that it
reects the actual structure of the recovery teams after all decisions have been made.
Plan Section 3: Notification/Activation Phase
is is the rst of three plan sections that document actual recovery operations.
According to NIST Publication 800-34, this section
denes the initial actions taken once a system disruption or emergency
has been detected or appears to be imminent. is phase includes
308 ◾  Official (ISC)
2
® Guide to the ISSMP® CBK®
© 2011 by Taylor & Francis Group, LLC
activities to notify recovery personnel, assess system damage and
implement the plan. At the completion of this phase, recovery sta will
be prepared to perform contingency measures to restore system func-
tions on a temporary basis.
It is common for organizations to plan this phase inadequately. Most of your
work on the plan is focused on the actions that you must take to recover. It is very
easy to forget that declaring the emergency and deciding that it is time to initiate
operations under the disaster recovery plan can be dicult and require advance
planning as well. In fact, there is a very natural tendency, absent clear guidelines,
for people to delay action until they are “certain” that the disaster is imminent or is
bad enough to react. Unfortunately, by the time certainty is achieved, it is generally
too late.
is section must answer the following questions:
On what basis will the decision to activate the plan be made?
What information is required?
What additional guidelines are there for making the decision?
Who is responsible for performing the damage or threat assessment that will
provide the information above?
What restrictions or guidelines are there for how long the assessment may
take or how certain the information must be?
Who is responsible for the go/no-go decision?
What are the rules of succession, if that person is not available?
How will teams be notied?
How will recovery teams communicate?
ere are several things that should be kept in mind when preparing this sec-
tion of the plan.
When preparing guidelines for the activation decision, account for the fact
that there is a natural tendency to be conservative in assessing risks to avoid
being seen as an alarmist if the feared damage does not actually happen.
Wherever possible, provide clear, positive, and specic guidance on when the
person in charge should or should not activate the plan.
Make sure that the person responsible for decisions is in a position to know
what they need to know. For example, if the decision requires knowledge of
conditions at a site, it is best to designate someone located at that site, in case
communications are impossible.
In fact, communication is a key aspect that must be carefully thought through.
Depending on the type and scale of the disaster, common means of communica-
tion, such as cell phones, email, and landline phones may not be operational. Either
Understanding BCP, DRP, and COOP ◾  309
© 2011 by Taylor & Francis Group, LLC
alternative methods must be developed, like satellite phones or radios, or local
teams need to be empowered to make decisions autonomously and be given the
tools they need to implement those decisions.
is section may be an appropriate place to keep contact information on each
team member; alternatively, it may be included as an appendix. Keep in mind that
you can never have enough contact information. Especially for key recovery per-
sonnel, you may wish to include work and home phones and email addresses, faxes,
cell phones, neighbors, relatives, etc.
is is the rst point in the development of the plan where you must design
actual procedures to be followed during a crisis. It is impossible to develop good
procedures of any complexity without playing them out. For this reason it is criti-
cal that the procedures developed for this section be tested in actual use, just like
the recovery procedures themselves. It is also useful, during the development of the
plan, to role-play a crisis, preferably with the people who will actually be involved,
in order to think through the necessary steps.
Plan Section 4: Recovery Phase
is is the second of the three major sections documenting actual recovery opera-
tions, but it is the one that most of us have in mind when we talk about a DR
plan. is is the section of the plan that documents in detail the solutions to be
used to recover each system and the procedures required to carry out the recovery
and restore operational capabilities.
e organization of this section is simple. For the organization as a whole and
for each system individually, the plan identies a sequence of recovery goals (for
example, to restore Internet connectivity or to switch email services to a backup
system at a secondary site) and provides documentation on the procedures required
to accomplish each of them. Procedures may be as simple as a couple of bullets, or
they may be many pages of instructions and checklists, depending on the complex-
ity of the recovery solution and, of course, of the system.
ere are two aspects to your work in developing this part of the plan: actu-
ally implementing solutions that align with the recovery strategies you identied in
Step 4 and then documenting the procedures required during recovery. Implementing
your recovery strategy is, of course, the major work here. is includes everything
from evaluating and purchasing hardware and software solution components, design-
ing and implementing the solution around these components, equipping alternate
sites for your systems, negotiating with managed service facilities, vendors, and IT
consulting companies and so on. To lay out everything you need to know would
require a substantial book just for this discussion. Further, in this dynamic environ-
ment, details could be out of date as soon as published. erefore, you should take
the generic concepts and keep yourself up to date through conferences, research, and
general awareness through networking.
310 ◾  Ofcial (ISC)
2
® Guide to the ISSMP® CBK®
© 2011 by Taylor & Francis Group, LLC
You may also wish to consider outsourcing some or all of this work to a profes-
sional services organization that specializes in disaster recovery system development—
although it is important to understand that it will still take a lot of eort on your
part to ensure that they have the information they need about your organization.
Whether you are doing all of it yourself, outsourcing parts, or outsourcing
everything, it is a good idea to utilize other resources to help ensure that you under-
stand the options available and the trade-os involved.
ere is no substitute for action in this phasedo the recovery and write down
what you did. en do it again following the instructions, and see if they are correct
and complete. It is important that the level of detail in the instructions corresponds
to the level of knowledge of the least knowledgeable personnel who might need to
carry them out. To minimize disruptions, much of the doing can be simulated or role-
played, and procedures for individual subsystems can be worked out independently.
Nevertheless, it is extremely important that both nal documentation and nal
testing include full-scale tests as they are expected to occur during a real crisis. is
is the only way to discover subtle intersystem dependencies that might otherwise
be missed.
It is very important to highlight any points in the procedures that require coordina-
tion with other teams or other systems. is is information that should be easy to see by
skimming quickly over a given procedure. If the procedure is long and complex, it may
be helpful to include an overview of the major steps in an introductory section, or to
break out some of the details into separate checklists or subprocedures. Of course, while
completeness and correctness are key, the shorter and simpler the procedure, the better.
Remember that these procedures will be carried out in a high-stress environment, in
which mistakes and confusion are much more likely than during a practice run.
Plan Section 5: Reconstitution Phase
is is the last of the three sections of the plan that document actual operations,
and it is again one that does not immediately leap to most peoples’ minds when
thinking about disaster recovery planning.
Disasters eventually end and there is a need to return operations to normal.
Per the NIST guide, in this phase recovery activities are terminated and normal
operations are transferred back to the organization’s facility. If the original facility
is unrecoverable, the activities in this phase can also be applied to preparing a new
facility to support system processing requirements.
ere are two reasons why it is very important to think through and document
reconstitution procedures just as carefully as recovery procedures. e rst is that it
will help you ensure that the solutions you select are supportive of a relatively pain-
less return to normal. A solution that gives you easy recovery, but makes it hard to
get back, is not a particularly good solution.
Understanding BCP, DRP, and COOP ◾  311
© 2011 by Taylor & Francis Group, LLC
e second reason is even more important. Even though stress levels may be
lower during the return to normal, doing it without well-documented and well-
tested procedures risks mistakes that can transform the return to normal into
another disaster. e type of content and suggestions for preparing it are the same
as for the recovery section, so I wont repeat them here.
Plan Section 6: Appendices
e appendices should contain any information that (a) is necessary as reference
material during recovery, (b) may be necessary during any revision of the plan, or
(c) documents legal agreements. Examples include the following:
Team contacts
Vendor contact (including o-site storage)
Standard operating procedures (SOPs) and checklists for system recovery
or processes
Lists of equipment, system requirements for hardware, software, rmware, etc.
Vendor SLAs, reciprocal agreements, etc.
Description of/directions to alternate site
Worksheets used to develop the plan
Step 6: Plan Testing, Training, and Exercises
Testing a business continuity plan can be dicult. Simulating potential threats
to your business can be time consuming and expensive. However, testing your
business continuity plans will help show whether you have covered all angles, and
whether your plan is achievable. In addition, it can increase your business and trad-
ing partners’ condence in your business’ ability to recover from disruption. Tests
are also useful to raise sta awareness of the plans.
You can test whether sta can function without access to data cheaply and eas-
ily. Such tests can also help to check that other sources of data, such as backups or
archives that are held o site, are suciently up to date.
How often should plans be tested? At some point, usually around 12 months after
the plan has been developed, you should carry out a real restore of data—use data
that has been backed up to get your system fully operational again—and attempt to
work without premises or les. is will help to establish the following:
Whether your expected timescales for recovering key business applications
are realistic
How prepared sta are for putting the plan into action
Whether any third parties or service providers who are integral to the plan
are ready to respond
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.191.78.136