Archive for Business Impact Analysis

The Business Continuity Planner’s Job

Although this concept may prove frustrating for the business continuity planning professional, I suggest that our primary job is not to make sure the enterprise can recover critical processes in a timely manner following a business interruption crisis, but, rather, our primary job is to identify the risks and threats that could cause a business interruption event, the resulting impacts to the organization should those threats be realized and the options (and costs) of addressing these threats.  Now, there may be a subtle difference in the two sides of that statement and, you may need to re-read that sentence a couple of times to fully understand what I am suggesting, but I often see business continuity planners get frustrated because they cannot appreciate the difference.

I believe, that our first job as business continuity planning professionals is to provide senior management with the data and information that allows them to make an informed and intelligent decision on what to do based on this information.  If, senior management, armed with this information, decides to accept the risks and potential impacts – and, signs off on that strategy – so be it.  Every organization has its own risk acceptance, or risk adverse, personality and may make polar opposite decisions faced with the same risk and impact profile.

The worst thing that can happen to a business continuity planning professional, proving we did not do our job, is if a situation occurs and senior management is justified in saying, “No one ever told me …

… that a disaster in our data center would take us out of business for months”, or

… that a fire in our call center in Anytown would take down all our customer service capability”, or

… that our primary distribution center was located in a flood plain”, or


If we are in a position to say, “No, we told you, but you elected not to invest the funds necessary to mitigate the risk or position us to recover from it”, then, although we may still be the scapegoat, we can feel satisfied we did our job.

Now, once we inform management of the risks, potential impacts and various options for addressing the situations, our job then becomes to implement, document, test and exercise the strategies and solutions they have approved.  Hopefully, we can influence management to take the course we, as professionals, believe they should follow.  If not, then, rather than just complain that management doesn’t understand, we either need to gather more information to influence a different choice or, do our best to implement and document the strategies management elects to employ.

It can be frustrating working for an organization that is willing to accept risks and bet against the chance that a business interruption event will occur, but our job is primarily to make sure they are making these decisions based on all the facts and understanding of what their decisions could mean should a disaster occur.

The Business Impact Analysis (BIA)

I know this is a well known concept and BIAs are part of almost every Business Continuity Program, but I happen to think that many, if not most, people get this wrong – just a little.

Many practitioners, in my way of thinking, overcomplicate or overextend what the BIA is supposed to include and result in.  In many instances, the BIA is performed to establish the equally well known recovery objectives, the Recovery Time Objective (RTO) and Recovery Point Objective (RPO).

One of the issues that I have is what the RTO measures – is it the recovery time objective for a business process or the recovery time objective for an application or IT infrastructure?  Often, people use it for both and I think that can confuse things.  The RTO grew up as a disaster recovery, implying technology recovery, measurement and I think that is where it should stay.  The BIA, by definition does not measure technology recovery objectives it measures exactly what the words say – business objectives.

So let’s back up a bit.  What does (should) the BIA do for us?

The BIA measures and records the “impact” on an organization should a “business” process cease to operate.

The BIA answers questions such as:

What is the impact to our company if we cannot settle trades?  Or, what is the impact if we cannot provide customer service?  Or, if we cannot sell tickets.  Or, if we cannot pick raw materials from our inventory warehouse? …

The BIA measures the impact on WHAT you do, not HOW you do it.  The HOW questions come later in the methodology.  Most companies are not in the business of running computers.  They are in the business of providing financial services, or selling insurance, or flying airplanes, or making consumer goods, …  Now, most also rely on technology and business applications to support what they do but these tools are recovery requirements and are looked at downstream in our analysis.

Once we know the impacts of not performing discreet business processes, we can determine how long the company can survive before these impacts become so severe that they jeopardize the solvency of the organization or pass some other pre-established pain threshold.  To avoid confusion with RTOs, I like to call this the Maximum Acceptable Downtime – now you may say I am MAD, but that’s the result of my BIAs.

And that ends the Business Impact Analysis.

Now, focusing on those business processes with the most demanding MADs we can start looking at how we perform those processes; start analyzing the required technology to support those processes; and, start assigning RTOs and RPOs.  This, we might call our Technology Impact Analysis, although I don’t see too many people using that term.

Many times, MADs and RTOs for applications that support that business process are equal, but, then again, many times they are not.

For example:

In conducting a BIA, a trading company may discover that they must be able to execute a commodity trade within 4 hours of a business interruption, i.e. the MAD = 4 hrs.

In defining how they trade commodities, they identify the Commodity Trading Platform (CTP) as an application that supports this activity.  However, in evaluating contingencies, they decide that they could actually execute trades manually, by filling out a manual trade blotter, like the old days, and enter them into the system within 24 hours of the trade.  So, as long as they have a telephone and a pad of paper they can, with great inconvenience, execute trades.  So, the RTO for the phones might be 4 Hrs, but the RTO for the supporting application, the Commodity Trading Platform is 24 Hrs.

Now, if you want to argue that you get that, but in order to not keep going back to your business partners over and over again in the planning process you collect BIA, Recovery Requirements and Technology Objectives information all in the same interview, I can accept that.  But, I think it is important to differentiate the results of the BIA, business process MADs, from the results of the Recovery Requirements Analysis and subsequent disaster recovery requirements.

Even though most planning professionals preach that there is a difference between business continuity and disaster recovery, I think that the distinction often gets blurred in the execution of our methodology.

Just one man’s opinion, for what it is worth.

Is a Business Impact Analysis Always Needed?

Okay, in answering the question posed in the title of this blog, I am ready to commit heresy.  I have lost this argument with many an auditor and probably won’t convince too many of you reading this, but I suggest that there are some situations where you do not need to perform a formal Business Impact Analysis (BIA).  Did I just lose your respect?

First, let’s look at what the BIA does for us.  Quite obviously, it measures the impact on the organization should a business process cease to function, for whatever reason.  Okay, why do we need to know that?  We want to know the impacts on the organization so we can identify those business processes that have the most severe impact (or impacts that exceed a pre-defined pain threshold) to include in our business continuity program.  The BIA also helps us establish Recovery Time Objectives and Recovery Point Objectives (also, I think the RPOs really come later in the process, but that will be the topic of a future blog article).

So, the BIA provides the statistical and intellectual support for our Critical Business Processes and associated recovery objectives – great.  But, what if those are given to us?

I have witnessed on more than one occasion, after a long, in depth BIA, the findings are presented to the Executive Committee only to have them respond, in so many words, “I don’t care what your BIA says, what we need to do is recover these processes in this timeframe.”

Even worse than that, I have personally been involved with assisting a business in their recovery efforts following the World Trade Center bombing in 1993, which occurred on a Friday afternoon, where the CEO says, “I don’t care what we planned for; we will be back in full operation with 100% of our workforce in place by Monday morning.”  The Business Continuity Manager lamented that that was not what they planned for as their BIA indicated they could survive with 25% of their workforce supporting about 50% of their business processes.  Needless to say, a mad scramble to now meet management’s expectation was underway.  We had a fun weekend – NOT.

Like I said, I have had arguments with auditors who insist that they need to see evidence of a formal BIA and I could not get them to see the waste in time when the Executive Team already established the program recovery objectives.

Now, on most occasions, when I go into an organization and explain that their business continuity program should ensure that their mission critical business processes are recovered in a timeframe to ensure losses do not exceed an acceptable level so as to jeopardize the solvency of their organization, I am asked how we define those.  And, of course, the answer is to conduct a BIA.

But, in those situations where I am told, create a program that allows us to recover very specific business processes within x hours, I ask you again, Is a Business Impact Analysis Needed?