| The University of Texas at Austin
|
Information Security Office
|

| |
Risk Management Services

Business Impact Analysis Instructions

Use the instructions below to help you complete the BIA template for each business process.

Header and Footer Information

The information in the document header and footer populate automatically from information you enter in the content areas. If you change the style names used in these sections, the header and footer may not populate correctly.

Critical Dates and Impact Timeline

You should identify both critical dates when the business process must be functional and how long it would take to feel the impact of a failure. Identify any dates, date ranges, or times of day that are particularly critical to the business process being analyzed. These critical dates are not only for the process being analyzed, but also for any downstream processes.

To complete the template, enter the length of time until the specific impact level is reached. Be sure to fill in the impact for the line pre-filled with “Normal Operation” so that you know what the impact will be on your routine operations. The impact levels are as follows:

  • N: None – There is no impact on any work function. An example would be a process that runs only intermittently; normal function would continue until the next interval that process is scheduled to run.
  • M: Moderate – The failure of the process results in minor or moderate disruption to the function of the department itself or to another department with a downstream dependency.
  • S: Severe – The failure of the process results in the department or another department with a downstream dependency being unable to function.
  • C: Catastrophic – The failure of the process results in a disruption of the university’s daily functioning.

This information could be provided in the following way:

Date/Time

Details

Time Until Impact

N

M

S

C

 

Normal Operation

24h

 

 

 

Daily@ 12AM

Run batch process

24h

48h

 

 

11/15

Run critical report

 

 

4h

 

3/10-3/15

Downstream process accesses database for critical function

 

 

.25h

 

Every Friday

Process all new entries for the week

 

6d

7d

 

The boxes on each row in the N, M, S, or C columns should be filled in with the length of time after a failure that it takes for the impact level to be reached. While these examples are generic, real entries should be specific and meaningful. Below the table, additional detail should be provided if needed to fully explain the critical time period.

Operational and Financial Impacts

Describe any impact to operations in this section, and specify any financial costs associated with this function not being performed.

Examples of operational impacts at the university include, but are not limited to:

  • Regulatory/Compliance Issues
  • Damage to Reputation
  • Embarrassment
  • Loss of research data
  • Disruption of teaching
  • Disruption of research
  • Loss of faculty
  • Loss of staff
  • Loss of students
  • Well-being of faculty/staff
  • Well-being of students
  • Legal obligations unmet by campus
  • Legal harm to the university
  • Impact on other campus unit(s)
  • Impact on important partner(s)

Examples of financial impacts at the university include, but are not limited to:

  • Reduced Productivity
  • Increased Expenses
  • Delayed Collection of Funds
  • Reduced Income/Revenues
  • Breach of Contract
  • Lateness Penalties
  • Loss of future business
  • Loss of research funding
  • Payment deadlines unmet
  • Loss of revenue to campus

More explanation may be required for each of these that apply to the process being analyzed. Here is an example of how to fill out an entry in the template:

Impact:

Fines levied because of process failure                

The Association will begin levying fines if the process does not complete.

Time:

4 hours

Severity Level:

Moderate

We will be charged $15 per hour that the process does not complete.

Time:

8 hours

Severity Level:

Severe

Fines are increased to $1000 per hour

Time:

24 hours

Severity Level:

Severe

Fines are increased to $2000 per hour

Time:

48 hours

Severity Level:

Catastrophic

Fines are increased to $25000 per hour. External regulators are called in to investigate.

Each impact should have an entry.

Dependencies

List all the components the process relies on. Some things may be listed as aggregates. For example, although power is obviously critical, you may just list it as “power” rather than enumerating each of the components that comprise it. On the other hand, you may wish to include certain components that you manage, such as uninterruptible power supplies, power distribution units or the like. It is also important to be as specific when an dependency could be construed in different ways. For example, if a process relies only on local network connectivity, as opposed to WAN/Internet connectivity, spell that out specifically.

Upstream Dependencies

These are external processes that the process relies upon. For example, if the process requires a data feed from another server, that data feed would be considered an upstream dependency.

Downstream Dependencies

These are external processes that rely on the process and will be affected by its failure. If there are any critical time periods during which an interruption of this process will have an extraordinary effect on a downstream dependency, they should be noted in the critical date section of the impact analysis.

Recovery Time Objective

The Recovery Time Objective (RTO) is a goal you set for the amount of time it should take to restore the service. When figuring the RTO, account for other business processes that must be restored as well as the impacts that this process has when unavailable. If there are a number of processes that must be restored, it may be helpful to develop several tiers for RTOs. For example, Tier 1 could be 0-4 hours, Tier 2 4-24 hours, etc. These tiers are arbitrary and should be developed based on the needs of your organization.

Work-around Procedures

There may be multiple work-around procedures for this process. For each workaround identified, the following information should be provided:

  • Work-around name
  • Description
  • Date last tested or used
  • Hardware Required
  • Additional Personnel Required
  • Additional Supplies Required
  • How long can it be used?
  • How long will it take to implement this work-around?
  • What % of production can this alternative provide?

 



Last updated July 20, 2009.
Copyright © 2006-14, Information Security Office. All rights reserved.
Privacy | Accessibility | Emergency Preparedness, Safety and Security

Send computing questions to the ITS Help Desk or call (512) 475-9400.

 

| | | |