Benchmark - Business Impact Analysis and Resource Profile

Business Impact Analysis Template

1. Overview

This business impact analysis (BIA) was developed as part of the contingency planning process for the { company name }. It was prepared by { insert student name }.

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 processes and recovery criticality. Mission/Business processes supported by 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 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 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.

This document is used to build the 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.

2. System Description

<Provide a general description of system architecture and functionality in 150-words or less.>

3. BIA Data Collection

3.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
Pay vendor invoice	Process of obligating funds, issuing check or electronic payment, and acknowledging receipt

3.1.1 Identify Outage Impacts and Estimated Downtime

Business Process 1: This section identifies and characterizes the types of impact that a system disruption is likely to create, as well as the estimated downtime that the organization can tolerate for a given process.

Business Process 2: This section identifies and characterizes the types of impact that a system disruption is likely to create, as well as the estimated downtime that the organization can tolerate for a given process.

Business Process 3: This section identifies and characterizes the types of impact that a system disruption is likely to create, as well as the estimated downtime that the organization can tolerate for a given process.

Outage Impacts

The following impact categories represent important areas for consideration in the event of a disruption or impact.

Impact category:

· Additional Cost (expenses)

· Customer Loyalty (trust)

· Loss of Revenue (income)

· Regulatory or Legal Ramifications (penalties)

Example Impact Category = Cost

· Severe - temporary staffing, overtime, fees are greater than $1 million

· Moderate – fines, penalties, liabilities potential $550,000

· Minimal – new contracts, supplies $75,000

Impact values for assessing category impact:

· Severe

· Moderate

· Minimal

The table below summarizes the impact on each mission/business process, if unavailable, based on the following criteria:

Mission/Business Process	Impact Category
	Expenses	Trust	Income	Penalty	∑ Impact
Pay vendor invoice	Minimal	Moderate	Minimal	Minimal	Moderate

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

Values for MTDs and RPOs are expected to be specific timeframes, identified in hourly increments (e.g., 8 hours, 36 hours, 97 hours).

Mission/Business Process	MTD	RTO	RPO
Pay vendor invoice	72 hours	48 hours	12 hours (last backup)

Business Process 1: Include a description of the drivers for the MTD, RTO, and RPO listed in the table above (e.g., mandate, workload, performance measure).

Business Process 2: Include a description of the drivers for the MTD, RTO, and RPO listed in the table above (e.g., mandate, workload, performance measure).

Business Process 3: Include a description of the drivers for the MTD, RTO, and RPO listed in the table above (e.g., mandate, workload, performance measure).

3.2 Identify Resource Requirements

The following table identifies the resource requirements including hardware, software, and other resources, such as data files.

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

It is assumed that all identified resources support the mission/business processes identified in Section 3.1 unless otherwise stated.

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

Priority	System Resource/Component	Recovery Time Objective
Web Server 1	OptiPlex GX280	24 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.

© 2021. Grand Canyon University. All Rights Reserved.

4