Business Impact

Analysis For
Information Security
 TABLE OF CONTENT

1. Overview ................................................................................. 01
2. Executive summary .............................................................. 01
3. Purpose .................................................................................... 01
4. Methodology ........................................................................... 02
5. BIA steps .................................................................................. 03
6. System description ................................................................ 04
7. BIA sample .............................................................................. 06
7.1 Determine process system criticality ........................... 06
7.2 Identify Resource Requirements ................................... 09
7.3 Identify Recovery Priorities for System Resources .... 10
8. Key findings .............................................................................. 11
9. Recommendations .................................................................. 12
10. Summary ................................................................................. 13
 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}.

2.EXECUTIVE SUMMARY

The Business Impact Analysis (BIA) provides a comprehensive overview of our

organization's critical functions and their potential vulnerabilities to disruptions.
It identifies key operational areas, assesses the impact of their interruption, and
outlines strategies to ensure continuity. This summary offers a structured
approach to understanding and mitigating risks, enabling quick recovery and
maintaining essential operations during unforeseen events. The template guides
resource allocation and recovery planning, enhancing our resilience and
preparedness to navigate unexpected challenges.

3.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.

01
 4.METHODOLOGY
1.PREPARATION
Build a team of current or outsourced
employees to carry out your business
impact analysis, then define and
document its objectives and scope.

2.INFORMATION GATHERING
Anyone who performs or manages any
part of the process should complete a
business impact analysis survey for you
to consolidate into one document.

3.INFORMATION REVIEW
& ANALYSIS
The team will need to look at each process
to determine which functions are most
important, what resources are needed to
operate them successfully, and the
recovery timeline for bringing each to
normal operation.

4.BIA REPORT CREATION

This report is the most important outcome
of your BIA. Use it to communicate your
findings and recommendations to
leadership with the power to make
changes to the disaster recovery process.

5.RECOMMENDATION
IMPLEMENTATION
Once your team has conducted steps 1-
4, it is ultimately up to leadership to act.
However, your team can help promote
the findings of the analysis and
encourage leadership to move forward.

02
 5. BIA is composed of the
following three steps:

01. Determine
mission/business processes
and recovery criticality.
LMission/business processes supported
by the system are identified and the
impact of a system disruption to those 2. Identify resource
processes is determined along with requirements.
outage impacts and estimated
downtime. The downtime should reflect
Realistic recovery efforts require a
the maximum that an organization can
thorough evaluation of the resources
tolerate while still maintaining the
required to resume mission/business
mission.
processes 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 processes. Priority
levels can be established for
sequencing recovery activities and
resources.

03
 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 Cyber Incident
Response Plan.

6. SYSTEM DESCRIPTION

Here is a template for conducting a Business Impact

Analysis (BIA) on information security:

01. Identify critical business processes:

Identify the business processes that are essential to the organization's
operations. These processes should be ranked according to their
importance, with the most critical processes given the highest priority.

02. Identify the assets and resources that support these processes:
Identify the IT assets and resources that are necessary to support
thecritical business processes. This includes hardware, software,
networks,data, and personnel.

03. Identify the threats and vulnerabilities:

Identify the potential threats to the organization's information security,
such as cyber attacks, natural disasters, power outages, and human error.
Identify the vulnerabilities in the organization's IT infrastructure that
could be exploited by these threats.

04
04. Assess the impact of a disruption
Determine the potential impact of a disruption to the critical business
processes and IT assets. This should include the financial impact, operational
impact, and reputational impact.

05. Determine the recovery time objectives (RTOs):

Determine the maximum amount of time that the organization can afford to
be without access to its critical business processes and IT assets.

06. Identify recovery strategies:

Identify the strategies that can be used to recover the critical business
processes and IT assets. These strategies may include backup and restore
procedures, redundant systems, and alternate processing sites.

07. Develop a BIA report:

Document the findings of the BIA in a report that includes an overview of
the organization's critical business processes and IT assets, a summary of
the threats and vulnerabilities, an assessment of the potential impact of a
disruption, and the recovery strategies that will be used.

08. Review and update the BIA:

Regularly review and update the BIA to ensure that it remains current and
reflects changes in the organization's operations, IT infrastructure, and
threat landscape.

By following this template, organizations can conduct a comprehensive BIA on

information security that will help them to identify their critical business
processes and IT assets, assess the potential impact of a disruption, and develop
recovery strategies to minimize the impact of an incident

05
 7. BIA SAMPLE

Data collection can be accomplished through individual/group interviews,

workshops, email, questionnaires, or any combination of these.

7.1 Determine Process and System Criticality

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

Mission/Business Process Description

Process of obligating funds, issuing

Pay vendor invoice check or electronic payment and
acknowledging 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.

06
7.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 FIPS
199 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 an impact category's 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 a disruption or impact.
Impact category: {insert category name}
Impact values for assessing category impact:
• Severe = {insert value}
• 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} Impact

Pay vendor invoice

07
Estimated Downtime
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) the selection of an appropriate recovery method, and (2) the
depth of detail that 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 processes, 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 processes 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
MTD RTO RPO
Process

12 hours
Pay vendor invoice 72 hours 48 hours
(last backup)

Include a description of the 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
workaround) for recovering the mission/business process(es) that rely on the
system. If none exist, so state.

08
7.1.2 Identify Resource Requirements

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

System Platform/OS/Version Description

Resource/Component (as applicable)

Web Server 1 Optiplex GX280 Web Site Host

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

identified in Section 7.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.

09
7.1.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 processes, and the MTD. Determining the information
system resource RTO is important for selecting appropriate technologies
that are best suited for meeting the MTD

System Recovery Time

Priority
Resource/Component Objective

24 hours to rebuild or
Web Server 1 Optiplex GX280
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.

10
 8. Key Findings

Finding No.1 :

Finding No.2 :

Finding No.3:

Finding No.4 :

11
9. RECOMMENDATIONS

Recommendation No.1

Recommendation No.2

Recommendation No.3

12
 10. Summary
Summary
Point 1

Summary
Point 2

Summary
Point 3

13