Conducting the Business Impact Assessment

The Business Impact Assessment (BIA) describes the impact that a disaster is expected to have on business operations. This important early step in Business Continuity Planning helps an organization figure out which business processes are more resilient and which are more fragile.

A disaster’s impact includes quantitative and qualitative effects. The quantitative impact is generally financial, such as loss of revenue or output of production. The qualitative impact has more to do with the delivery of goods and/or services.

Any Business Impact Assessment worth its salt needs to perform the following tasks well:

Perform a Vulnerability Assessment

Carry out a Criticality Assessment — determining how critically important a particular business function is to the ongoing viability of the organization

Determine the Maximum Tolerable Downtime

Establish recovery targets

Determine resource requirements

You can get the scoop on these activities in the following sections.

Vulnerability Assessment

Often, a BIA includes a Vulnerability Assessment that helps get a handle on obvious and not-so-obvious weaknesses in business critical systems. A Vulnerability Assessment has quantitative (financial) and qualitative (operational) sections, similar to a Risk Assessment, which is covered in detail in Chapter 6.

The purpose of a Vulnerability Assessment is to determine the impact — both quantitative and qualitative — of the loss of a critical business function.

Quantitative losses include

Loss of revenue

Loss of operating capital

Loss because of personal liabilities

Increase in expenses

Penalties because of violations of business contracts

Violations of laws and regulations (which can result in legal costs such as fines and civil penalties)

Qualitative losses include loss of

Service quality

Competitive advantages

Customer satisfaction

Market share

Prestige and reputation

The Vulnerability Assessment identifies critical support areas, which are business functions that, if lost, would cause irreparable harm to the business by jeopardizing critical business processes or the lives and safety of personnel. The Vulnerability Assessment should carefully study critical support areas to identify the resources that those areas require to continue functioning.

Quantitative losses include an increase in operating expenses because of any higher costs associated with executing the contingency plan. In other words, planners need to remember to consider operating costs that may be higher during a disaster situation.

Criticality Assessment

The BCP team should inventory all high-level business functions (for example, customer support, order processing, returns, cash management, accounts receivable, payroll, and so on) and rank them in order of criticality. The team should also describe the impact of a disruption to each function on overall business operations.

The team members need to estimate the duration of a disaster event to effectively prepare the Criticality Assessment. Project team members need to consider the impact of a disruption based on the length of time that a disaster impairs critical business functions. You can see the vast difference in business impact of a disruption that lasts one minute, compared to one hour, one day, one week, or longer. Generally, the criticality of a business function depends on the degree of impact that its impairment has on the business.

Planners need to consider disasters that occur at different times in the business cycle, whatever that might be for an organization. Response to a disaster at the busiest time of the month (or year) may vary quite a bit from response at other times.

Identifying key players

Although you can consider a variety of angles when evaluating vulnerability and criticality, commonly you start with a high-level organization chart. (Hip people call this chart the org chart). In most companies, the major functions pretty much follow the structure of the organization.

Following an org chart helps the BCP project team consider all the steps in a critical process. Walk through the org chart, stopping at each manager’s or director’s position and asking, “What does he do?”, “What does she do?”, and “Who files the TPS reports?” This mental stroll can help jog your memory, and help you better see all the parts of the organization’s big picture.

When you’re cruising an org chart to make sure that it covers all areas of the organization, you may easily overlook outsourced functions that might not show up in the org chart. For instance, if your organization outsources accounts payable (A/P) functions, you might miss this detail if you don’t see it on an org chart. Okay, you’d probably notice the absence of all A/P. But if your organization outsources only part of A/P — say, a group that detects and investigates A/P fraud (looking for payment patterns that suggest the presence of phony payment requests) — your org chart probably doesn’t include that vital function.

Establishing Maximum Tolerable Downtime

An extension of the Criticality Assessment (which we talk about in the section “Criticality Assessment,” earlier in this chapter) is a statement of Maximum Tolerable Downtime (MTD —also known as Maximum Tolerable Period of Disruption or MTPD) for each critical business function. Maximum Tolerable Downtime is the maximum period of time that a critical business function can be inoperative before the company incurs significant and long-lasting damage.

For example, imagine that your favorite online merchant — a bookseller, an auction house, or an online trading company — goes down for an hour, a day, or a week. At some point, you have to figure that a prolonged disruption sinks the ship, meaning the business can’t survive. Determining MTD involves figuring out at what point the organization suffers permanent, measurable loss as a result of a disaster. Online retailers know that even shorter outages may mean that some customers will switch brands and take their business elsewhere.

Make the Maximum Tolerable Downtime assessment a major factor in determining the criticality — and priority — of business functions. A function that can withstand only two hours of downtime obviously has a higher priority than another function that can withstand several days of downtime.

Maximum Tolerable Downtime is a measure of the longest period of time that a critical business function can be disrupted without suffering unacceptable consequences, perhaps threatening the actual survivability of the organization.

Establish recovery targets

When you establish the Criticality Assessment and Maximum Tolerable Downtime for each business process (which we talk about in the preceding sections), the planning team can establish recovery targets. These targets represent the period of time from the onset of a disaster until critical processes have resumed functioning.

Two primary recovery targets are usually established for each business process: a Recovery Time Objective and Recovery Point Objective. We discuss these targets in the following sections.

Recovery Time Objective

A Recovery Time Objective (RTO) is the maximum period of time in which a business process must be restored after a disaster.

An organization without a DR plan that suffers a serious disaster, such as an earthquake or hurricane, could experience an RTO of one to two weeks or more. An organization could possibly need this length of time to select a new location for processing data, purchase new systems, load application software and data, and resume processing. An organization that can’t tolerate such a long outage needs to establish a shorter RTO and determine the level of investments required to meet that target.

Recovery Point Objective

A Recovery Point Objective (RPO) is the maximum period of time in which data might be lost if a disaster strikes.

The traditional schedule for backing up data is once per day. If a disaster occurs before backups are done, the organization can lose an entire day’s worth of information. This is because system and data recovery are often performed using the last good set of backups. An organization that requires a shorter RPO needs to figure out a way to make copies of transaction data more frequently than once per day.

Here are some examples of how organizations might establish their RPOs:

Keyed Invoices. An accounts payable department opens the mail and manually keys in the invoices that it receives from its suppliers. Data entry clerks spend their entire day inputting invoices. If a disaster occurs before backups are run at the end of the business day (and if that disaster requires the organization to rebuild systems from backup tapes), those clerks have to redo that whole day’s worth of data entry.

Online orders: A small business develops an online web application that customers can use to place orders. At the end of each day, the Orders department runs a program that prints out all the day’s orders, and the Shipping department fills those orders on the following day. If a disaster occurs at any time during the day, the business loses all online orders placed since the previous day’s backup.

If you establish the Maximum Tolerable Downtime for processes such as the ones in the preceding list as less than one business day, the organization needs to take some steps to save online data more than once per day.

Many organizations consider off-site backup media storage, where backup tapes are transported off-site as frequently as every day, or where electronic vaulting to an offsite location is performed several times each day. An event such as a fire can destroy computers as well as backup media if it is nearby.

How the Recovery Time Objective and Recovery Point Objective work together

RPO and RTO targets are different measures of recovery for a system, but they work together. When the team establishes proposed targets, the team members need to understand how each target works.

At first glance, you might think that RPO should be a shorter time than RTO (or maybe the other way around). In fact, different businesses and applications present different business requirements that might make RPO less than RTO, equal to RTO, or greater than RTO. Here are some examples:

RPO greater than RTO: A business can recover an application in 4 hours (RTO), and it has a maximum data loss (RPO) of 24 hours. So, if a disaster occurs, the business can get the application running again in 4 hours, but data recovered in the system consists of data entered prior to 24 hours before the incident took place.

RPO equal to RTO: A business can recover an application in 12 hours (RTO), with a maximum data loss of 12 hours (RPO). You can probably imagine this scenario: An application mirrors (or replicates) data to a backup system in real-time. If a disaster occurs, the disaster recovery team requires 12 hours to start the backup system. After the team gets the system running, the business has data from until 12 hours in the past — the time when the primary system failed.

RPO less than RTO: The disaster recovery team can recover an application in 4 hours (RTO), with a maximum data loss of 1 hour (RPO). How can this situation happen? Maybe a back-office transaction-posting application, which receives and processes data from order-processing applications, fails. If the back-office application is down for 4 hours, data coming from the order-processing applications may be buffered someplace else, and when the back-office application resumes processing, it can then receive and process the waiting input data.

Defining Resource Requirements

The Resource Requirements portion of the BIA is a listing of the resources that an organization needs in order to continue operating each critical business function. In an organization that has finite resources (which is pretty much every organization), the most critical functions get first pick, and the lower-priority functions get the leftovers.

Understanding what resources are required to support a business process helps the project team to figure out what the contingency plan for that process needs to contain, and how the process can be operated in Emergency mode and then recovered.

Examples of required resources include

Systems and applications: In order for a business process to continue operating, it may require one or more IT systems or applications — not only the primary supporting application, but also other systems and applications that the primary application requires in order to continue functioning.

Suppliers and partners: Many business processes require a supply of materials or services from outside organizations, without which the business process can’t continue operating.

Key personnel: Most business processes require a number of specifically trained or equipped staff members — or contingent workers such as contractors or personnel from another company — to run business processes and operate systems.

Business equipment: Anything from PBXs to copiers, postage machines, POS (point-of-sale) machines, red Swingline staplers, and any other machinery required to support critical business processes.

When you identify required resources for complex business processes, you may want to identify additional information about each resource, including resource owners, criticality, and dependencies.