University Information Technology Services

Business Impact Analysis

For
{System Name}

Prepared by
Victor Font
UITS Business Continuity / Disaster Recovery Coordinator
January 2013
Business Impact Analysis for {System Name}

1.   Overview ....................................................................................................................... 3  
1.1   Purpose................................................................................................................... 3  
2.   System Description ....................................................................................................... 4  
3.   BIA Data Collection ..................................................................................................... 4  
3.1   Determine Process and System Criticality ............................................................. 4  
3.1.1   Identify Outage Impacts and Estimated Downtime ........................................ 5  
3.2   Identify Resource Requirements ............................................................................ 6  
3.3   Identify Recovery Priorities for System Resources ............................................... 7  

2
Business Impact Analysis for {System Name}

This sample template is designed to assist the user in performing a Business Impact
Analysis (BIA) on an information system. The template is meant only as a basic guide and
may not apply equally to all systems. The user may modify this template or the general
BIA approach as required to best accommodate the specific system. In this template,
words in italics are for guidance only and should be deleted from the final version.
Regular (non-italic) text is intended to remain.

1. Overview
This Business Impact Analysis (BIA) is developed as part of the contingency planning
process for the {system name}{system acronym}. It was prepared on {insert BIA
completion date}.

1.1 Purpose  

The purpose of the BIA is to identify and prioritize system components by correlating
them to the mission/business process(es) the system supports, and using this information
to characterize the impact on the process(es) if the system were unavailable.
The BIA is composed of the following three steps:

1. Determine mission/business functions and recovery criticality. Mission/business

functions supported by the system are identified and the impact of a system disruption
to those functions is determined along with outage impacts and estimated downtime.
The downtime should reflect the maximum that an organization can tolerate while
still maintaining the mission.

2. Identify resource requirements. Realistic recovery efforts require a thorough

evaluation of the resources required to resume mission/business functions and related
interdependencies as quickly as possible. Examples of resources that should be
identified include facilities, personnel, equipment, software, data files, system
components, and vital records.

3. Identify recovery priorities for system resources. Based upon the results from the
previous activities, system resources can more clearly be linked to critical
mission/business functions and functions. Priority levels can be established for
sequencing recovery activities and resources.

This document is used to build the {system name} Information System Contingency Plan
(ISCP) and is included as a key component of the ISCP. It also may be used to support
the development of other contingency plans associated with the system, including, but not
limited to, the Disaster Recovery Plan (DRP) or Incident Response Plan (IRP).

3
Business Impact Analysis for {System Name}

2. System Description

Provide a general description of system architecture and functionality. Indicate the

operating environment, physical location, general location of users, and partnerships
with external organizations/systems. Include information regarding any other technical
considerations that are important for recovery purposes, such as backup procedures.
Provide a diagram of the architecture, including inputs and outputs and
telecommunications connections.

Note: Information for this section should be available from the system’s System Security
Plan (SSP) and can be copied from the SSP, or reference the applicable section in the
SSP and attach the latest version of the SSP to this contingency plan.

3. BIA Data Collection

Data collection can be accomplished through individual/group interviews, workshops,
email, questionnaires, or any combination of these. Describe the process used for this
BIA here.

3.1 Determine  Process  and  System  Criticality  

Step one of the BIA process - Working with input from users, managers,
mission/business process owners, and other internal or external points of contact (POC),
identify the specific mission/business functions that depend on or support the information
system.

Mission/Business  Process   Description  

Process of obligating funds, issuing check
Pay Vendor Invoice or electronic payment and acknowledging
receipt

If criticality of mission/business functions has not been determined outside of the BIA, the
following subsections will help to determine criticality of mission/business functions that
depend on or support the information system.

4
Business Impact Analysis for {System Name}

3.1.1 Identify  Outage  Impacts  and  Estimated  Downtime  

This section identifies and characterizes the types of impact categories that a system
disruption is likely to create in addition to those identified by the Categorization of
University Information and Information Systems impact level, as well as the estimated
downtime that the organization can tolerate for a given process. Impact categories
should be created and values assigned to these categories in order to measure the level
or type of impact a disruption may cause. An example of cost as in impact category is
provided. Organizations could consider other categories like harm to individuals and
ability to perform mission. The template should be revised to reflect what is appropriate
for the organization.

Outage Impacts

Impact categories and values should be created in order to characterize levels of severity
to the organization that would result for that particular impact category if the
mission/business process could not be performed. These impact categories and values are
samples and should be revised to reflect what is appropriate for the organization.

The following impact categories represent

important areas for consideration in the event of Example impact category = Cost
a disruption or impact.
Severe: temp staffing, overtime
Impact category: {insert category name} fees are greater than $1 million.
Moderate: fines, penalties,
Impact values for assessing category impact: liabilities potential $550k
Minimal: new contracts,
• Severe = {insert value} supplies $75k
• Moderate = {insert value}
• Minimal = {insert value}

The table below summarizes the impact on each mission/business process if {system
name} were unavailable, based on the following criteria:

Impact  Category  
Mission/Business  Process  
{Insert}   {Insert}   {Insert}   {Insert}   Impact  
Pay Vendor Invoice

Estimated Downtime

5
Business Impact Analysis for {System Name}

Working directly with mission/business process owners, departmental staff, managers,

and other stakeholders, estimate the downtime factors for consideration as a result of a
disruptive event.

• Maximum Tolerable Downtime (MTD). The MTD represents the total amount
of time leaders/managers are willing to accept for a mission/business process
outage or disruption and includes all impact considerations. Determining MTD is
important because it could leave continuity planners with imprecise direction on
(1) selection of an appropriate recovery method, and (2) the depth of detail which
will be required when developing recovery procedures, including their scope and
content.

• Recovery Time Objective (RTO). RTO defines the maximum amount of time
that a system resource can remain unavailable before there is an unacceptable
impact on other system resources, supported mission/business functions, and the
MTD. Determining the information system resource RTO is important for
selecting appropriate technologies that are best suited for meeting the MTD.

• Recovery Point Objective (RPO). The RPO represents the point in time, prior to
a disruption or system outage, to which mission/business process data must be
recovered (given the most recent backup copy of the data) after an outage.

The table below identifies the MTD, RTO, and RPO (as applicable) for the organizational
mission/business functions that rely on {system name}. Values for MTDs and RPOs are
expected to be specific time frames, identified in hourly increments (i.e., 8 hours, 36
hours, 97 hours, etc.).

Mission/Business  Process   MTD   RTO   RPO  

Pay Vendor Invoice 72 Hrs. 48 Hrs. 12 Hrs. (last Backup)

Include a description of the business drivers for the MTD, RTO, and RPOs listed in the
table above (e.g., mandate, workload, performance measure, etc.).

Include a description of any alternate means (secondary processing or manual work-

around) for recovering the mission/business process(es) that rely on the application. If
none exist, so state.

3.2 Identify  Resource  Requirements  

6
Business Impact Analysis for {System Name}

The following table identifies the resources that compose {system name} including
hardware, software, and other resources such as data files.

Platform/OS/Version  
System/Resource  Component   Description  
(as  applicable)  
Web Server 1 Optiplex GX280 Web Site Host

It is assumed that all identified resources support the mission/business functions

identified in Section 3.1 unless otherwise stated.

Note: Information for this section should be available from the system’s System Security
Plan (SSP) and can be copied from the SSP, or reference the applicable section in the
SSP and attach the latest version of the SSP to this contingency plan.

3.3 Identify  Recovery  Priorities  for  System  Resources  

The table below lists the order of recovery for {system name} resources. The table also
identifies the expected time for recovering the resource following a “worst case”
(complete rebuild/repair or replacement) disruption.

• Recovery Time Objective (RTO) - RTO defines the maximum amount of time
that a system resource can remain unavailable before there is an unacceptable
impact on other system resources, supported mission/business functions, and the
MTD. Determining the information system resource RTO is important for
selecting appropriate technologies that are best suited for meeting the MTD.

System  Component/  
Priority   Recovery  Time  Objective  
Resource  
Web Server 1 Optiplex GX280 24 Hrs. to build or replace

A system resource can be software, data files, servers, or other hardware and should be
identified individually or as a logical group.

Identify any alternate strategies in place to meet expected RTOs. This includes backup or
spare equipment and vendor support contracts.