A business impact analysis checklist: 10 common BIA mistakes

Here are the top ten mistakes IT managers make when performing BIAS. See what they are and how to avoid them in your environment.

Steven J. Ross

A business impact analysis (BIA) is central to the development of business continuity (BC) and disaster recovery (DR) plans. A BIA is a statement of requirements for recoverability, a hierarchy of priorities, and the value proposition to support senior management's investments in data backups, alternate facilities, duplicate equipment and other resources. It demonstrates an organization's vulnerabilities, and what needs to be done before a disaster to meet the needs of the business and what can be deferred until a disaster occurs.

Unfortunately, many people performing BIAs make mistakes. I know from experience; I've conducted more than 100 BIAs and I've made every mistake in the book. So I have compiled the top 10 things you should be aware of and avoid when conducting your business impact analysis.

The top 10 mistakes: A business impact analysis checklist

  1. Considering the impact of interrupted applications, not business functions: The driver of a business impact analysis is the business. The first question that needs to be addressed is what the impact would be on the entire organization if a business function could not be performed. The second question that should be addressed is which applications that function relies on.
  2. Considering applications in isolation: While business users may know which applications they rely on, they do not often know which other applications or infrastructure those applications rely on. When determining the relative importance of applications, the analyst needs to understand the totality of the IT environment: servers, storage, network, infrastructure and the portfolio of applications as a whole.
  3. Paying too little attention to financial impact: You shouldn't ask yourself, "If application X couldn't run, how much money would be lost?" It raises too many other questions such as: Could losses be made up when the system is recovered? Would an outage lose customers as well as sales? How much loss is attributable to a specific application? When performing a BIA, financial information is often collected and then isn't used when determining recovery requirements because it's too complicated. You should consider the P&L impact of an extended outage, as well as the capital and operating costs of reconstruction.
  4. Paying too much attention to financial impact: There are impacts other than financial loss that may be more important to senior management. The effect on reputation and customer retention may weigh more heavily on their minds. Moreover, many business managers don't fully understand how their function fits into their company's business model. So they attribute the totality of financial risk to their own applications rather than considering the entire business.
  5. Failing to distinguish enterprise applications: Some applications are more important than others because they serve the enterprise as a whole. Therefore, there is no one business manager who can state the overall importance of those applications. However, an application that serves a single business function, or that serves many functions in different ways may not be as readily noticed. There are some applications such as enterprise resource planning (ERP) and customer relationship management (CRM) systems whose impact is self-evident. But there are others (e.g., legal support, document management) that may go relatively unnoticed.
  6. Failing to recognize data center applications: Some applications do not have business users. These applications include the operating systems, database management systems and data center tools that enable business applications. It is easy to say that all of the infrastructure must be recovered before all applications, but should the operating system on an obscure server that performs analysis really be recovered before the credit, trading or inventory systems?
  7. Confusing a risk assessment with a business impact analysis: A risk assessment determines what could cause an outage; a business impact analysis shows the effects if one did occur. There have been too many unlikely events that have occurred in the recent years to confuse these terms. The issue lies in the resulting consequences of interruptions of varying durations, regardless of the causation.
  8. Confusing risk acceptance with a business impact analysis: If a business manager is willing to take the risk of an application's unavailability, that does not mean it's not necessary to determine the impact. Often, managers won't want to spend time on the BIA process, so they'll take the easy way out. However, this is a risky approach, and many managers don't realize the big risk they're taking. It is one thing for managers to accept the risk to their own applications, but it is quite another to put the entire company at risk.
  9. Pre-determining BIA results: Sometimes the result of an analysis seems obvious to business managers, so they automatically assume the answer without going through the BIA process. Assumptions may yield correct results 80% of the time, but that means they're incorrect 20% of the time. In other words, one out of every five business functions or applications is inaccurately analyzed. The impact may only become apparent when a disaster strikes, and by then it is too late.
  10. Backing into a BIA result: A business manager may choose to understate the financial, operational or reputational impacts of his or her applications being unavailable because of the perceived cost of recoverability. Of all the 10 mistakes listed here, this is the most insidious because it intentionally undermines the overall statement of recovery needs that a BIA is intended to produce. It is understandable that managers may be more concerned about budget today than an incident that may (or may not) occur in the future, but they are placing a potentially intolerable burden of risk on the enterprise.

Getting your business impact analysis right

Overall, you should perform BIAs with an open mind and follow the facts wherever they may lead. Existing preconceptions may be shattered, but if preconceptions were reliable there would be no need for a business impact analysis checklist at all. In far too many organizations, the so-called business impact analysis for information systems is performed in a quick meeting between a few IT managers.

An IT disaster recovery plan is a subset of a business continuity plan and the criticality of an application is dependent on the criticality of the business function(s) that rely on it. The business functions of any organization are complex and interdependent. In large companies, they may be so interwoven that understanding the relative impact of one versus another is a herculean labor. But it is a worthwhile effort, not only so that senior management can invest in recoverability but also for the insights it gives them into the complexities of the companies they manage.

About this author: Steven Ross is an Executive Principal of Risk Masters Inc. and holds certification as a Master Business Continuity Professional (MBCP). He is a specialist in business continuity management, crisis management and IT disaster recovery planning. He is editor of the multi-volume series, "e-Commerce Security," and author of several of the books in the series, including "e-Commerce Security: Business Continuity Planning."

Next Steps

Conducting a BIA from start to finish

Dig Deeper on Disaster recovery planning - management

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

The articles are very important
An interesting article that just re-emphasises the point; the Business Impact Analysis is to analyse the business; not IT systems. In my opinion the IT team should not conduct BIA's because their bias will be towards IT. A good Business Analyst or business manager should be used for the purpose together with a finance person to verify financial data. Another idea, keep the Risk guys away. Risk Management and Business Continuity Management are two different approaches to solve different issues.