288 ◾ Official (ISC)
2
® Guide to the ISSMP® CBK®
© 2011 by Taylor & Francis Group, LLC
e cost for any outage can be calculated using a variety of data. For example, if you
are processing customer orders, you can calculate the total value of historic order levels
against your recovery time objectives. Remember to add in any penalty payments.
What are the points of contact between the current process or system and any
other systems on which it depends? e answer to this question gives us the next layer
of the onion and how it interfaces with the current one. For example, the sales process
may involve personnel working with a customer relationship management (CRM) sys-
tem. e point of contact there may be via a Web portal into the CRM application.
e CRM application is itself a system that may consist of Web servers, CRM
application servers, and database servers, all with the portal as a point of contact
with the sales process. Later you may consider the CRM layer and its points of
contact with, for example, the storage systems, if they are administered separately.
At the end of the chain, of course, are basic infrastructure resources and systems
such as electric power, telecommunications connections, and environmental con-
trol systems—these must be considered as well since they may well be impacted by
some of the disruptions for which contingency planning is being undertaken.
What are the critical roles in the process? e point of this information is two-
fold. First, in many cases these roles must be taken into account for recovery. If a
process requires the intervention of a person for monitoring, management, analysis,
or maintenance on a regular basis, how long can the process run without that role
in a crisis? For IT systems, in particular, there may be IT administrator roles that
will play a critical part both in the recovery and in running systems for the duration
of the crisis. e second reason these roles are important is that the people in them
represent critical sources of information for determining system dependencies and
requirements. ese are the people who must be closely involved both in this phase
of the planning and in subsequent testing.
Essentially, the same analysis should be performed for data and roles. Again,
what is the impact that results from unavailability or loss of data or from the inabil-
ity of someone to fulll a specic role? In the latter case, this may occur because the
person is injured or otherwise prevented from performing his or her duties, but it
may also be a result of the lack of access. If an epidemic were to occur, for example,
so that people were required to work from home, as happened during the SARS
epidemic in 2003, people might be quite capable of working, but unable to do so
because they lack access to the resources they need.
Carrying out this sequence of analyses yields, in eect, a full chart of dependen-
cies that runs from the outermost layer of business processes to the innermost layer
of core infrastructure on resources, people, and data. is is a very valuable tool
for later test development and maintenance and should be included in the disaster
recovery plan in the System Description and Architecture section described later.
Once this analysis is complete, it is time to develop recovery priorities for IT systems
and individual components, beginning with the latter. is task is straightforward
if the work described in this section has been done thoroughly, since the priorities