Having mentioned a Business Impact Analysis several times, the text presents a chapter dedicated to it. A BIA should build a list of the assets that are critical to an organization, but it should also let you rate how important all the other assets are as well.
The text tells us to learn three concepts that relate to a BIA:
As the text explains it, the BIA process is meant to tag the things that are most important to our organization, whether they are IT systems, processes and procedures, or components of a system. We are not charged with identifying everything on this mission, that should have already been done. We are just identifying the important things.
That being said, we need to set the scope for our inquiry. Are we determining
the the important things for all users, or a subset of all users? We should
determine who the stakeholders are for the system, the division, the location,
or the function we are documenting. It would always be better to include
stakeholders for all aspects of our organization, but there may not be
time, funding, or interest in doing a BIA for the entire organization.
In the illustration on page 319, the author shows us assets that concern a customer making an Internet purchase. The author points out that even short downtime for the firewalls, web server, and database server all affect the immediate experience of the buyer. However, the buyer is not immediately affected by longer downtime for the warehouse or the shipper. The customer does not expect immediate shipment or delivery, unless we have made a silly promise that such a thing will happen.
page 320, we see a graph that
shows time increasing along the
x-axis, and cost increasing up
the y-axis. Its point is that as outage
time increases, cost of a disruption
increases as well. In fact, the graph indicates that the longer
an outage lasts the faster the
costs go up. A second curve is also shown on that graph. It shows that
the costs to recover from an outage
diminish as time goes on. The
graph is similar to the ones you will see on this technet
web page. The argument to make from this data is that there is a point
where the two curves intersect, and that this point defines the time at
which the combination of outage cost and recovery cost is typically the
The next section of the chapter walks through the example of the customer making a web purchase from our organization. In pages that follow, the text outlines a procedure to identify what is important.
When considering the maximum acceptable outage, you should also define
what the text calls the recovery objective. You will have to specify what
conditions define "recovery" to you and your organization, else there
will be internal and external disagreements about the state of recovery
having been reached.
Just to make sure we understand the material this chapter presents, the author presents it again, and then one more time. Oh, my.
To make this chapter, like most of the others, a stand-alone chapter, the author begins with another statement about the nature of a Business Continuity Plan. Remember that this is the plan for continuing critical business activities while we are experiencing some kind of crisis. To continue conducting business we must:
It should be obvious that we are considering the IT needs of the business for our part of the BCP, but we should be aware that assembling the full BCP requires a great deal of knowledge about what the organization does, who does what, what the management structure is, what our various locations need to stay operational, what alternatives we have for continuing operations when locations must halt operations, and more.
The text spends several pages trying to make general recommendations for the information that you need to gather about the items above, and about the things to look for that will enable you to keep them running. It may be helpful to consider a business continuity plan as having three operational phases that will be used while it is needed.
The text cautions us to hold periodic reviews of BCPs, in conjunction with practice sessions when and where possible.
The chapter ends with some recommendations for best practices: