If you browse the scenario that opens chapter 2, you will see several people role playing a contingency. They are doing it in two parts. One is to run through a plan that is already in their operations manual. The other part is to involve the people in the room, to develop questions about the planned response, and to determine whether they are doing what should be done. In this case, they have a plan for a contingency, they are walking through the plan, and they are learning about the merits of the plan. They should not just be reading their assigned parts. They should be thinking about the reality of doing what they are assigned and proposing amendments to improve the plan.
The text talks about forming a body that will be responsible for creating contingency plans. That body has a number of duties, some of which should be done before it starts;
The text offers suggestions about the kinds of knowledge that will be necessary to create the contingency plans. Note the section about representatives from other business units, which include the company's actual business, IT management, and IT security management. Remember that these are the three axes of the CNSS security model. On page 52, the text tells us that there also needs to be commitment from management in these areas to create useful plans that will be available when they are needed.
In the scenario at the beginning of the chapter, we are left wondering whether the manuals being used by people from different work areas were identical, or different in some ways. There should be specific pages for some staff, depending mostly on the specialization or security level of their jobs. However, there should also be a master copy with all the sections in case someone needs to step in to do another person's job.
The text delivers a lot of details about a lot of details for several pages. Moving on to more focused material, let's continue on page 57 where we see five "Keys to BIA Success":
The first of three phases of a business impact assessment begins on page 58 with making a list of the critical processes/functions of the organization you are studying. In the first column of the example chart on page 59, you see seven functions performed by company. (The text notes that this chart of seven functions is an example, and that a real chart for a real company would be much longer.)
In the columns to the right of each function name, four kinds of impact are considered. Each kind of impact has been given a percentage rating, reflecting how much the company cares about it. Note that the sum of the percentages is 100%. If it were not, we would have to assume we are not measuring the impacts correctly, or we are measuring the wrong impacts.
Each function is rated on a scale, probably from 1 to 10, on how much its loss would affect each kind of impact. Note that the columns and the rows do not add up to a specific value. There is no presumption that they should. To get the weighted score for a function, its raw score for each column is multiplied times the percentage for that column, and each of those weighted scores is added together. The weighted score for each function is a measure of its criticality to the company's ongoing business.
In the chart above, I have marked the three functions that
have the highest weighted scores. They are the ones we need to protect
the most. Preparing a chart of this sort, or a series of them, leads to
our knowing which business functions should get our attention first and
Page 60 brings up a related idea. Some functions will have a different criticality when we consider which to bring back from a damaged or disabled state first. Some functions rely on other functions to make them possible. In cases like this, it is necessary to prioritize the recovery of any service that a critical service depends on. With that in mind, it makes sense to consider the downtime metrics discussed in text. (This is considered further in the table on page 63.)
In the small chart on page 62, the text shows us two curves plotted on the same graph. The Cost to Recover is highest if we have a constant live copy of the data, and lowest if we use an old-fashioned tape backup system. The old system looks good until we note that the time it takes to use it causes a much longer disruption time, which has associated costs that go higher the longer the disruption takes.
The simplified version of this chart, shown on the right, makes the same point, but is may be easier to see. The projected cost to the organization in any scenario using these curves is the total cost of the red and the blue lines at any given point.
Reasonable expectations about tolerable downtime and recovery
time lead to a compromise that the text shows as the Cost Balance
Point. If we spend more on our recovery system, we can expect less time
that the system will be down, lowering the costs that down time
creates. You need to plot those two curves for your own organization to
determine what the best choice is.
The text returns to the idea of determining the priority of each process to the business, and each system or asset to the functions that use or depend on it. This is discussed again on page 63. At this point, you would think you would know a lot about the company's assets, functions, and priorities. the text turns to data collection on page 65. eight data collection methods are listed, then discussed for the next twelve pages. Which one is best? The one that gets you to the truth. Keep that in mind. People often answer questions with either your agenda or their own in mind. Ask without pressure, and you may get better responses.
The last major topic in the chapter is budgeting. The text lists four operations that will require a budget. They are four familiar areas by now.