Business impact analysis (BIA) process basics

The BIA process and risk assessment are critical steps for disaster recovery planning. This tip can help you get started with conducting a BIA.

In an earlier technical tip on risk assessment, I mentioned that two important questions must be answered before...

deciding what is the most efficient and cost-effective recovery strategy: What can realistically happen to our IT environment? And how will it affect the business it supports if it happens? The next step is the BIA process: what impact would a given disaster have on the organization?

It’s difficult to separate the BIA process from the risk assessment because identifying risk is not meaningful unless we also understand the impact. It is the combined outcome of both that will help drive the DR planning process.

But that doesn’t mean they are directly related or mutually dependent. High risk does not necessarily mean high impact and, likewise, an event that would have a high impact does not mean that a high risk exists. In addition, there is no rule as to which process should take place first. Some DR industry professionals start with the BIA process and then assess risk, while others focus on identifying risk and then measure the possible impact.     

Type of impacts

Impact generally falls under one of two categories, quantitative or qualitative. Quantitative impact can be measured, often in financial terms. For example, when IT systems fail, the quantitative impact to the business may be defined in terms of:

  • Salaries paid to an idle workforce that depends on an application
  • Lost sales because the web site is down
  • Cancelled flights due to a reservation system failure
  • Penalties and fines for missed deadlines

Qualitative impact refers to losses or consequences that are less tangible and difficult to assign an immediate monetary value. For example, when IT systems fail, the qualitative impact to an organization could be defined in terms of:

  • Loss of reputation or damage to the brand because the ATM network was down for a few hours
  • Political or public embarrassment resulting from an IT system failure during a high-profile product launch

Analyzing impact

The BIA process is by far the most arduous and time-consuming step of the business continuity planning process.

Trying to determine the financial losses resulting from an outage is not always simple, depending on the nature of an IT system failure. Using our earlier example, it might be relatively easy to quantify how many online sales were lost during an eight-hour outage based on average daily sales data. However, when IT systems supporting the customer database for a large retail chain fail, the immediate losses may be a lot harder to calculate because there are many dependencies between systems and business activities. That said, your best effort is required to determine the impact because the budget allocation to increase the availability or recoverability of a system is justified by the potential impact on the business.

The potential losses (or impact) will dictate how much money a company will spend to prevent or minimize them. In environments with hundreds of IT systems, not many companies would be willing to pay for the implementation of remote failover capabilities for all its systems, even if only a handful are subject to this type of recovery requirement.

This is where the concept of grouping business processes and supporting systems into tiers of criticality comes into play. For example, the most critical systems can be assigned to Tier 0, while Tier 3 would include the least critical systems, and tiers 1 and 2 are reserved for the remaining systems.

The next step consists of developing a chart where we can rate the most critical aspects of the business, like the one shown below. This list of impact areas will vary -- depending on the business -- but the concept is the same. Likewise, the criticality rating can vary: for example, some may prefer to use a more granular approach with metrics from 1 to 5 where 1 represents the highest impact, 5 the lowest and the processes with the lowest total scores become the most critical. There are many possible variations to this process but, again, the concept remains the same. The objective is to rate processes and the IT systems they depend on so we can assign criticality and recovery requirements.

Sample impact chart

Business Process





IT Systems Dependencies

MS Dynamics Great Plains Siebel Oracle

Other Process Depend.

Accounting     Sales


48 hours 8 hours 24 hours 24 hours


Last backup Last transaction Last backup 1 hour

Customer Impact (1-3)





Cash Flow Impact (1-3)





Additional Losses (1-3)





Legal / Liability (1-3)





Reputation (1-3)





SLA (1-3)





Health & Safety (1-3)





Loss of Opportunity (1-3)





Total Score





The outcome of a well-executed BIA should clearly identify the following:

  • Identify dependencies between IT systems and specific business processes.
  • The maximum IT systems outage the company can tolerate before incurring significant losses. This becomes the recovery time objective (RTO).
  • The maximum amount of business information (data) the company can tolerate to lose. This becomes the recovery point objective (RPO).
  • Potential losses or consequences resulting from an IT systems outage.
  • Criticality or priority rating of IT systems based on the business activity they support and the potential losses incurred when those systems are down.

Note that both the RTO and RPO are established in function of the impact chart score. The higher the impact usually means a shorter RTO and low tolerance to data loss means a short RPO.   

Ultimately, once the most critical business processes have been identified, the IT systems they depend on are also identified. Based on this criticality rating, combined with the risks and exposures identified during the risk assessment, we now have a much better understanding of what type of recovery strategy is required and how much we can afford to spend to prevent those losses. The high-risk and high-impact systems will have tighter recovery requirements and therefore require more advanced recovery or availability capabilities.

Pierre Dorion is the data center practice director and a senior consultant with Long View Systems Inc. in Phoenix, Ariz., specializing in the areas of business continuity and disaster recovery planning services and corporate data protection. Over the past 10 years, he has focused primarily on the development of recovery strategies, IT resilience and recoverability as well as data protection and availability engagements at the data center level.

Dig Deeper on Disaster recovery planning - management