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. egular (non!italic) te"t 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 y correlating them to the
mission!usiness process(es) the system supports" and using this information to characterize the impact on
the process(es) if the system were unavailale.
The BIA is composed of the following three steps#
$. Determine mission/business processes and recovery criticality. %ission!usiness processes
supported y the system are identified and the impact of a system disruption to those processes is
determined along with outage impacts and estimated downtime. The downtime should reflect the
ma&imum that an organization can tolerate while still maintaining the mission.
'. Identify resource requirements. (ealistic recovery efforts re)uire a thorough evaluation of the
resources re)uired to resume mission!usiness processes and related interdependencies as )uic*ly
as possile. +&amples of resources that should e identified include facilities" personnel"
e)uipment" software" data files" system components" and vital records.
,. Identify recovery priorities for system resources. Based upon the results from the previous
activities" system resources can more clearly e lin*ed to critical mission!usiness processes.
-riority levels can e estalished for se)uencing recovery activities and resources.
This document is used to uild the #system name$ Information .ystem /ontingency -lan (I./-) and is
included as a *ey component of the I./-. It also may e used to support the development of other
contingency plans associated with the system" including" ut not limited to" the 0isaster (ecovery -lan
(0(-) or /yer Incident (esponse -lan.
2. System Description
%rovide a general description of system architecture and functionality. Indicate the operating
environment, physical location, general location of users, and partnerships with e"ternal
organi&ations'systems. Include information regarding any other technical considerations that are
important for recovery purposes, such as bac(up procedures. %rovide a diagram of the architecture,
including inputs and outputs and telecommunications connections.
)ote* Information for this section should be available from the system+s ,ystem ,ecurity %lan (,,%) and
can be copied from the ,,%, or reference the applicable section in the ,,% and attach the latest version of
the ,,% to this contingency plan.
Example impact category = Cost
Severe ! temp staffing, overtime,
fees are greater than -. million
Moderate / fines, penalties,
liabilities potential -001(
Minimal / new contracts,
supplies -20(
3. BIA Data Collection
3ata collection can be accomplished through individual'group interviews, wor(shops, email,
questionnaires, or any combination of these.
3.1 Determine Process and System Criticality
Step one of the BIA process 1 2or*ing with input from users" managers" mission!usiness process
owners" and other internal or e&ternal points of contact (-3/)" identify the specific mission!usiness
processes that depend on or support the information system.
Mission/Business Process Description
%ay vendor invoice
%rocess of obligating funds, issuing chec( or electronic
payment and ac(nowledging receipt
If criticality of mission'business processes has not been determined outside of the BIA, the following
subsections will help to determine criticality of mission'business processes that depend on or support the
information system.
3.1.1 Identify Outae Impacts and !stimated Downtime
This section identifies and characteri&es the types of impact categories that a system disruption is li(ely
to create in addition to those identified by the 4I%, .55 impact level, as well as the estimated downtime
that the organi&ation 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
e"ample of cost as an impact category is provided. 6rgani&ations could consider other categories li(e
harm to individuals and ability to perform mission. The template should be revised to reflect what is
appropriate for the organi&ation.
Outae Impacts
Impact categories and values should be created in order to characteri&e levels of severity to the
organi&ation 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 organi&ation.
The following impact categories represent important areas for consideration in the event of a disruption or
impact.
Impact category# {insert category name}
Impact values for assessing category impact#
.evere 4 {insert value}
%oderate 4 {insert value}
%inimal 4 {insert value}
The tale elow summarizes the impact on each mission!usiness process if #system name$ were
unavailale" ased on the following criteria#
Mission/Business Process
Impact Cateory
!insert" !insert" !insert" !insert" Impact
%ay vendor invoice
!stimated Downtime
2or*ing directly with mission!usiness process owners" departmental staff" managers" and other
sta*eholders" estimate the downtime factors for consideration as a result of a disruptive event.
Ma#imum $olerable Do%ntime &M$D'. The %T0 represents the total amount of time
leaders!managers are willing to accept for a mission!usiness process outage or disruption and
includes all impact considerations. 0etermining %T0 is important ecause it could leave
continuity planners with imprecise direction on ($) selection of an appropriate recovery method"
and (') the depth of detail which will e re)uired when developing recovery procedures"
including their scope and content.
(ecovery $ime )b*ective &($)'. (T3 defines the ma&imum amount of time that a system
resource can remain unavailale efore there is an unacceptale impact on other system
resources" supported mission!usiness processes" and the %T0. 0etermining the information
system resource (T3 is important for selecting appropriate technologies that are est suited for
meeting the %T0.
(ecovery Point )b*ective &(P)). The (-3 represents the point in time" prior to a disruption or
system outage" to which mission!usiness process data must e recovered (given the most recent
ac*up copy of the data) after an outage.
The tale elow identifies the %T0" (T3" and (-3 (as applicale) for the organizational
mission!usiness processes that rely on #system name$. 7alues for 8T3s and %6s are e"pected to be
specific time frames, identified in hourly increments (i.e., 9 hours, :; hours, 52 hours, etc.).
Mission/Business Process M$D ($) (P)
%ay vendor invoice 2< hours =9 hours
.< hours (last
bac(up)
Include a description of the drivers for the 8T3, T6, and %6s listed in the table above (e.g., mandate,
wor(load, performance measure, etc.).
Include a description of any alternate means (secondary processing or manual wor(!around) for
recovering the mission'business process(es) that rely on the system. If none e"ist, so state.
3.2 Identify "esource "e#uirements
The following tale identifies the resources that compose #system name$ including hardware" software"
and other resources such as data files.
System (esource/Component
Platform/)S/+ersion
&as applicable'
0escription
Web Server 1 Optiplex GX28 Web Site !ost
It is assumed that all identified resources support the mission!usiness processes identified in .ection ,.$
unless otherwise stated.
)ote* Information for this section should be available from the system+s ,ystem ,ecurity %lan (,,%) and
can be copied from the ,,%, or reference the applicable section in the ,,% and attach the latest version of
the ,,% to this contingency plan.
3.3 Identify "ecovery Priorities for System "esources
The tale elow lists the order of recovery for #system name$ resources. The tale also identifies the
e&pected time for recovering the resource following a 5worst case6 (complete reuild!repair or
replacement) disruption.
(ecovery $ime )b*ective &($)' 1 (T3 defines the ma&imum amount of time that a system
resource can remain unavailale efore there is an unacceptale impact on other system
resources" supported mission!usiness processes" and the %T0. 0etermining the information
system resource (T3 is important for selecting appropriate technologies that are est suited for
meeting the %T0.
Priority
System
(esource/Component
(ecovery $ime )b*ective
>eb ,erver . 6ptiple" ?@<91 <= hours to rebuild 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 e"pected T6s. This includes bac(up or spare
equipment and vendor support contracts.