Chapter 5 Business Impact Analysis Chapter Summary The Business Impact Analysis (BIA) is a key activity necessary to develop the Business Continuity Management System and to satisfy major requirements of the Business Continuity Standards. It identifies the financial and operational loss of the organization’s business functions and processes over periods significant to the individual organization regardless of what caused the loss by examining their impact on service objectives, financial position, cash flow, regulatory and contractual issues, and competitive risk. Information useful to understanding the context of the organization and the collection of resource requirements necessary for the implementation of the business continuity plans are often included in the analysis. The information developed because of the analysis allows management to make decisions concerning their Maximum Acceptable Outage (MAO) or the Maximum Tolerable Period of Disruption (MTPD). Another similar term, the Maximum Tolerable Downtime (MTD) is used as the maximum downtime the organization can tolerate for a business process or the length of time a process can be unavailable before the organization experiences significant (unacceptable) losses. The impact is stated in both financial loss and operational loss. Operational loss is used when it is difficult to characterize the loss or degradation of a function in financial terms, assigning a subjective severity level from one to five or Low to Critical. This then allows management to set Recovery Time and Recovery Point Objectives (RTOs and RPOs) for each critical or prioritized business function. Work Recovery Time (WRT), is another concept developed by the analysis. Based on this information, business functions are designated as critical or noncritical to the goals of the organization. The upstream and downstream dependencies of each function within the scope of the analysis are highlighted. The data for the analysis is collected through a combination of workshops, questionnaires, and interviews with functional managers from all components of the organization that are within the scope of the analysis. Detailed sample questions allows the analyst to identify gaps in the prevention, preparedness, response, mitigation, and recovery of each business function’s resilience and include recommended corrective actions to close gaps suggested by the answers revealed on the questionnaires or during the interviews. Pandemic Flu preparedness and response, supply chain risk, and legal and regulatory compliance are addressed. The manner in which the BIA is documented is important to auditors and to management so that the objectives of the analysis are clearly illustrated. It should identify the MAO/MTPD and RTO for each process, product, or service, and internal and external dependencies. It must provide an understanding of the negative impacts over time that the failure to provide these products, processes, and services would have on the organization. It describes the risk to the organization of not resuming its business activities. BIA documentation should be regarded as confidential, controlled information. Key terms BIA analysis; BIA documentation; BIA project planning; Business impact analysis; Business impact analysis questionnaire; Financial impact of risk; Maximum acceptable outage (MAO); Maximum tolerable downtime (MTD); Operational impact of risk; Pandemic planning; Recovery point objective (RPO); Recovery time objectives (RTO); Supply chain risk; Work recovery time (WRT) Key Points • The Business Impact Analysis (BIA) is necessary to develop the Business Continuity Management System • It is key to understanding the context of the organization • The Business Impact Analysis identifies the financial and operational loss of the organization’s business functions over time • It provides data to establish the Maximum Tolerable Downtime (MTD), Recovery Time Objectives (RTO), and the Recovery Point Objectives (RPO) • The BIA presents management with a financial basis for selecting the most cost-effective continuity strategies • Identifies gaps in prevention, preparedness, response, mitigation, and recovery 5.1. Introduction The Business Impact Analysis (BIA) is a key activity necessary to develop the Business Continuity Management System. It is necessary (apart from the requirement in the standards) because it defines almost all aspects of the business continuity program. This process allows the Business Continuity Manager and other important key players including interested parties to understand the context of the organization. It identifies which business functions and processes are critical to the survival of the organization. The International Organization for Standardization (ISO) defines BIA simply as the “process of analyzing activities and the effect that a business disruption might have upon them.” ASIS does not seem to define the BIA. The BIA identifies the financial and operational loss of the organization’s business functions over periods significant to the individual organization regardless of what caused the loss by examining their impact on service objectives, financial position and cash flow, regulatory and contractual issues, and competitive risk. The BIA process will help to establish the importance of each of the organization’s functional units in a manner that avoids the bias of opinion by the functional leader (i.e., if you simply ask the leader of a function how valuable his or her operations are to the organization you may receive the useless response “Of course all of my functions are the most critical to the operation of the organization”). This allows the ranking of functions by importance and tells the Business Continuity Manager exactly which functions need to be recovered and at what level they need to continue without interruption, that is, which functions are the most mission critical and at what times of the business cycle they are the most critical. In many of today’s lean organizations, however, few business functions can be deferred for any period, or, in other words, few are not critical. It will identify which data processes and computer applications are the most important to the resilience of the organization and the continuity of its key business objectives. The ranking produced by the analysis will show where to concentrate funds and resources and in what order the functions need to be recovered if not included in a high-availability category. It will also • Identify the financial and operational consequences of a function’s loss over time • Highlight interdependencies from one process or function to another and to any third party relationships • Establish the Recovery Time Objectives (RTOs), Recovery Point Objective (RPO), and the Maximum Tolerable Downtime (MTD) • Aid in the understanding of where to focus risk treatment • Refine the scope of the Business Continuity Management System • Identify critical resource requirements to support the management system and to implement the continuity strategies • Determine the legal, regulatory, and contractual obligations related to business continuity or to the failure to provide a service or product • Serve as a venue for the awareness of the business continuity management system • Reveal potential inefficiencies in normal operations. The results of any LEAN initiatives that produce process mapping can be incorporated into the BIA and provide a deeper level of “understanding the organization” • Begins the process of continuity strategy development and allows the organizations to select the most cost-effective strategies • Understand where to set escalation levels for IT or other support systems and potentially when to activate the business continuity plan The BIA presents management with a financial basis for selecting the most cost-effective continuity strategies. The BIA of a Fortune 500 company with worldwide operations located on the west coast of the United States showed that a disruption of their product supply would cause the loss of prime product placement space on the shelves of supermarkets resulting in a tremendous loss of sales over a short period. Shopper’s eyes naturally look first at certain locations on shelving and tend to select products in this space over others. Once this prime placement is lost, it is difficult and time-consuming to get back. The main computer operations for the entire company were concentrated in a single location, less than a mile from the hypothesized epicenter of a future major earthquake. The company decided the best strategy was to build a second, backup data center in the Midwest at a cost of $6 million. All data going to the primary data center would be mirrored in almost real time to the backup center. As this plan was in the implementation phase, the economy suffered a sustained downturn imposing a significant financial hardship on the company and placing the completion of the second data center in jeopardy. However, they were able to return to the BIA and used its information to better prioritize the continuity of their business systems resulting in a revised strategy that mirrored only critical data and implemented a less expensive solution for data processes that did not need to be restored for days to weeks. By better focusing on the results of the BIA, the company was able to save $3 million in their second data center strategy. The BIA also highlights times throughout the business cycle when certain business functions, processes, or service objectives are more critical that others allowing the Management Team to adjust strategies or resources based on the timing of the disaster. Not all business functions need to be continued without interruption or recovered all at once. Some are more or less dependent on seasonal variances. The BIA will show these variances. 5.1.1. Recovery Time Objective and Recovery Point Objective The information in the BIA from the example above showed that not all business processes need to continue without interruption. The RTO is established for each business function and the processes that support the function. The standards define the RTO as the period following an incident within which a product, service, activity, or resource must be resumed or recovered. ASIS defines it more precisely by saying it is the goal for the restoration and recovery of functions or resources based on the acceptable downtime and acceptable level of performance in case of a disruption of operations. The RTO is the amount of time by which the organization would like to have the process or function back in service after an outage. It is based on the Outage Tolerance, a term replaced by the Maximum Acceptable Outage (MAO) or the Maximum Tolerable Period of Disruption (MTPD), which is the time it would take the loss or degradation of a business function or process to have an adverse impact on the organization’s objectives such as the delivery of a service or product. Another similar term, the MTD is used as the maximum downtime the organization can tolerate for a business process or the length of time a process can be unavailable before the organization experiences significant (unacceptable) losses. The RTO, MAO, and MTD are ultimately a management decision based on the results of the BIA and the agreement between the process owners and management about what level of loss or impact is acceptable. This tolerance can be zero, hence the terms “continuity,” “high availability,” “0.9999% uptime,” and so on. Alternatively, the organization can decide that a minimum acceptable level of production, service, or delivery of product is adequate to remain under the MAO over time. In determining the RTO, consideration must be given to the goal to have processes reestablished before the point is reached at which the outage begins to cause unacceptable harm or, in other words, before the MAO is reached. The RTO of each business function is a major deliverable of the BIA. As the above example illustrates, the RTO will guide the organization toward the selection of the most cost-effective continuity strategy. The strategies necessary for the lowest RTO, that is, those with the least tolerance for an outage, are usually the most expensive to implement, a longer RTO will allow for the selection of lower cost options. The RPO, also referred to as the Maximum Data Loss, is the point at which information used by an activity must be restored to enable the activity to operate after its resumption. In other words, how much loss of data or loss of records is the organization willing to accept or how current does the data need to be to start the recovery? In many cases, the tolerance for data loss is near zero, but at what point do you begin the reconstruction or reentry of records? This is often used to decide what form of backup strategy is used. Tape backup, for example, would mean a day or more of lost data. Similar to RPO, the Work Recovery Time (WRT) is the time necessary to catch up from any backlog created by an outage. 5.2. Business Impact Analysis Process The biggest predictor of the success or failure in the development of a Business Continuity Management System that will actually meet its objectives at the time of a disaster is the amount of demonstrated management support for the program. Without this, many business continuity programs take too long to develop often causing the entire effort to fail. A poorly constructed BIA, or the lack of one, is another contributor to failure, causing the misdirection of resources and decisions based on poorly defined risk. Apart from the requirement of the standards for management commitment, it is the BIA and Risk Assessment that will help to solidify this support by demonstrating the financial and operational risk the organization could face. But how does one begin this process if the support is not yet solidified? After all, the BIA will require a large block of organizational time to interview process owners and have them complete informational questionnaires. In this case, the management sponsor can be used to introduce the program and to motivate all process owners to participate in the analysis. In addition to management’s support, the following major elements of the BIA process include: • BIA project planning • Data collection • Data analysis • Documentation and Communication of analysis • Reanalysis 5.2.1. BIA Project Planning One way to avoid failure and to maintain the momentum of the analysis is through good project planning. The BIA should be completed in the shortest time possible to avoid the loss of momentum established by management. The loss of momentum can cause the effort to languish to the point that the information produced is no longer accurate or descriptive of the current state of the organization. A project plan incorporated into a descriptive document that outlines the approach and methodology used to complete the analysis will show a third party, such as an auditor, that all elements of the analysis have been met. It is important to determine what method will be used to complete the analysis, especially how the data will be collected that must be illustrated in this document. Just as important in the project planning phase is the understanding of the scope of the analysis. The scope will most often run parallel to the scope of the Business Continuity Management System, but often the scope of the former is not determined until the latter. The scope of the Business Continuity Management System, if already established, can be refined by the results of the BIA (many organizations will start with the BIA, examining all functions of the organization before they decide on the scope of the management system). As we mentioned in a previous chapter, use caution that an out-of-scope dependency of something that is in scope must be included in the analysis and therefore included in the management system. After management commitment and a definition of the scope of the analysis are established, the next step is to review any previous BIAs. If one was recently completed, it may simply become a matter of revision and update (see Reanalysis below). If not recent, it should provide valuable information about products, process, process owners, and acceptable risk. It could provide clues about a presentation and report format acceptable to management that can be used for the current BIA. If no previous analyses exist, review the organization’s marketing data, stock reports, or other regulatory filings. Insurance reports and financial audits are also good sources of information. Examine the results of any Lean Kaizen initiatives where process flow charts such as Fishbones or Value Stream Mapping may have been produced (this information is gained from an interview with manufacturing or quality managers). An organizational chart is also a valuable tool to assist the manager with planning the BIA. The results of the BIA should provide much of the same information in the end, but it is useful to at least have a basic understanding of the organization before its start. This understanding will help the analyst ask more pertinent questions during the data collection, or process-owner interview phase. Decide what data to collect. Information that helps the manager understand the organization, and that returns financial and operational information to establish risk and prioritized treatment of IT and functional processes is the main focus of the BIA. However, to minimize the need to meet with a number of individuals a number of times, Business Continuity Managers, and especially Business Continuity Consultants, will often combine the process of initial strategy and resource development with the BIA. Although one relates to the other, some managers separate these tasks for simplicity and for the expedience of not asking for too much information all at once when a need for an all-at-once approach is not demonstrated. If using an outside consultant to develop the program, combining these phases of program development will likely result in a less expensive effort. Strategies and resource information developed in this manner may need to be refined later. In our description of the BIA process, we will assume the analyst will follow the combined approach as is the common practice in the industry. BIA software programs are generally structured to follow this approach. Next, decide how the information for the BIA is to be collected. Some managers rely on the CFO to provide the necessary financial information, but this practice does not allow the manager to effectively gain the level of understanding of the organization or serve to begin the orientation and training that functional leaders will need to gain the knowledge to begin the business continuity process for their areas of responsibility. The CFO is the person who may be legally responsible for the protection of financial data so would likely be a valuable resource to the BIA. The results of the BIA must not only be acceptable to an auditor, but ultimately must be acceptable to senior management. The credibility of the information is vital especially if developed by an outside consultant. The advantage of obtaining the data from the CFO is that it is more readily accepted because a top-down approach produces data from those closer to senior management, but has the disadvantage of less interaction with others in the organization to orient them to the concepts of risk ranking and initial strategy development. The CFO can help to clarify or refine the contents of the analysis. The CFO can also provide the analyst with an idea of the general time frames in which risk becomes unacceptable or what the Recovery Time Objectives will look like—information useful to the analyst when developing the financial impact profiles; in other words, will an outage become unacceptable after just a few minutes or after one to two weeks? Other managers rely purely on the distribution of questionnaires sent to functional leaders to collect the data. This method can produce results in a greater amount of time than other methods, but also does not carry the advantages described above. Ideally, the collection of the data is best accomplished through a combination of personal interviews with the functional owners and through the distribution of a list of questions before the interviews take place. This gives the functional leader time to understand what the analysis is looking for and to formulate a more complete answer. When the questionnaires are returned to the analyst prior to the interview, he or she will be better positioned to ask follow on or clarifying questions. Often, questions arise after a review of the written response that would not have occurred to the analyst to ask initially or the functional leader may identify important areas for discussion that are not addressed in the questions. Determine what functions or business processes are within the scope of the analysis and who within these functions need to be interviewed. This generally includes the functional or process leaders. The trick is to avoid going too high in the organization (but speaking with these people is not a mistake) because persons in these positions may be too far from the day-to-day operation of the functions under their control, but also avoid going too low in the organization as these people will not likely understand how their jobs map to others or are unaware of the function’s interdependencies. When selecting groups to interview for the BIA, try to think ahead about what business functions will have continuity or recovery teams. Continuity teams are groups of employees and/or third parties that will implement the continuity strategies. The teams are generally aligned along functional groups such as the Human Resources Team, IT Infrastructure Recovery Team, the Customer Support Team, and others. Teams are segregated by separate alternative work areas, differing continuity strategies, different resource requirements, and the like. This, however, will not likely be the case if organized under an Incident Command System structure. One word of caution: some literature suggest that the manager only meet with and interview the owners of “critical” processes, but it is the BIA that helps the organization to decide what is critical to the continued operation of the organization and what is not. Do not make the mistake of including in the analysis only those functions you or management believes up front are critical. All functions within scope of the analysis should be analyzed to decide what is critical, and to what degree other functions are not critical to the continued operations of the organization. 5.2.2. Data Collection As described above, decide how the data are to be collected. We believe the best method is to identify the functions in scope and develop a set of questions to send to the function owners prior to a meeting to discuss the questions and data that are required for the analysis. As we will explain later, the questions sent to functional leaders must be accompanied with detailed instructions, but some business continuity managers prefer to conduct a short orientation session with all of the functional leaders as a group to introduce the process and outline the expectations of their participation in the analysis. List those functions that are within scope. This may include every function within the organization, but may also include third parties outside of the organization (see the interview questions for Purchasing/Procurement for example). Consider: • Customer Service • Engineering • Facilities, Real Estate, Custodial • Finance (Accounting, Accounts Payable, Accounts Receivable, Accounting, Payroll, Cash Management, Order Entry, or others that may be pertinent to your organization. These functions, depending on their complexity and relations to the others, may be treated separately or combined. This will also apply to functions listed below.) • Human Resources, Benefits • Information Technology (Desktop systems, Servers, Infrastructure, Environment, Security, Disaster Recovery) • Insurance, Risk Management • Legal • Marketing • Operations, Manufacturing • Public/Media Relations • Purchasing or Procurement, Supply Chain • Research and Development • Sales • Security, Safety • Shipping, Receiving, Distribution, Mailroom • Telecommunications • Warehouse, Stores Once the functions are identified, prepare the questions you will need to ask during the interviews. At a high level, the questions are designed to: • Understand risk to the functional unit and ultimately to the organization • Understand the organization. What are the primary service objectives of the business unit or function, how does the function fit into the overall mission of the organization, and what are the function’s dependencies? What other functions are dependent upon its continued operation are questions that should be answered • Rank functions to determine criticality (RTO, RPO) • Identify gaps in prevention, preparedness, and mitigation • Serve as a beginning for strategy development (we will discuss strategies in a later chapter, but for now remember that continuity strategies generally consist of an alternate work site, an alternate location where IT functions are available, and a means to connect the two. On a lower level, each business function may have additional specific strategies to continue its functions, such as a plan to collect and deliver mail to relocated workers) The questions and the subsequent meeting are also designed to orient functional owners, who later may become team leaders, to the program. This is an opportunity to build interest and support for the program at the midmanagement level. If the business continuity manager or consultant combines the BIA process with strategy and plan development, questions are also designed to provide information that the planner can cut and paste or electronically import into planning software to include in the individual continuity team plans. The questions consist of two major categories. The first contains questions common to all functions, and the second are questions focused specifically to each function. Sections included in the common questions are descriptive of the function, a discussion of risks to the function, information on potential alternate locations, team leaders, and alternates, and sections that ask for financial and operational risks that list legal and contractual dependencies. The focused questions may also seek information related to resource needs for the continuity teams that can start with initial strategy development and implementation. Resources needs include the continuity team list and contact numbers, internal and external contact numbers, forms and supply needs, software requirements, and vital records. Implementation can be addressed by asking the question “What are the first 30 things your team would need to do if access to the building was denied for 2 weeks?” See Appendix D for sample questionnaires. The questions are then combined (general and function specific) into a questionnaire that is distributed to functional leaders in either paper or electronic form. An electronic form can consist of a simple word document or spreadsheet or an executable toolkit questionnaire produced by a commercial BIA software program. These programs allow the completed toolkits to upload into the program for compilation and varying degrees of analysis, graphing, and reporting. The rigor of the final reports produced by the software is not likely to be sufficient for certification, but can be a good start. If a commercial software program is used, ensure that it is compatible with the IT systems in use within the organization. Users who have difficulty with the installation of the program, especially if the difficulties are widespread, will likely not become champions of the process. Be prepared to assist with the installation of the software. If a group meeting is held to introduce the BIA process as described above, this may be a good venue to walk users through, with the help of IT representatives, with the installation of the software, especially if laptop systems are used. If the questionnaire/toolkits are sent in advance of the interviews, as we recommend, an explanation of the intent and expectations must be included. Detailed instructions, especially if commercial software is used, must also be sent to the recipient. Expect the recipient to know very little to nothing about what you expect or how to answer the questions, especially those that pertain to financial and operational impacts. Consider using screen captures and examples in your instructions. This can also be accomplished verbally in an orientation meeting. Meetings with each functional leader are then scheduled roughly 2 to 3 weeks or more after they receive the questionnaires, but not so far that they become deprioritized. Reasonable timelines should be established and progress reported to management on a regular basis. Functional leaders may not understand what you are asking and return information that is off the mark. In addition, information returned may not be as complete as necessary. Tracking the tasks in a project plan or via a heat map is an important metric that will help to illustrate progress toward the milestones the manager established. When establishing timelines, consider the workload constraints of the organization. Beginning the BIA at the start of a seasonal rush or product introduction will lead to a higher degree of difficulty to achieve on-time results. Typically, once the communication describing the project and tool kits/questionnaires are distributed, allow for a two-week period for completion or before scheduling the first interview or group of interviews. Two to three weeks, depending on the norm for the organization, should be sufficient for functional owners to return any necessary information. It is more important that complete and accurate data is obtained, and continuity strategies well considered (if asking for this type of information at this phase) than it is to require the return of information quickly, but use caution because longer response times will add delays to the analysis. The duration of most interviews is usually an hour in length, but one should allow at least an hour and a half for Facilities and potentially two hours for Information Technology. A memo or email should describe the intent and expectations of the interview, and if an outside consultant is used for the analysis, an introduction and brief biography with the consultant’s affiliation should be included. Consider having a member of senior management sign the memo or send the email under their name to ensure that all requested functional leaders participate in the analysis. Some leaders may believe their presence will not add value to the program. Open the interview with a discussion of the Business Continuity Management program and an explanation of the BIA. At the end of the interview, inform the participants of the next steps and the timelines agreed upon. This is in general good meeting etiquette but worth repeating. It may be appropriate at the beginning of the interview to mention any scope limitations. Managers often preface the meeting by asking the participants to think about a worst-case scenario when answering the impact questions and when developing their continuity strategies. Although this is arguably the correct thing to do, bear in mind that a worst-case scenario can cause some participants to feel overwhelmed or to take the attitude that nothing can be done after the asteroid strikes the earth, so why plan a response? A better approach might be to propose a very serious but credible regional disaster scenario (but remember that we are concerned with the loss of functionality, not the cause of the loss, although we will change this focus when we discuss mitigation). Nevertheless, the analyst should frame questions that are applicable to different types of disasters. For example, in an area subject to earthquake risk, many are aware of the consequences that are associated with such a hazard. However, speaking about earthquakes may not give the proper perspective when asking questions about reputational damage due to securities fraud. As appropriate, ask questions based on the consequences or conditions expected from different threat scenarios. During the interview, encourage the function owners to describe how their function and processes work and how they relate to the goals of the organization and to other units within the business. This is the opportunity to “understand the organization.” Ask open-ended questions before moving onto the specific questions, allowing the functional owners to talk without interruption, noting any follow-up questions you may have. When asking follow-up questions (actually, keep this in mind when forming all questions), be careful to frame them in a manner that does not cause the manager to believe they need to justify their positions or the value of their functional units within the organization. For example, don’t ask the manager how valuable their function is to the organization. Ask, instead, questions that elicit a value-oriented response, that is: • What would be the impact to the organization if your business unit could not function? • How would this impact change over time? • How would the loss of your business unit affect other functions within the organization—what other business units are dependent on the input or output from your unit? Discuss the financial and operational impact questions early in the interview so that neither party feels rushed to provide answers that may be incomplete due to time constraints. Avoid conducting the interview in an office to eliminate any disruptions. A summary report of the discussion, data obtained, strategies explored (including any that were discussed and rejected), and recommendations to close gaps identified in the interview and review should be sent to the interviewee for factual accuracy and acceptance of any proposed recommendations. Once accepted, the recommendations should be entered into a corrective action tracking system (this may require additional review and acceptance at a higher level). Selected content from these reports can later be collated into the final BIA report. 5.2.3. Data Analysis Once the questionnaires are completed and the interviews finished, the analysis of the data can begin. Define Maximum Acceptable Outage (MAO), RTO, and RPO for each business process or function. Rank functions by their shortest RTO, greatest risk, greatest loss, or in the order that management agrees is the most critical after an examination of the data. Once this is accomplished, the analyst then maps the software and data (IT) processes that support these functions to illustrate their criticality. Look at dependent functions to decide if their ranking should be elevated to match any associated functions that have been deemed critical. If a function is critical, generally all that supports that function becomes critical necessitating the adjustment of their RTOs or RPOs to a higher level. Identify gaps in prevention, preparedness, and response revealed from the questions and develop recommended corrective actions to close the gaps. Keep the following in mind when analyzing the data: • RTOs, MAO or Maximum Tolerable Outage (MTO), and criticality ranking are not simply a function of the raw data. It is an agreement with senior management. The loss of function or product “A” may pose the greatest risk to the organization’s goals or cause the greatest loss, but management may decide that in light of future disruptions, they may want to shift emphasis onto function or product “B.” Before the analysis and the selection of strategies are finalized, meet with management to ensure they are in agreement with the BIA’s conclusions • Establish MAO, RTO, and RPO within the normal business cycles and within any peak cycles (some managers simply determine and use the peak cycle, which is what ISO 22313 suggests). For example, the peak cycle for a retail toy manufacturer could be the months just prior to the holiday season. • Account for impact only once, that is, watch for duplication. This can be a problem, for example, if the impact of the loss of order entry is duplicated inside a separate loss estimate for Accounts Receivable, or Accounting in general • Do not deduct insurance or anticipated claims reimbursements from loss estimates. Claims can became a matter of litigation and in the end may not be realized in total, or the delay in reimbursement may cause cash flow difficulties that can be fatal to a small- or medium-sized organization. Figures adjusted for expected reimbursement cannot consider these uncertainties • Combine the financial loss data by exposure over time (see example #1). Some of the suggested BIA questions ask for the financial loss for each day of an outage. The data is then further combined into a cumulative loss by function over time (see example #2). This will allow the manager to say “if we were to go cold and dark for three days, we would lose X amount of money.” BIA software programs will help to establish the MAO, operational impacts, and future resource requirements. Without the software, financial impacts are combined (totaled) into the financial impact table used to collect the data (see Table 1 Financial Impact Spreadsheet in Appendix D). Note that the next table will now list the functions themselves and not the breakdown of the loss categories (although a compilation of these losses may be included in the BIA report). Meet with the steering committee, the sponsor, or with top management to agree on the MAO and RTO after the data is compiled and the report is in draft form. Include these agreements in the final report. In addition, matrix the operational impacts and RPO for the BIA report. Most of the questions asked in the interview pertain to preparedness, response, and strategy development gaps that are designed to prevent and limit the impact of the disaster, resulting in recommended corrective actions included in the BIA report. Consider at this juncture developing the cost estimates for the implementation of the corrective actions. If less expensive alternates are available, also consider a discussion of these options. 5.2.4. Documentation and Communication of Analysis The results of the analysis are combined into the BIA report that is often combined with the Risk Assessment report. The manner in which the BIA is documented is important to auditors and to management, so the objectives of the analysis must be clearly illustrated. Although the standards do not specify a particular format for the report (remember the document control requirements), it is important that the report describes the business (its products, processes, and services), processes that support products, and services that enable the goals of the organization (“understanding the organization”), the MAO/MTPD for each process, product, or service, and internal and external dependencies. It must provide an understanding of the negative impacts over time that the failure to provide these products, processes, and services would have on the organization. It describes the risk to the organization of not resuming its business activities. The BIA report is one of the most important documents within the Business Continuity Management System. The report can begin with an introduction that describes the purpose of the analysis and must describe the business impact analysis process, including the processes used to analyze the data to arrive at the assigned priorities. The scope of the analysis is discussed and should include a high-level list of products, processes, or services that were excluded from the scope of the analysis. The rationale for any exclusion should also form part of the discussion. If the list of exclusions and the rationales for their exclusion are extensive, consider including the detail in an appendix. A list of all personnel and/or third parties who were interviewed or participated in the analysis should be listed along with their titles or positions. If an outside consultant was used, their affiliation can also be listed. Significant documents reviewed can be summarized with the detail (if lengthy) included in an appendix. Because this can be a lengthy report, it is important that an executive summary is compact but complete and, as most executive summaries are, included early in the report. Describe the nature of the organization, but from a high level in the summary with the appropriate amount of detail in the body of the report. Also, discuss the overall impact to products and services and the overall impact of the organization’s inability to meet its goals after a disaster, listing the most vulnerable functions or these with the greatest gaps with a description of the risk and financial and operational impacts. Tables that illustrate the risks and rankings can supplement the discussion. The MAOs and RTOs, and potentially the RPOs, should be highlighted. A list of recommended corrective actions can also be included in the summary (be careful not to preface the recommendations in a findings or recommendation format, leave this to the body of the report). The body of the report should contain an expanded description of the functions that support products, processes, and services within the scope of the analysis and abbreviated items from the Executive Summary, focusing on a detailed treatment of the impacts of potential loss. First describe and illustrate the major impacts (and risks if a combined report) revealed in the analysis. For example, an excerpt from a BIA that discussed its impacts (and later illustrated in a combined table of impacts) describes the impact of the loss of their call center: The loss of the call center could result in the failure to realize about $1 million per day in direct sales. Many strategies have been discussed to continue their operations but call center managers disagree about their effectiveness. The existing strategy to use the presentation room on the first floor of the San Diego facility will take some time to prepare and can only accommodate less than one quarter of the total call center volume. Work-at-home strategies, although expensive to implement and maintain, have been successfully tested. Other strategies discussed involve transferring call volume to other present and future call center locations. The discussion should then focus on the following, in no particular order: • Combined financial loss of each function over time (but list the function in place of the loss category) • Operational loss by severity and function • Maximum Acceptable Outage (MAO) (or other measures) by function • Recovery Time Objectives (RTOs) • Recovery Point Objectives (RPOs) • IT systems associated with functional rankings • IT applications (software) associated with functional rankings • List dependent functions • List alternate locations by function • List of internal and external dependencies (upstream and downstream dependencies) • Initial strategies by function • Key resources necessary for continuity • Other significant measures from the analysis Although the organization can arrange the information in any manner it wishes, some simple examples include (some tables have been abbreviated by the number of weeks and number of functions represented) (Tables 5.1–5.8): Table 5.1 Example of Financial Loss over Time by Exposure Day 1 Exposure Min Day 2 Max Min Day 3 Max Min Day 4 Max Min Day 5 Max Min Week 2 Max Min Max Processing Royalty overrides 10,00 14,00 10,00 14,00 10,00 14,00 10,00 14,00 10,00 14,00 0 0 0 0 0 0 0 0 0 0 0 0 Total 10,00 14,00 10,00 14,00 10,00 14,00 10,00 14,00 10,00 14,00 0 0 0 0 0 0 0 0 0 0 0 0 Salaries Records administratio 2830 2830 2830 2830 2830 2830 2830 2830 2830 2830 28,300 28,300 n Refunds and 2269 2269 2269 2269 2269 2269 2269 2269 2269 2269 22,690 22,690 repurchase WW training 958 958 958 958 958 958 958 958 958 958 9580 9580 Royalty overrides 4457 4457 4457 4457 4457 4457 4457 4457 4457 4457 44,570 44,570 Statistical analysis 1400 1400 1400 1400 1400 1400 1400 1400 1400 1400 14,000 14,000 Sales awards 472 472 472 472 472 472 472 472 472 472 4720 4720 Dist. services 912 admin. 912 912 912 912 912 912 912 912 912 9120 9120 Total 13,29 13,29 13,29 13,29 13,29 13,29 13,29 13,29 13,29 13,29 132,98 132,98 8 8 8 8 8 8 8 8 8 8 0 0 Table 5.2 Example of Financial Loss over Time by Function Day 1 Day 2 Day 3 Day 4 Day 5 Week 2 Function Min Max Min Max Min Max Min Max Min Max Min Max Sales/call center 1.2 1.5 2.4 3.0 3.6 4.5 4.8 6.0 5.0 7.5 10.0 14.0 Day 1 Day 2 Day 3 Day 4 Day 5 Week 2 Function Min Max Min Max Min Max Min Max Min Max Min Max Sales/direct 0.7 1.0 1.4 2.0 2.1 3.0 2.8 4.0 4.5 5.0 9.0 10 Royalty overrides 0.1 0.1 0.2 0.2 0.3 0.3 0.4 0.4 0.5 0.5 1.0 1.0 Total ($Million) 2.0 2.6 4.0 5.2 6.0 7.8 8.0 10.4 10.0 13.0 20.0 25.0 Table 5.3 Example of the Severity of Operational Impacts Dist.Royalt Impact y Overri des Distrib utor Service s Huma n Resour ces Sales Medi Reco Scient Refunds Awar cal Reception/Op rds ific &Repurc ds Affair erators Admi Affair hase (WW s n. s ) Statist ical Analys is Traini ng Aver (WW age ) Custom er 5 service 4 5 1 4 5 5 5 4 4 5 4.2 Legal obligati 5 ons 1 4 5 1 5 3 1 1 1 3 2.7 Regulat 5 ory 1 5 1 1 5 3 1 4 1 3 2.7 Industry 3 image 1 5 1 1 5 4 3 4 1 3 2.8 Public image 2 1 4 1 3 5 4 1 0 1 3 2.3 Increase in 3 liability 1 4 1 1 5 3 1 4 1 1 2.3 Financia l 5 reportin g 1 1 1 1 4 3 1 1 1 1 1.8 Dist.Royalt Impact y Overri des Distrib utor Service s Huma n Resour ces Sales Medi Reco Scient Refunds Awar cal Reception/Op rds ific &Repurc ds Affair erators Admi Affair hase (WW s n. s ) Statist ical Analys is Traini ng Aver (WW age ) Cash flow 5 1 1 1 1 1 1 1 1 1 1 1.4 Shareho lder 3 confide nce 1 2 1 1 4 1 1 3 1 3 1.9 Vendor relation 3 s 2 1 1 1 2 1 2 4 1 1 1.7 Financia 4 l control 1 2 1 1 2 1 1 1 1 1 1.5 Table 5.4 Example of Operational Loss by Function Impact 1 (Low Impact) 2 Cash flow Human resources Reception/operators Medical affairs Scientific affairs Records administration Refunds and repurchase Sales awards Statistical analysis Dist. services admin. Training Competitive advantage Reception/operators Medical affairs Training Refunds and repurchase Statistical analysis 3 4 5 (Severe Impact) Order administration Royalty overrides Human resources Royalty overrides Sales awards Scientific affairs Records administration Impact 1 (Low Impact) 2 3 4 5 (Severe Impact) Statistical analysis Dist. services admin. Human resources Royalty overrides Records Administration Refunds and repurchase Sales awards Training Dist. services admin. Customer service Reception/operators Medical affairs Financial control Reception/operators Medical affairs Refunds and repurchase Sales awards Statistical analysis Dist. services admin. Training Human resources Records Administration Royalty overrides Table 5.5 Example of Risks and Single Points of Failure by Function Function Risk Mitigation Distributor services–call center Loss of the call center could result in Build out extra capacity in Dallas, develop the failure to realize about $1 million failover procedures. per day. Global supply chain Losses could increase backorder shipping costs by $11 to $20. Licensing Records duplicated and stored in fire Recall of product and suspension of resistant containers, equip selected team sales, possible imprisonment of members to connect to data systems from country manager, fines and penalties. remote location. Organizational development Delay in program milestones. Equip members to work remotely, migrate to Agile. Equip members to work remotely, establish offsite training locations out of disaster affected area. Function Risk Mitigation Potential FTC fines of $10,000 per file Inability to produce records for civil Royalty overrides and criminal proceedings Inability to service 2500 new distributors Redundant data center, records protection. Records are scanned and archived off site. Store work in progress in fire-resistant containers. Table Continued Function Risk Mitigation Scientific affairs Loss of clinical trial could delay product introduction by one year or more and possibly the loss of the monetary investment in the study. Adverse event files are not duplicated and stored off site Ensure trial sites maintain tested business recovery plans certified under ISO 22301 or ASIS SPC. 1-2009. Scan critical adverse event files into an electronic form and archive off site. Store work in progress in secure, fire resistant cabinets. Table 5.6 Example of Initial Recovery/Continuity Strategies by Function Function Alternate Location Business development Any, home Recovery Headcount Continuity/Recovery Strategy 6 Work from home Distributor services Los Angeles, Dallas 25 Continue Century City Backup until Dallas center is built out Distributor/royalty accounting Los Angeles distribution center Overstock supplies and store in secure location off site Human resources Los Angeles, Dallas, 6 home Work at alternate location until replacement facility established Internal audit Near audit locations 7 Wait for recovery Legal Home, contract law 8 offices Connect remotely 5 Recovery Headcount Function Alternate Location Organizational development Home, any alternate 2 location Schedule sessions off site at alternate location New technologies Contract labs 8 Salvage equipment, use contract or partner labs Payroll Payroll contractor, Los Angeles 2 Pay 80 hours and adjust later Royalty overrides Any alternate location 27 Remote connect to systems Records Any alternate location 5 Remote connect to systems Refunds and repurchase Canada, any alternate location 5 Canada to pick up load Supply chain planning Home, any alternate 8 location Alternate, but more expensive shipping modes, carriers and ports Transportation Shipper, any alternate location Redundant and alternate modes, overstocking Treasury Home, any alternate 2 location TOTAL 12 Continuity/Recovery Strategy Maintain ability to communicate with financial institutions. 137 The results of the questionnaire and interview questions are summarized in the report by department, process, or function. The summary, where applicable, should include products, preparedness, vulnerabilities and impacts, alternate work-space strategies, and initial continuity/recovery strategies, along with any special resources or needs required to implement the strategies (this does not mean the number of pencils Human Resources would need if they were to work from home, but this might be listed in the Human Resources Team Plan under Resource Requirements. It refers to higher-level necessities, such as high-speed data connections at home (which most people these days already have) to enable Virtual Private Network (VPN) connections, any special software necessary on the home computer and any associated licensing requirements. For each gap in prevention, preparedness, response and mitigation, obligation, and the like identified in each functional description, a resulting corrective action or recommendation should be listed. Suggested vendors or product cut sheets, if the recommendation involves the purchase of a product or service, should be included in an appendix (see Figure 5.1). Figure 5.1 Example of Business Impact Analysis Results of Interview Questions. Table 5.7 Example of Maximum Acceptable Outage (MAO) and Business Cycle Criticality by Function Function Maximum Acceptable Outage Critical Business Cycle Legal Immediate Quarter and year end Risk management Immediate None Corporate communications 1h None Facilities 1h None Investor relations 4h End of month, SEC Filings Licensing 1 day None Finance 2 days 7–14th each month Human resources 4 weeks None Employee benefits 2 days None Distributor services–call center 2 days All Order processing 2 days End of month Distribution 2 days End of month Treasury 2 days None Royalty overrides 3 days Middle of month Records 1 week All Royalties 3 days Middle of month Refunds and repurchase 3 days Middle of month All other royalty override functions 1 month None Internal Audit None Table 5.8 3 months Example of Recovery Time Objectives for Business Applications Application or Process Used By: Recovery Time Objective Share point Investor relations 2h Licensing 4h New technologies 3–4 months Company track Supply chain management 2 days CAPS Distribution 1 day Supply chain planning 1 week Distribution 1 day e-Time Finance 1 day HRIS Human resources 1 day Distribution 1 day Transportation 3 days Paybase Finance 1 day Phoenix Finance 1 day Remote desktop Royalty overrides 1 day PAIRS Supply chain planning 1 week Genesys New technologies 3 months Clear orbit Oracle 5.3. Reanalysis The introduction of a new project, function, or process should include an analysis of the impact of its loss. This helps to foster a culture of business continuity and keeps the BIA fresh. Likewise, any major change in the organizational structure, risk appetite, or strategic direction of the company would necessitate an update of the analysis. Otherwise, the expectation is an annual review of the BIA, and reanalysis every 3–5 years. 5.4. Confidentiality Because of the sensitivity of the information revealed in the BIA, it should be treated as a confidential document. It is appropriate to distribute the full report to top management and to distribute the individual departmental (functional) results and recommendations to the functional leaders for review. Tables of RTO, RPO, and MAO may be included in the Business Continuity Plan, which should also be a controlled document. 5.5. Review BIA identifies the financial and operational loss of the organization’s business functions over periods significant to the individual organization, regardless of what caused the loss, by examining their impact on service objectives, financial position and cash flow, regulatory and contractual issues, and competitive risk. It is necessary to develop the Business Continuity Management System and is essential to understanding the context of the organization. To meet the requirements of the standards, the BIA must identify the functions that support the delivery of products, processes, and services and document the BIA process. The information developed as a result of the analysis allows management to make decisions concerning their MAO or the MTPD, which is the time it would take the loss or degradation of a business function or process to have an adverse impact on the organization’s objectives, such as the delivery of a service or product. Another similar term, the MTD is used as the maximum downtime the organization can tolerate for a business process or the length of time a process can be unavailable before the organization experiences significant (unacceptable) losses. This then allows management to set RTO and RPO, respectively for each critical or prioritized business function. The information consists of financial loss impacts in addition to operational or subjective loss impacts in which it is difficult to characterize the loss or degradation of a function in financial terms. Based on this information, business functions are designated as critical or noncritical to the goals of the organization. The functions are prioritized based on the level of criticality, and continuity or recovery strategies are cost justified based on the results of the analysis. It also identifies the upstream and downstream dependencies of each function within the scope of the analysis and highlights internal and external resources to ensure its resiliency. The data for the analysis is collected through a combination of workshops, questionnaires, and interviews with functional managers from all components of the organization that are within the scope of the analysis. The scope of the analysis should parallel the scope of the Business Continuity Management System, but the scope may be improperly limited unless the entire organization (within reasonable constraints) is analyzed. Information that will be useful later in the planning process, such as an evaluation of the minimum number of personnel required at alternate worksites, is often included as part of the analysis. The manner in which the BIA is documented is important to auditors and management, so the objectives of the analysis must therefore be clearly illustrated. It should identify the MAO/MTPD and RTO for each process, product, or service, and internal and external dependencies. It must provide an understanding of the negative impacts over time that the failure to provide these products, processes, and services would have on the organization. It describes the risk to the organization of not resuming its business activities. The BIA document should also identify gaps in the prevention, preparedness, response, mitigation, and recovery of each business function’s resilience and include recommended corrective actions to close gaps suggested by the answers revealed on the questionnaires or during the interviews. BIA documentation should be regarded as confidential, controlled information. Business impact should be understood with the introduction of any new process, product, or service and reevaluated when a significant change occurs in the organization’s structure or strategic direction. Chapter 8 Business Continuity Plans and Procedures Chapter Summary The emphasis of business continuity managers in the past was to produce “the plan.” Achieving the goal of developing a broader business continuity management program in too many instances became secondary if the need for a program was recognized at all. The standards correctly place the focus on developing a business continuity management system, but the business continuity plan still holds its place as the most critical document in the effort to continue the critical operations of the organization and to recover from the effects of a damaging incident. Based in part on the all-hazard, Multihazard Functional Planning structure recommended by the U.S. Federal Emergency Management Agency, a “basic plan” describes the pertinent parts of the business continuity management system that the responsible individuals must know to achieve the objectives of resiliency. The basic plan is supplemented by specific team plans in which the instructions and resources needed to implement the organization’s continuity and recovery strategy are listed. A management team or a crisis management team oversees the entire incident response effort. They are typically located in the emergency operations center. Important information about how and when to activate the plan (“invocation of the plan”), the order of succession if a key member of the organization is unable to perform their duties under the plan, and a description of the execution of its high-level data and relocation strategies are found in the basic plan. It describes how this information is communicated internally and externally, how damage is assessed, and how financial or purchasing policy may change during an incident.The business continuity plan should be brief and to the point, but it should encompass enough information to implement the strategic objectives and resource requirements of the organization and of the individual continuity or recovery teams at a time when stress and physical and mental exhaustion are elevated. Plans are maintained in a manner in which they can be accessed offsite, are flexible, and their security and the confidentiality of their contents respected. Key terms All-hazard planning; Alternative workspace; Business continuity communications; Crisis management team; Damage assessment; Emergency operations center; Invocation; Multihazard functional planning; Order of succession Key Points • Importance of business continuity plans • Fundamental attributes of continuity plans • Plan organization and structure • How the continuity response is activated • Order of succession • Communication within the business continuity structure • The emergency operations center is a focal point for situational information and strategic decisions 8.1. Introduction The emphasis in the past was focused toward building a business continuity plan, or at the very least, filling out the blanks in a template plan. Today it is to build a business continuity management system that enables resilience for the entire organization. However, the business continuity plan is still a vital and necessary piece of the process. The plans list the detailed instructions (procedures) to the continuity team members that implement their strategies and define their roles and responsibilities. Communication and other resource information, internal and external interdependencies, activation criteria (now referred to as invocation criteria), and relocation information are included to assist the team to accomplish their tasks. A flexible response and control structure and the purpose, scope, and objectives of the business continuity management system are described in the plan. It documents many of the processes required by the standards. Continuity plans must be “lean and mean” but complete, executable documents. However, the standards make this difficult because each plan must contain certain information that is not necessarily geared toward direct incident response. Remember that the standards also do not draw solid distinctions between planning for emergency response and business continuity. Business continuity plans typically consist of two separate documents, the top document or “base or basic plan,” which outlines the overall incident organizations, its policies, scope, assumptions, and lines of authority, and the team plans, which are similar to the government’s Functional Annexes that list the specific instructions and resources to each individual continuity team. The basic plan contains information pertinent to all teams and interested parties, and the team plans focus on the business function. Rather than repeating the information required by the standards, the manager may consider a single plan with the team plan as simply additional chapters. Although the standards allow for a single or multiple plans, this approach may or may not be agreeable to an auditor. However, the requirement to repeat basic information can be wise if plans consist of subplans based on a corporate, divisional, or regional basis. The type of plan described above is known as Multihazard Functional Planning according to the U.S. Federal Emergency Management Agency (FEMA) and fits well the recovery team methodology suggested in this text. It uses “all-hazard emergency operational planning” and is based on the premise that although the causes of incidents and disaster can vary, almost three-fourths of them produce common response requirements. Task-based plans are developed around these requirements rather than using contingency planning, which calls for the listing of response procedures for each individual hazard or risk. 8.2. Fundamental Attributes of the Plan Absent regulatory requirements, the plans can exist in several formats, but they should be consistent within the organization and follow its, and the standards’, document control procedures (The plan must conform to the requirements for document control as described in Chapter 3). Plans exist on the cloud, on webpages, in portable electronic devices, in laptop computer systems, on thumb drives, and DVD and other electronic forms, but in case all else fails, it should also exist on paper. Paper plans do not rely on batteries. No matter what format is used, plans should meet the following conditions: • The plan must be organized in a logical sequence. • It must be simple and easy to follow. The stress of the situation can add to the difficulty in finding important information if executable procedures are mixed with background, descriptive, or training information. Information that is difficult to find is useless. • It must be complete but not overly detailed. The plan, both basic plan and team plans, should contain enough information to allow someone who did not participate in the planning process to understand and perform the instructions necessary to implement the strategies but referring detailed procedures to embedded or linked documents. Except for what is required by the standards, the plan should not contain information about how the plan was developed, hazard identification, or strategy development. If necessary, try to include this information in separate documents. Necessary documents can be treated as, and listed in, the vital records resource section of team plans. • It must assign roles, responsibilities, and lines of authority. This is another requirement by the standards that are included in all plans. This can be accomplished at a high level in the basic plan by describing a continuity organization and more specifically in the individual team plans by identifying team leaders, team lead alternates, and the responsibilities (team task instructions) of team members. • The plan should include a glossary of any terms used. Avoid or minimize the use of acronyms. Use plain, clear language. • It must be flexible enough to respond to unforeseen issues and allow for midcourse correction and adaptation. Although most organizations exist in controlled, predictable environments where they can foresee the types of incidents they need to respond and recover from, the ability to react to unforeseen events must be written into the plan. • It must state assumptions upon which the plan is based or constrained. Any additional assumptions contained in the team plans should be explained. • Outline or proceduralize what and how pertinent information is communicated to internal and external stakeholders, among teams, and to the management team/crisis management team and emergency operations center (EOC). This requirement must exist in all plans. • Specific resources and the tasks required to perform recovery or continuity operations are included in the plan. These are typically included in the individual team plans. • Each plan must contain implementation procedures. These are mostly found in the individual team plans, but activation procedures can also reside in the basic plan. • Consider including information that is subject to frequent changes as an attachment to the plan, and not part of the body of the plan. This will facilitate the ease of updates. The use of single-sided pages will also make updates easier. 8.3. Plan Organization and Structure If not using the Incident Command System (ICS), the business version of the basic plan and individual continuity team plans form a viable set of plans that, as part of the greater business continuity management system, will help ensure success of the continuity effort. The basic plan contains administrative and descriptive details to properly manage the continuity activities in a focused, constructive manner. It contains information that is of interest to all continuity team members. The plan, depending on the needs of the organization, should contain the following sections: • Table of contents • Statement of policy • Purpose • Scope • Objectives • Assumptions • Damage assessment • Invocation (activation) criteria, procedures, and authority • Order of succession and delegation of authority • Continuity organizational structure • Communication of information • Emergency telephone numbers • EOC • Alternative locations and space allocations • Recovery priorities or recovery time objectives (RTOs) • Internal and external dependencies • Documentation of expense and activities • Additional information • Plan distribution • Orientation and training • Exercising and testing • Plan maintenance • Confidentiality • Appendix 8.3.1. Table of Contents After the title page that conforms to the requirements listed in the standards, the plan should contain a table of contents. If the plan is in an electronic format, then it is useful to link each subject heading to its location within the document. 8.3.2. Statement of Policy The plan should outline, but not necessarily duplicate, the business continuity policy. The pertinent elements of the policy should be emphasized. The plan should tie the achievement of business continuity goals and objectives to performance evaluations and bonuses. Statements from the policy that illustrate management’s support for the program should be emphasized. 8.3.3. Purpose The purpose of the business continuity management system and that of the plan must be completely defined. This is one of the required elements of the standards and applies to each documented procedure (i.e., plan—the plan can consist of a single document or collection of multiple documents). 8.3.4. Scope The dimension of the business continuity management system encompassed by the plan is briefly but completely discussed. If the plan pertains to a single building or site, then refer to it by building numbers, site name, and exact street address. Inform the reader of any pertinent functions, locations, or contingencies not included in the plan. If the scope of the plan is a subset of a higher or broader plan, or part of a phased approach, then explain this in the appropriate detail. Explain very briefly what is excluded; why it was excluded; and, if necessary, reference a more complete document. If the business continuity system is designed according to the ASIS International standard, then include a Statement of Applicability (see Chapter 3). 8.3.5. Objectives The objectives of the business continuity management system and those of the plan should also be described. What will the plan accomplish, by whom, and within what timeline? Objectives must be SMART (Specific, Measurable, Attainable, Relevant or Realistic, Timely) and consistent with the scope and policy statement. Objects are another required plan element. Objectives can include the following: • The organization will meet all legal, contractual, and regulatory requirements throughout the duration of the incident. • Continuity teams will implement all strategies in a manner that meets their RTOs. • The human resources team will account for the location and welfare of all employees within 24 h of an incident with the potential for mass causalities. 8.3.6. Assumptions List assumptions upon which the plan is based or constrained. It is nearly impossible to plan for the absolute worst-case scenario in which everything ceases to exist. Assumptions must be realistic and can describe things out of the organization’s control. Assumptions can also include something pertinent that cannot be mitigated. Common assumptions include the following: • Facilities will be either partially or totally damaged or inaccessible for a period of 30–60 days. • Key personnel identified in the plan are available after a disaster. However, incidents that have a national impact such as the September 11 attack when air traffic was grounded may necessitate a different assumption. Pandemic situations may use the assumption that key personnel may not be available. • Alternative facilities identified in the plan are available for use after a disaster. • Backup data and valuable papers located in offsite storage will be readily available. • Critical resources will be available. • Employees are trained in facility evacuation and relocation procedures. 8.3.7. Damage Assessment The strategies for damage assessment to facilities, building contents, and equipment and the methods to document and report the damage (generally to the EOC) are described in the plan. Damage assessment can include an estimation of any reduction in production capacity and estimates of the time needed to recover. Damage to facilities and infrastructure can be the responsibility of the facilities team, contract structural engineers, or a trained damage assessment team. The assessment will include an estimate of the time required to repair and re-occupy the facility. Some strategies call for a rapid assessment to be forwarded to the EOC, followed by a more detailed examination. This will help to decide if relocation to alternative facilities is necessary. Individual continuity teams are often tasked with conducting their own assessment of the damage to their equipment, resources, or ability to deliver services. This is also documented and forwarded to the EOC. 8.3.8. Invocation (Activation) Criteria, Procedures, and Authority Another required element that must be defined in the plan(s) is the criteria to use to determine when the plan (i.e., the response or continuity effort) is to begin. A major earthquake when lights and computer systems go dark, pieces of the building start to fall to the ground, and the potted plant above your desk is now resting on top of your head should signal the need to invoke your plan. However, what if the earthquake is of a much lesser magnitude? Some disasters or major incidents can develop gradually. List the triggers and invocation criteria, procedures, and activation authorities in the plan. This will include the people or circumstances that have the authority to invoke the entire plan, individual team plans, or multiple team plans. Typically, any member of the management or crisis management team, or the business continuity system manager, can invoke the entire plan or any portion of the plan, whereas team leaders can independently invoke only their individual teams with notification to the business continuity system manager, management team, or EOC. The plan may be activated in whole or in part when the operation of a department, critical function, machine, or system component fails to operate, is damaged, is unable to meet its operational objectives, or access to it or to the facilities is restricted. Many plans allow for a graduated invocation (Level I, II, III), and some, in an effort to get to the head of the line when competing for space at a hot site, will let the type of disaster dictate how the plan is invoked. For example, after a localized disaster such as a fire in the data center, the team will first assess damage before declaring a disaster. However, if the disaster is regional, such as an earthquake, and the data center is damaged, the person with the invocation authority will immediately declare a disaster to the hot site, pay the declaration fee, and then assess the damage. Only then they will decide whether there is a need to relocate to the hot site. Organizations must develop invocation sequences that make sense for their situation. Disaster levels can be defined as follows: Level I disaster: A Level I disaster is one that results in facility inaccessibility or loss of power or other critical services for an expected period of up to 48 h (this time factor should change according to the RTO and maximum allowable outage). Damage from a Level I disaster is not large scale. It may consist of minor damage to one or more buildings, lack of access due to weather or city infrastructure conditions, or hardware and software problems not addressed by normal short-term support. Level II disaster: A Level II disaster exists when the outage is expected to last between 2 and 5 business days. Damage from a Level II disaster is more serious than that from a Level I disaster, and it may result in more serious loss to equipment and documentation (files, reports, contracts) due to a serious or prolonged event, such as a fire or local flooding. Level III disaster: A Level III disaster is one in which the effects of the incident are expected to last in excess of 5 days; cause severe damage to reputation; or have serious legal, contractual, or regulatory implication(s). A Level III disaster is severe and could include the total destruction of one or more buildings, requiring significant facility restoration or replacement. Information technology (IT) team plans may use a different activation sequence, each of which may involve a specific response by a different group of people. If an IT disruption is expected to last less than 2 h, then a “Stage 1” situation is declared, the team leader or shift supervisor is notified, and instructions are implemented by the on-duty technical support or repair personnel. If the outage is not resolved within this time frame, or if it is apparent that more time is required, then the response will escalate to Stage 2 or 3. This will invoke an additional set of instructions, notifications, or full recovery team activation. A process to determine when and how teams are to deactivate (i.e., stand down their continuity and recovery operations) should also be include in the plan. 8.3.9. Order of Succession and Delegation of Authority National Fire Protection Agency (NFPA) 1600: 2013, as does governmental planning, requires the documentation of lines of succession for top management of the organization. The term “succession planning” is included in the NFPA’s definition of continuity, but the manager should understand that the use of this term carries a meaning broader than simply listing who is next in command when the primary person cannot fulfill their duties and responsibilities under the plan as a matter of choice, death or injury, or inability to respond. Succession planning is a human resources function (typically) that identifies workers within the organization who have the potential to advance into senior management positions. It implements a long-term program of training and mentoring its future leaders. In the event that a member of top management is unable to perform their duties under the plan, then an order of succession with the associated delegation of authority to act in the successive position is followed according to the plan. This is often included as a portion of the organization’s Articles of Incorporation or in other legal documents. An example of an order of succession includes the following: This order of succession and delegation of authority is authorized by the president and is valid until the succeeded manager becomes available, is changed by the president, or is permanently replaced by the organization. The successor will have the full authority to act in place of the original (Table 8.1). There is no requirement in the standards to go three deep or more on the “Replaced by” or “Alternate Replaced by”; it is completely up to the organization as to how many replacements it wants to list. 8.3.10. Continuity Organizational Structure The plan should succinctly describe the structure of the business continuity incident response. Is the achievement of continuity operations accomplished according to the ICS or according to a continuity team methodology? Identify the elements of the organizational structure, its purpose and goals, authority, and communication. Table 8.1 Order of Succession Position Replaced by Alternate Replaced by Alternate Replaced by President Executive Vice President Vice President Operations Vice President Finance/CFO Executive Vice President Vice President Operations Vice President Finance/CFO Director of Manufacturing Vice President Operations Vice President Finance/CFO Director of Manufacturing Director of Human Resources Vice President Finance/CFO Finance/Treasury Director Accounting Manager Purchasing Director Most plans and continuity structures are based on a continuity team concept. This means that all required continuity or recovery actions are the responsibility of designated teams with specific instructions and resource requirements contained in their section of the continuity plan. Each team will be responsible for performing a series of tasks and procedures to continue or to facilitate the resumption of their unit’s business or systems processes. One member of each the team is designated as the team leader. The team leader, who may or may not be assigned unique tasks within the team plan, will act as the liaison (communication) between the management team or EOC and other team leaders and is responsible for the continuation of the team’s critical functions (i.e., the tasks designed to implement the team’s business continuity strategies). The team leader has the authority to modify their team task instructions to adapt the strategies to any unique demands of the disaster or to adapt them to any strategic decisions issued by the management team/EOC. Each team leader should have an alternate team leader. See Recovery Teams for more information. A flow chart or organizational chart can help to clarify the relationships among the management team, team leaders, and those responsible for the implementation of assigned tasks. See Figure 8.1 for an example of the continuity organizational structure. The example above represents an organization with multiple worldwide locations, the business continuity structure of which consisted of several continuity teams for which the team leaders reported to the local crisis management team. Part of their management strategy provided for support of senior managers from the corporate offices—a management strike team if you will. The business continuity manager acted as the EOC leader with the management team located in the EOC. The Corporate Strike Team had the ability to stay in the EOC or to provide support in the field as needed. Communication to and from the EOC was accomplished through the team leaders. Communication from one team to another was also accomplished through the team leaders. 8.3.11. Communication of Information The communication requirements of the standards call for the receipt of information to identify impending incidents, to warn the community of hazards created by the organization, and to identify how the organization will communicate to other stakeholders. A description of how the organization will communicate internally with members of the organization as well as externally with interested parties (e.g., emergency responders, the community, and the media) is written into the plan. The procedures to detect, monitor, document, and respond to an incident, including national or regional advisories, must also be written into the plan. Some of this information can reside in individual team plans, such as the requirement for procedures to operate a communications facility that could be included in the EOC plan. However, despite the goal to minimize information in the plan that is not executable, methods to ensure the technology of warning and communication systems are survivable during an incident are explained. Redundancy of communications, interoperability of communication among responding agencies (i.e., all can all talk on the same radio channel using common terminology), are best left to the purchasing department, but they can be placed in this section of the document, especially if specific radio channels must be selected. Figure 8.1 Example of continuity organizational structure. How and what will be communicated to the employee population is listed. This does not preclude individual teams from developing supplemental communication means. If applicable, indicate that in all cases, the telephone is intended to serve as the primary means of notification and communication. Cellular phones can act as an alternative. The organization’s emergency notification and communications systems will be used to notify and provide instructions to staff, visitors, and guests. In addition, each team will maintain emergency contact numbers for each of its team members. Other modes of communication the organization may use in an emergency include • Commercial emergency notification systems: These firms will send prerecorded messages over the phone system or send text messages to all phone numbers in their database after activation by a single call. • Call trees. • Two-way radios: List channels numbers to use in an incident. • Satellite phones (usually found in the EOC). • Public address system. • Warning siren. • Amateur (Ham) radios (specify a frequency and other necessary parameters). • Telecommunications network. • Websites: Similar to the toll-free number described below, a webpage should be available via an outsourced, offsite hosted webserver, www.status.organization.com, located in a third-party data center outside of an area that could be affected by the same incident. The site provides status information in the event of a disaster as updated by the business continuity manager, public relations, EOC, or a support team. List the URL in the plan. • Organization-wide e-mail messages. • Bullhorns. • Voicemail boxes hosted outside of the area to leave messages or instructions. • Toll-free numbers: The toll-free numbers should connect to messages and instructions that will inform workers, customers, and other parties about the status of the organization. The number can be printed on employee security badges, webpages, and training materials. The instructions on how and when to update the message should be contained in the public relations or EOC plan. List the number in the plan. • AM/FM/TV stations: Local news stations can be contacted to broadcast messages to workers during a disaster. List the frequencies in the plan and instructions in the team plan that tell team members how to contact the stations. Many jurisdictions maintain emergency radio stations that can be listed in the plan. Train employees to monitor these stations for information. This section of the plan can also be used to inform responsible individuals how to communicate with other team members, team leaders, and internal emergency responders, but remember to minimize any verbiage in the plan that is purely training in nature.To the greatest extent possible, communications should be documented. 8.3.11.1. Emergency telephone numbers As a separate section, or a subsection of communication of information, include a list of emergency notification telephone numbers that would be common to multiple teams. Include primary and alternative numbers. In the case in which 911 (112 in Europe, 999 in the United Kingdom, 000 in Australia, etc.) is used to notify the police, fire, and ambulance, include the direct dispatch number as the alternative. Some emergency numbers to consider for the plan include • Police, fire, and ambulance • Office of emergency or disaster services • Local hospital • Local medical clinic • Electric, gas, and water utilities • Taxi and transportation • National or local weather service • American Red Cross or other relief agency • Poison control center • Applicable regulatory agencies • Fire and security alarm company • Local and long-distance phone carriers • Traffic information and road closures • Coast Guard or other appropriate rescue agency • Department of Homeland Security 8.3.12. Emergency Operations Center A brief description of the EOC and its primary and alternative location is included in the basic plan. Directions to the EOCs are detailed. The management or crisis management team members are instructed to report to this location when the plan is invoked or a situation warrants activation of the EOC. Some plans call for a third alternative location outside of the area. Primary telephone numbers of all EOC locations are listed. 8.3.13. Alternative Locations and Space Allocations Describe the strategies for relocation to alternative data processing sites and for alternative workspace. Include complete details that instruct team members where to go, how to get there, and what to do when they arrive. The name of the relocation facility, address, and special instructions are written into the plan. Maps and directions should be included in the appendix along with air transportation schedules and any special reservation instructions. Also included in an appendix are any instructions on how to connect to data systems once the teams arrive at the alternative work area. A relocation assistance team can be formed ahead of time to help with travel arrangements, other transportation needs, lodging, check-in, and orientation at the alternative location. If the organization has an in-house or onsite travel department, then they are good candidates for this task. Of course, this does not apply to work-at-home strategies (one would hope). Relocation strategies can be based on different scenarios. The corporate offices of a company based in the San Francisco Bay Area are located about 20 mi north of its worldwide data center. Their strategies directed critical functions to relocate to the data center if the corporate offices were rendered unusable. If the corporate offices and the data center were damaged by the same event (a credible scenario), then IT was to relocate to a hot site and the business systems (continuity teams) were to relocate to a hotel in Reno, Nevada. Although the organization may have an overall relocation strategy, certain teams may choose to relocate to different locations. All alternative locations should be listed in this section of the plan along with the associated contact phone numbers. It is important to train all team members who may be required to relocate in the details and expectations of the plan. It is more important to conduct exercises that actually call for the physical relocation to their alternative location and practice logging onto the alternative data systems. In the above example, a relocation exercise was held and the team members were asked to make their way from the corporate offices to the data center. Detailed maps and directions were distributed to the data center that was adjacent to a major interstate highway with an off-ramp less than one-quarter mile away. Forty percent of those who participated in the exercise could not initially locate the data center. Space allocations can also be listed for each alternative location. Allocation refers to the number of team members that will relocate. Not all employees may be needed during the initial phases of a continuity or recovery operations. The allocation will indicate how many employees or team members are needed so resources and space can be anticipated. Some planners include the total head count and the short- and long-term space requirements (square footage) in this section, but this may be best left in the facilities, real estate, or other team plans. The plan should describe from a high level how it will return to its original location after repairs are completed or how it will transition from the alternative location into a new facility. The details of the return may reside in the facilities, IT, and/or other team plans. 8.3.14. Recovery Priorities or RTOs RTOs, recovery point objectives, and the maximum allowable outages should be discussed in the overview for each team plan, but it is useful to list this information by critical function in the basic plan for easy reference when resource reallocations need to be made at the time of the disaster. Some would argue that this information is better placed in the management team or EOC plan. In the order of importance (criticality) as determined by management agreement on the basis of the business impact analysis and risk assessment, also list any times of the year (quarter, month, or other business cycle) during which the loss of these functions is especially critical. 8.3.15. Internal and External Dependencies Probably best recorded in the team plans or in an appendix, some managers will list each function’s upstream and downstream dependencies in the basic plan. The advantage to listing in the basic plan is the provision of a better view of the interrelationship between functions, and it allows the business continuity manager to better manage the incident. Most functions require some sort of input into their processes such as raw materials or information to deliver their products or services. When completed, this product or work in progress then becomes the input for the next function until the finished product is completed. The accounts receivable function may depend on the output of the sales function in the form an invoice, and their output would be cash or a check for deposit. In other words, how does one function support or depend on another? Likewise, the facilities department in a research institution may support the survival of laboratory animals by ensuring that their life safety support systems remain functional during an incident. This is an example of a downstream dependency. 8.3.16. Documentation of Expense and Activities Instructions directing each participant in the business continuity process, or at the very least each continuity team leader, to document all actions and expenses during and after an incident should be emphasized in the plan. This practice is of such importance that the instructions bear repeating in all team plans. A log of the actions performed by team members can be used later for an after-action report to identify lessons learned, verify that important steps were completed, defend the organization in litigation, or to demonstrate that regulatory compliance was achieved. It demonstrates to management and to auditors that the plan was executed as intended. The log, along with photographs and receipts, provides additional documentation to insurance claims adjusters that the expenses were in fact incurred. The activities and expenses should be entered as they happen because the stress of the moment will likely result in forgotten entries or unreliable detail. A process should be developed and written into the plan that describes how and who is to receive the completed logs on a daily basis (potentially the risk and insurance management team) and how this information is to be collated and reported. It is not unreasonable to copy the business continuity manager or EOC support team because they can be used to help craft a daily status report on the progress of the continuity operations. A form for this purpose should be developed and appended to the plan. The form can ideally exist in an electronic format in which entries are easily transmitted and collated. See Figure 8.2 for a sample log form. Figure 8.2 Appendix continuity action and expense log. 8.3.17. Additional Information Other pertinent information that most, if not all, teams need to know that is specific to the recovery or continuity operation should be listed, potentially under separate headings. For examples, emergency financial or purchasing procedures (expedited purchasing or changes in approval levels) or changes in policy under emergency conditions should be agreed to beforehand and explained in the plan. 8.3.18. Plan Distribution Again, paying strict attention to the document control requirements of the standards and of the organization, list the plan recipients in this section. If a separate means to track document ownership and version control exists, then this section could become redundant and therefore would be eliminated. Large organizations will not list in the plan every person who is entitled to receive a copy. Senior members may be listed by name and the remainder by title or generic description such as “team leaders” and “team members.” The entire plan is not distributed to every continuity team member. Complete distribution is appropriate only for the business continuity manager and staff, offsite vital record storage, and the management team (EOC). There may be others who need the “phone book” version of the plan, but team members must receive only the information they will need in a continuity or recovery situation. This will help them to remain focused in their duties, locate important information in a stressful situation, and maintain security of the confidential information contained in the plan. This is accomplished by distributing only a copy of the basic plan and the individual team plan to the team members. Some business continuity managers argue that the team members should receive only their team plan, excluding the basic plan. As mentioned above, most plans today will exist in some type of electronic format. However, paper plans are still useful and necessary—when all else fails, the ultimate business continuity planning tool, the pencil and eraser, becomes the base element. Remember that the standards require the documents to be available when needed. Maintaining the plan in varied forms and locations will help to ensure this requirement is met. To facilitate version control and updates to the plan, print paper plans on single sheets, not double-sided sheets. This may also allow comments and notes to be written for later improvement opportunities. Team members will maintain paper and electronic copies of the plan with at least one copy secured offsite at all times. All team members with laptop systems should ensure that their team plans are regularly replicated to their system or other portable devices. 8.3.19. Orientation and Training Normally a description of the program that provides orientation and training to those who have responsibility under the business continuity management system is included in the plan, but when planning under the standards, the details of the training program will likely reside in a separate document. The plan can still define and reference the requirements to conduct orientation (initial training on the contents and expectations of the plan) when it is first introduced and to all new members of the organization. It can also include an overview of the ongoing training program with possibly a training schedule or training requirements included in an appendix. Orientations should emphasize the confidential nature of the plan’s contents. 8.3.20. Exercising and Testing Similar to orientation and training, the exercising and testing section should contain a high-level description of the testing program or exercising strategy, but the actual exercise plans should exist outside of the basic plan. Testing and exercising requirements are described in a subsequent chapter. The types of exercises, drills, and tests along with their expected frequency can be included in the plan. Specific requirements for all tests, such as the need for an after-action report and corrective actions, may also be listed. 8.3.21. Plan Maintenance As part of continuous improvement, the information contained in the plans must not only be updated on a regular basis, but the document control provisions of the standards also require that the use of obsolete information is prevented. Version control according to the organization’s document control system, and converting the plan to a form such as a pdf, will help avoid the unauthorized deletion of information or modification of i...
Purchase answer to see full attachment