• United States




Business Continuity Event Planning: Business Impact Analysis (BIA)

Oct 29, 20087 mins
Business Continuity

This is the second of two posts examining the prepare step in building and managing a BCEM (Business Continuity Event Management) plan.  In the previous post, we saw how understanding the business is critical to a business impact mitigation and process recovery.  The activities discussed produce input for the business impact analysis, including:

  • Business objectives
  • Regulatory environment
  • Critical processes
  • Threats
  • Process interdependencies
  • Process vulnerabilities

Using this information, we can plan for inevitable process failures.  The BIA uses business impact information and the probability of specific business continuity events to calculate levels of business risk.  The end result of a BIA is a picture of the BCEM threat, vulnerability, mitigation, and response framework and how that framework reduces risk to levels acceptable to management.

Instead of segregating the BIA from risk assessment and mitigation activities, I integrated them into an overall business continuity risk management process.  The result is a continuous, risk-centric approach to BCEM preparation.

What is Business Impact?

Business impact is a measure of how an organization might be affected by a process failure, caused by technology, premise, or human resource issues.  Impact is classified as either revenue or non-revenue.Revenue impact includes the full or partial failure of any process which produces, collects, or processes business income.  Examples include:

  • Accounts receivable systems
  • Availability of revenue generating facilities
  • Availability of sales, service or product delivery, or revenue collection employees
  • Any other process whose failure diminishes the organization’s ability to fund operations, pay its bills, or make payroll

Non-revenue impact is caused by challenges that do not directly affect short term realization of revenue, including:

  • Payroll systems
  • Availability of employees not directly related to revenue generation, such as human resources
  • Public perception
  • Regulatory compliance
  • Environmental damage

Although causes of non-revenue impact might not result in immediate financial losses, some could result in long term financial damage through loss of investor or customer good will.

Business impact can be calculated using either a qualitative or a quantitative approach.  Qualitative analysis depends on the experience of employees and consultants to arrive at risk scores.  The results of the quantitative approach are estimates of potential dollar losses based on known costs or revenue streams.  Most organizations don’t understand process interruption costs well enough to use quantitative BIA methods.  So we’ll focus on a qualitative approach in this article. 


The BIA, as presented in this series, is a risk management tool.  A very simple formula depicts the relationship between business impact and risk.

Risk = Probability of Occurrence * Business Impact

Probability of occurrence is calculated using the threat and vulnerability analysis performed in the previous step, understanding the business.  It’s represented as the number of occurrences expected in a single year.  This is known as the Annual Rate of Occurrence.

For example, if information about known threats, vulnerabilities, and actual events lead an analyst to believe a threat will cause a weakness to interrupt business operations once every four years, the probability of occurrence is .25. 

During a qualitative BIA, the analyst uses probability of occurrence (PO) and business impact (BI) to arrive at a risk score.  The risk score is a measure of the amount of damage resulting from one or more failed critical processes.   

The BIA Process

Figure 1 depicts BIA phases—the Prepare step in the BCEM Planning cycle—at a high level.

Figure 1

 The first phase, Understand the Business, was covered in the last post.  In the remaining sections of this article, we’ll step through the next three.

Calculate MTDs

MTD (Maximum Tolerable Downtime) is the maximum time a critical process can be down, or hindered in some way, without irreparable harm to the business.  It’s typically calculated as part of a BIA and is used during risk calculations.

At a high level, a BIA begins with identifying critical processes, describes resources necessary to maintain them, calculates the financial or PR impact on the business if the process fails, and determines process MTD.  Other processes which depend on the failed process’ output also suffer.  So a BIA must also describe the interrelationship between all critical processes and factor this into their MTDs.

A process MTD is an adjustable value, affected by several variables.  For more information on MTDs and how to calculate them, or extend recovery periods, see Calculating MTD based on impact mitigation and recovery capabilities.

Perform FMEA

The FMEA (Failure Modes and Effects Analysis) was developed to predict and mitigate possible failures in manufacturing processes.  Unlike root cause analysis, which takes place following an event, FMEA activities precede system or process implementation.  They help prepare teams for inevitable failures, mitigating business impact.  This makes FMEA a good fit for BCEM planning.

The best way to describe FMEA is stepping through a commonly used tool.  See Figure 2.  (Download the FMEA template.)

  • Process Description.  This column contains the name of a critical process identified during the earlier preparation activities.
  • Potential Failure Mode.  Each process usually consists of two or more components subject to failure.  For example, a cash collection process might require an Accounts Receivable application and supporting infrastructure as well as AR clerks to operate it.  All components making up a critical process should be listed in this column.
  • Potential Effects of Failure.  This is a description of the business impact of a failed component. 

    • SEV.  This column is a numeric severity rating of the failure described in the previous column.  The downloadable template includes a worksheet with a sample severity table listing rankings from 1 through 10.
  • Potential Causes.  Each failure might have several causes.  Each cause should be listed in this column. 
  • PROB.  This column represents a PO value for each potential cause.  Instead of using a fractional value, FMEA uses a score from 1 to 10, as shown in the Probability of Occurrence worksheet included in the template.
  • Current Controls.  For each cause, there should be one or more controls to prevent or detect potential failure.  These controls are listed in this column and should include response plans designed to recover within related MTDs.
  • DET.  This column contains a detectability score.  As depicted in the Detectability worksheet included in the template, the score is also selected from values from 1 through 10, based on the organization’s ability to detect potential problems.
  • RPN.  RPN (Risk Priority Number) is a value resulting from the formula SEV * PROB * DET.  The higher the number, the greater the risk.  Management should establish a threshold representing acceptable risk.  Any RPN over that threshold requires mitigation.

    Mitigate Risk

Once failure modes with RPNs exceeding the acceptable risk threshold are identified and prioritized, mitigation steps are scheduled.  The FMEA template provides columns for action plan tasks, including Recommended Actions and Responsibility, Target Completion Date, and Action Taken.  An additional set of RPN values are provided to recalculate risk, following action plan task completion.  If the RPN is still too high, additional mitigation steps are identified, executed, and the resulting RPN calculated.  This process continues until the RPN drops below the acceptable risk threshold or management accepts the increased risk.

The final word

BIA is a continuous process, with repeated analysis when new systems are implemented, major upgrades occur, or processes change.  The output of the BCEM BIA includes not only useful insight into business continuity event risk and ways to mitigate it.  It also includes documented controls and event response processes ensuring rapid detection and effective recovery of failed process components.

For more information on FMEA, see Failure Mode and Effects Analysis.


Tom Olzak is an information security researcher and an IT professional with more than 34 years of experience in programming, network engineering and security. He has an MBA and a CISSP certification. He is an online instructor for the University of Phoenix, facilitating 400-level security classes.

Tom has held positions as an IS director, director of infrastructure engineering, director of information security and programming manager at a variety of manufacturing, healthcare and distribution companies. Before entering the private sector, he served 10 years in the U.S. Army Military Police, with four years as a military police investigator.

Tom has written three books: Just Enough Security, Microsoft Virtualization, and Enterprise Security: A Practitioner's Guide. He is also the author of various papers on security management and has been a blogger for, TechRepublic, and Tom Olzak on Security.

The opinions expressed in this blog are those of Tom Olzak and do not necessarily represent those of IDG Communications Inc. or its parent, subsidiary or affiliated companies.