Conducting a Business Impact Analysis Guide

From http://searchsecurity.techtarget.com/#

Ten steps to a successful business impact analysis George Wrenn, CISSP Conducting a business impact analysis is hard work and takes time. But once this data is collected, security practitioners can confidently request resources, and more importantly, prioritize security efforts across the enterprise. Simply stated, BIA is an analytic process that aims to reveal business and operational impacts stemming from any number of incidents or events. A BIA traditionally leads to a report detailing likely incidents and their related business impact in terms of time and dollars. For example, a BIA report for an online retailer may include a Web site outage of one day with the loss calculated as the yearly gross sales divided by number of days per year the site is open for business. In order to conduct a BIA you need to understand the business operations of your company in detail. You need to roll up your sleeves and reach out to operational folks to get the real picture. I remember one such exercise on a consulting engagement at a large bank where it was assumed that if the tellers lost their computer terminals that the dollar impact per hour was in the millions. The bank tellers later told me that when the terminals aren't available they can continue accepting deposits and other transactions, then manually batch the transactions at the end of the day. There was actually a five- to seven-hour window of no real loss of revenue. Here is a simple step-by-step approach that will put you on your way to conducting a successful BIA. 1. Document the gross revenue and net profit your organization generates per year. These data sets the upper bound for business losses related to business operations. It will not, however, set the limits for reputation, regulatory or legal losses that can rise above yearly revenue. 2. Define the critical business systems your organization operates. This data can be entered and tracked in a spreadsheet. In many cases the revenue data can be linked to critical systems. This is especially true in e-commerce-driven companies. 3. Classify each system as business critical, important or non-critical. Ask system operators what would happen if a particular system was not available for an hour, a day or a week. In most cases you can quickly classify systems based on operator responses. 4. Document which systems have cross dependencies. There may be non-critical systems that act as upstream or downstream components to critical systems. For

example, DNS service may not appear to be critical to an online store until it is discovered that the credit card gateway relies on DNS to send credit card requests and process transactions. This type of cross dependency may require a reclassification of systems when linked to critical applications. 5. Estimate the financial, revenue and non-revenue impacts associated with each system. For example, a payment gateway server for fax orders that does only 1% of the total revenue of the company can easily be estimated as .01 x gross revenue. If data does not exist or is not easy to estimate, the replacement cost (including labor) can be used for important and non-critical systems. For nonrevenue related systems, note impact. For example, if the payroll system is not working, employees may not get paid on time -- which may cause other issues. 6. Estimate the cost to identify, remediate, recover and resume operations for each system in the spreadsheet. Include labor, hardware and software costs. For incidents that result in negative reputation, legal and regulatory outcomes, include estimate of fines, legal costs or a marketing campaign to win back customer confidence. Add these costs to impacts defined in step five. 7. Identify the Maximum Acceptable Outage (MAO) for each system. This is the time from the detection of the outage to obviation of importance to business. For example, if an online bookseller's Web site is down for over a week, it may lose all customers to the competition. However, an overnight outage may only result in a few lost orders. Some real-time financial industry systems may have very low MAO values, where more elongated global supply-chain processes with built-in delays may have MAO values that exceed a month. 8. Identify and document potential system threats, severity and the probability at which they may occur. For example, a datacenter fire severity would be 1.00 (on a .0–1.0 scale) but the probability may only be .01 (1%) in a given year. Threat statistics are available from a variety of sources and are used by insurance companies to calculate insurance premiums. Create a threat score for each incident type in a different section of the same spreadsheet. In the above example you would multiply (.01 x 1.0 =.01) and yield a combined risk score of .01 or 1%. Do this for all conceivable threats. You will also want to list one generic loss at 100% just to have a line item that reflects a complete loss for each system regardless of the incident or probability. This sets the upper bound for the system valuation. 9. Now you have most of the data needed to start the process. It is best to use the simple formula functions that a spreadsheet provides. For every system you have defined with a loss value, multiply the series of values from the threats listed in step eight with the combined loss values from step six to see the relative loss or impact per system. Do this on a line item basis. For each system calculate all possible listed threats. Do not include items that are not physically possible. For example, if you have business systems in Malaysia and New York, don't include the volcano or similar incidents that can't really happen in New York. 10. In this last step you will sort the data you have to show the top priority systems both from a business criticality and impact perspective. In the spreadsheet, select all columns in the sheet and use the "auto-filter" function on the data-sorting menu of your spreadsheet to link all the columns relationally. You can now sort

on any of the variables in the sheet. Optionally, you can create a scorecard-like report by dressing up the spreadsheet, or add a narrative document and use the spreadsheet as the supporting data source. Your BIA report can be used to request and prioritize resources, and incident-response activity. If done properly, it will be in a format your CFO and finance department can understand and include impact data gathered from these very same people, thus overcoming any objections or pushback on the validity of your report and subsequent resource requests!

Conducting a Business Impact Analysis Guide Objective The purpose of this document is to help businesses conduct a Business Impact Analysis (BIA), which identifies the business’s critical processes, required resources for each process and the order in which processes need to be recovered. This document provides guidance on how to conduct the BIA, analyze the information that is collected, and report the findings of the assessment. The following documents are available to help the business complete the assessment: • • • • •

Business Impact Analysis Template (both short and long versions) Application & Data Criticality Template Final Business Unit Report Template Final Executive Management Report Template Examples of Impact

The Business Impact Analysis is only a part of the overall Business Assessment. A Business Assessment is separated into two constituents, Risk Assessment and Business Impact Analysis (BIA). The Risk Assessment is intended to measure present vulnerabilities to the business’s environment, while the Business Impact Analysis evaluates probable loss that could result during a disaster. To maximize the Business Impact Analysis, a Risk Assessment should also be completed. Table of Contents of Conducting a Business Impact Analysis INTRODUCTION Compliance Scope BUSINESS IMPACT ANALYSIS Objectives of the Business Impact Analysis Developing the Project Plan BIA Process Steps

PHASE ONE – PROJECT DEVELOPMENT Scope Objectives and Deliverables Method of Collection Identify People Interview Order PHASE TWO – GATHER DATA General Information Process Information Dependencies Required Resources Potential Impact PHASE THREE – APPLICATION & DATA CRITICALITY Application Information Database Information Hardware Information Network Information PHASE FOUR – ANALYZE THE DATA Review Business Unit BIA Follow-Up Meetings Report the Results FINAL REPORT & PRESENTATION Creation of Executive Report Presentations NEXT STEPS APPENDIX Appendix A: Appendix B: Appendix C: Appendix D: Appendix E: Appendix F: Appendix G:

Business Impact Analysis Short Template Business Impact Analysis Long Version Template Application & Data Criticality Analysis Template Final Business Unit Report Template Final Executive Report Template Sample BIA Questions Examples of Impacts

Long Version Business Impact Analysis Template Objectives

Due to HIPAA Security Rule regulations, organization must implement Contingency Planning Practices to ensure the protection of ePHI (electronic Protected Health Information). In order to accomplish this undertaking, there are several steps that organization will be completing to identify critical business functions, processes and applications that process ePHI and to understand the potential impact to the business if a disruptive event occurred. The first step of implementing the Contingency Program for organization is to conduct a Business Impact Analysis (BIA). This questionnaire will help each business unit identify their critical business functions and recovery requirements as well as estimating the impact of a disaster (or prolonged outage) to the business unit. Once the survey is completed, the BIA Project team will review the data, analyze and create a prioritized recovery strategy to present to senior management. For the purpose of this BIA, answer each question based on the “worst-case scenario”. This means your workplace and all records; files and equipment in it are inaccessible. The priority of this questionnaire is to identify any business process or application that currently contains ePHI. However, please answer all questions regardless of ePHI status. By completing all questions to the best of your knowledge, a recovery strategy that best meets the need of the business can be established. Some questions will be directly related to a specific process where as other questions are about the business unit in general. Some sections contain an additional “Notes” area to amplify or explain your responses. While this is not a requirement, it can be useful in helping the Project Team understand the nature of your business unit operations. T a b l e o f C o n t e n t s : B u s i n e s s I m p a c t A n a l y s i s S u r v e y T e m pl a t e OBJECTIVE GENERAL INFORMATION Respondent Information Business Unit / Department Information ePHI (electronic Protected Health Information) Service Providers Business Unit Vulnerability Recovery Complexity PROCESS INFORMATION Process Identification Process Criticality & Frequency Processing Periods Process Unavailability Impact Process Deferrable Manual Work – Around Procedures for Processes Alternate Facilities / Work-load shifting Backlog Work

DEPENEDENCIES Internal Received Dependencies (Same Company) Internal Sent Dependencies (Same Company) External Received Dependencies (Outside Provider) External Sent Dependencies (Outside Provider) REQUIRED RESOURCES Software Resources Specialized Supplies and Clerical Type Resources Equipment Resources Manpower Resources Reports POTENTIAL IMPACT Financial Impact Customer & Operational Impact Legal & Regulatory Impact F i n a l B I A E x e c u t i v e M a n a g e m e n t R e p o r t T e m p l at e s w / C h a r t s Executive Overview Objectives The intent of the Business Impact Analysis (BIA) was to help our organization identify which business units, operations and processes are crucial to the survival of the business. The BIA has identified the time frames in which essential business operations must be restored to full functionality following a disruptive event. It has defined the business impact of not performing critical business operations based on a worst-case scenario. The BIA has also identified the resources required to resume business operations to a functioning level. A worst-case scenario assumes that the physical infrastructure supporting each respective business unit has been destroyed and all records, equipment, etc are not accessible within 30 days. The objectives for this BIA were: 1. Estimate the financial, customer/operation, and legal/regulatory impacts for each major business unit, assuming a worst-case scenario 2. Determine the estimated number of personnel required for recovery operations 3. Identify the critical business functions, business unit processes and the estimated Recovery Time Objective (RTO) for each business unit. 4. Provide a foundation for implementing Contingency Plans for HIPAA Security Rule 164.308 (a) (7) compliancy.

The RTO is the maximum allowable time a process can be inoperative following an outage / disruptive event. These timeframes may have to be re-evaluated to meet the requirements of the Technology capabilities. If the capabilities of technology do not meet the requirements of the business unit, a gap exists. These gaps must be mitigated to prevent extended outages and impact to your organization. Table of Contents:Executive BIA Finding Report EXECUTIVE OVERVIEW Objectives Scope Approach Department Responses and Findings BUSINESS UNIT RESULTS SUMMARY OF FINDINGS Combined Financial Impact Combined Customer/Operational Impact Combined Legal and/or Regulatory Impact Recovery Personnel Requirements Recovery Time Objectives for Business Processes Manual Work-Around Processes Work Backlog Processing Recovery Complexity for Business Units CONCLUSION