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 non-
revenue 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: Business Impact Analysis Short Template

Appendix B: Business Impact Analysis Long Version Template
Appendix C: Application & Data Criticality Analysis Template
Appendix D: Final Business Unit Report Template
Appendix E: Final Executive Report Template
Appendix F: Sample BIA Questions
Appendix G: 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