Tag Archive for business impact analysis

Business Objectives vs Business Continuity Objectives – The Missing Step

This blog article talks about a step in the Business Continuity Planning (BCP) Methodology that I think is missing – and, I happen to think it is a pretty important step.

One of the greatest challenges in the BCP methodology is in establishing the program’s recovery objectives.  Whether you label them as Maximum Acceptable Downtime (MAD); Recovery Time and Recovery Point Objectives (RTO & RPO); or some other creative anagram unique to your process, these program benchmarks are usually arrived at through a Business Impact Analysis (BIA) process or, at least, through some survey/interview with business managers and subject matter experts to establish what the critical business processes are; what timeframes they must be recovered; and what resources must be available in certain timeframes to enable our continuity or recovery of those processes.  Does this sound familiar?  I’m I right, so far?

But – you knew there was going to be a but – to achieve what end?  I mean, we do a great job defining business continuity objectives, but do we do so against established business objectives?

I always thought that the savvy business manager, when asked to complete a BIA questionnaire would ask the question, “What is Senior Management expecting me to achieve during the business interruption period?”  Sometimes, I think, we get close.  Many times I hear business continuity planning professionals say that the objective is to “survive” the disaster or “keep the company solvent”.  But do we ever define what that means – in business objective terms?

So, forget about operating in disaster situations for a second.  Just think about business as usual objectives.  Most every company and most every department within each company has established business or performance objectives.  There are defined revenue targets, income objectives, margin targets, production objectives, etc.  There are expected number of widgets to produce per week; sales targets; number of calls handled per hour; items sold; and so on and so on.

What I would want to know, if I were the business manager being asked what my critical processes are and how long can we go without performing those processes, is:  What adjustments are being made to my performance objectives during this incident you are asking me to plan for?  Am I expected to still achieve my revenue target, sales target, income target, margin targets?  Am I still being measured against growth?  How many widgets per day am I expected to still crank out?  If you can tell me what my management is expecting me to produce during this contingency period, I can then tell you what I need to do, when I need to do it and what I need to get it done.

Seems to me, we miss that step.  We make middle management guess at what our business targets are.  And, furthermore, we never ensure that their guesses are consistent with one another.  Each individual manager who completes the BIA makes their own assumptions about what the overall business objectives are during a business interruption event.  Seems a bit risky to me.

I understand why and how this happens.  It is primarily because middle management is more accessible in our planning process.  It is much easier to include middle management in the planning process, feed them the BIA questions and get them to assign MADs, RTOs and RPOs than it is to include Senior Management in the process.  But – there’s that damn word again – how can we really define viable business continuity objectives if we don’t first know our business objectives during time of an event?

I wonder what would happen if we tried?  I wonder … what if you posed that question to upper management?  What if we added that step in our BCP Methodology:  Define adjusted business objectives that must be achieved during a serious business interruption event.  IN BUSINESS TERMS – not in BCP terms.  Interesting.

Anyway, just a thought.  What do you think?

The BIA Insult

So, I came across this quote the other day that someone was using in a presentation about the importance of conducting a Business Impact Analysis (BIA):

“A business continuity plan that is not predicated on or guided by the results of a business impact analysis (BIA) is, at best, guesswork, is incomplete, and may not function as it should during an actual recovery.”


I understand what they mean and I appreciate this message given to business continuity planners, but, I would hesitate saying this in a board room.  It may not be wise suggesting to the CEO and other senior executives that they do not know their business well enough to tell you what is important to them and what business processes are necessary to keep their organization solvent.

I have long since been of the opinion that business continuity planners have become victims of our own methodology.  I think many of us have lost sight of the why’s and wherefores of what we do and have become too caught up in the whats and how we do things.  And, I think, the BIA is a prime example of this.

Ultimately, why do we conduct a BIA?

I suggest that we perform a BIA to establish the objectives for our Business Continuity program.  We gather and analyze the impacts of a business interruption in terms of financial impacts, reputational impacts, operational impacts, legal and regulatory impacts and other impacts unique to our company or industry.  Armed with this measurable and intangible information, we can make an educated and informed decision about what business processes we need to continue – and, in what timeframe – to minimize our losses and keep the organization solvent following some sort of devastating business interruption event.

I like to break down the standard Business Continuity Methodology into the Strategic Planning Phases and the Tactical Planning Phases.  The Strategic Planning Phases consists of the Risk Analysis, Business Impact Analysis, Recovery Requirements Analysis and Cost Benefits Analysis of viable solutions.  The Strategic Planning part of the methodology helps us define “what” our business continuity plan should achieve.  The Tactical Planning Phases of the methodology define “how” we achieve our objectives.  This includes, implementing the chosen solutions and documenting the policies, plans and procedures.

But, I don’t believe the Business Continuity Planner is always needed to define the Strategy.  I think, in some instances, the “strategy” can be given to us by the CEO, board or other executive management team members.

What if the CEO told you what business processes they want to continue, in what time frames?  Are you going to tell him/her that that would be creating a BCP based, at best, on guesswork?

I know that the methodologies say we MUST CONDUCT a BIA.  But, I think that that requirement is a little bit tangled up.  I think it is absolutely correct to say, before you can  successfully implement a viable and effective business continuity plan you must establish your recovery time and recovery point objectives; you must identify and categorize your business processes in terms of criticality and importance to the sustainability of the organization and the ability to satisfy the corporate mission; you must know the dependencies and requirements that support those critical processes to ensure a complete and holistic recovery solution – but, I am not sure a BIA is always what is needed to get these “strategic” parameters.

Yes, I have been in many a situation where the leadership team was not comfortable in establishing these objectives without the support of information gathered and analyzed through an in-depth BIA.  I have also seen many a business continuity planning team chastised for spending months on gathering and analyzing information simply to conclude in telling management teams what they already knew.  And, I have seen business continuity programs fail at time of an event because they were predicated on the findings from a BIA that were never verified and matched against management’s expectations, which were significantly different from what the information gathered suggested.

Now, I am not against BIAs.  I have made a nice living by conducting many a BIA over the past 20 years, and I do believe they are valuable and necessary tools – just not in every case.    I caution business continuity planners not to become so married to the methodology that you lose sight of what the objectives are for each methodology component.  If the objective of a BIA is to establish the continuity and recovery objectives of your business continuity program and the executive team in your company knows and are willing to sign off on recovery and continuity objectives that are given to you – do you really need to conduct the BIA?

In any case, I don’ think I would ever suggest that a business continuity plan not based on the findings from a BIA is guesswork, especially if the guesses are coming from the Executive Management Team.  I just know that if you came into my company and told me that a team of business continuity planning specialists are needed to identify what our critical processes are, I would be showing you to the front door.

Critical Data: Don’t Overlook the Hardcopy

I know we like to think we now work in a paperless society, but the fact is, we do not.  There are still plenty of industries and processes that rely on hardcopy documentation for historical records and in support of daily operations.  Business Continuity and Disaster Recovery programs often overlook these vital records as they focus on technology and electronic medium – I caution you not to fall into this same trap.

In know this to be true, especially in airlines, medical and educational organizations as well as in some financial services and other industries. 

For example:

Airlines are required to maintain and have access to all mechanical and maintenance records for each and every aircraft that they fly.  In many instances maintenance initiatives issued by various agencies are printed and given to the mechanics and engineers who then make handwritten notations and sign off on the printed form.  These printed forms, with their notations, become the official record of the maintenance activity in compliance with the initiative.  Should this physical, hardcopy record be destroyed or lost, the plane (or an entire fleet of planes) will have to be grounded until the maintenance check is performed once again and a new record created.  Some airlines maintain these records in a single location and do not scan or digitally record the information (keeping costs down, you know).  Should the facility housing these documents go up in smoke, it could take months or longer to recreate the audit trail for those planes – which, by law, must be grounded until proof that all the maintenance initiatives have been completed.

Many medical offices maintain a slew of forms and doctor reports in handwritten form.  Just notice all the filing cabinets up and down the halls in your doctor’s office.  These records are seldom scanned or stored electronically and are susceptible to numerous risks and threats.  The same is true for school records and other information gathered in handwritten forms.

Financial services firms and brokerages still house plenty of hardcopy documents in the form of payment instructions and customer documentation that could cause plenty of financial exposure and compliance irregularities if lost or destroyed.

For those of you who think that we operate in a paperless society, just take a look around and count the number of filing cabinets still in use.  What do you suppose is kept in all this space?  And, what would be the cost or impact to the organization if they were permanently destroyed?

Now, I am not saying this is true in every environment.  Certainly there are many, many offices and industries that truly have no exposure to hardcopy documentation and information.  I am just suggesting that your risk analyses, impact analyses and recovery requirements analyses do not simply overlook this potentially critical information base and include consideration of this potentially risky business practice.

Backing up or electronically scanning and storing hardcopy documentation, especially historical documentation, may be something your organization needs to look into.  There are plenty of vendors that can help you achieve this end.

Recovery Time Objectives: The Bigger Picture

A few of you didn’t take kindly to a blog I wrote a while back that suggested some of us business continuity planners have fallen victims to our own methodology.  Well, get ready to be offended once again.

This time, I want to take a look at the Business Impact Analysis (BIA) process and how we establish Recovery Time Objectives (RTO) – be they for business functions or software and applications.

In this case, I think we have fallen victims to our questionnaires.  Now, of course, some questionnaires are much more detailed and better than others, but I think they all fail from the problem that we do not put our questions in perspective of the bigger picture.  Ultimately, these questionnaires come down to the question of, “How long can we go without … doing something, or running something?”  Like I said, some questionnaires do a pretty good job of also gathering the justification for the ultimate answer, but…

I think the savvy business manager is the one who everyone else thinks is a pain in the asking.  The savvy business manager will stop short of answering these questions until he or she knows what the corporate position is on business targets during a crisis.  I would resist answering these questions until I knew what the Executive Teams’ expectations were for my department.

In other words, I would want to know; During a crisis…

  • Are our revenue targets adjusted?
  • Are profit targets adjusted?
  • Are margin targets adjusted?
  • Or, whatever business metrics I am measured against – are they adjusted?

I think most BIAs start and end with middle management answering individual BIA questionnaires, when, in fact, they should start with Executive Management establishing a Crisis Management Business Plan establishing the acceptable business targets to be achieved during a crisis.  Armed with that information, middle management has a more realistic shot at providing valid answers to our questionnaire.  Right now, every business manager is making their own assumptions about what Senior Management is expecting and these are likely not consistent across the board.

Furthermore, I think most planners simply accept the BIA answers provided with little push back.  Look, I’ve been a planner for a long time – I know exactly how easy it is to be so excited just to get any answers back that you do not dare challenge the results.  But, how often have you seen situations where business managers say they cannot be down for more than 4 hrs and yet close the entire office for a day or more during a snow storm?  Or, there is a function performed by 3 staff members and at time of crisis they say they need all three to be up and running in 4 hours – you mean none of these people ever take a vacation?  Again, it goes back to the original problem – it all depends what they think they need to achieve during a crisis.

Now before you jump down my throat – I do get that during a crisis you may not be functioning the same as normal.  You may be doing some things manually, requiring more labor.  I am just suggesting that sometimes we need to push back a little and have the managers support their answers and make sure they have thought things through logically.

Now on the opposite side of the spectrum, I was working for Comdisco during the World Trade Center bombing in 1993 and I worked very closely with two financial services firm recovering from that event.  On the Monday following the bombing – the first business day following the event – these companies experienced a call and transaction volume almost 10 X their normal volume!  So they, in fact, had some functions in which they really needed more than 100% of the workforce recovered.  I think, as planners, we may need to also push back on some departments to make sure they have taken into consideration the possible changes in work flow and volumes, given the fact that they had a disaster.  Insurance companies are just one example of organizations in which the disaster itself could be a catalyst for increased work activity.

It just seems to me that sometimes, and I don’t mean everyone does this, but sometimes, the BIA really simply becomes a Business Impact information gathering tool and we forget to do that “A” part – we forget to analyze the answers provided.

So, in summary, I think we can sometimes help the process along if we first get Senior Management to establish adjusted business targets for operations during crisis before asking middle management how long they can be down; and, I think we could do a better job challenging some of the answers we get back to our, sometimes, ambiguous questions. 

Okay, there you go, now let me have it and tell me why I’m wrong.

Business Continuity Planning: Have We Fallen Victims to our own Methodology?

I understand the importance of all the phases of the typical Business Continuity Planning Methodology.  I know the value of and why we conduct Business Impact Analyses (BIA) and Risk Analyses.  I understand the benefits and process for defining Recovery Time Objectives and Recovery Point Objectives.  I appreciate the need for defining Recovery Requirements and know the value of identifying different Recovery Solutions and conducting Cost/Benefit Analysis to evaluate and select the best alternatives.

I get it, really, I do.  I have been following this recipe for years (don’t ask how many) and have made a living at convincing clients they need all of this stuff.  And, I believe that they do … eventually.  I also believe, however, that we sometimes fall victims to our own methodology and sometimes lose sight of what it is our clients need, at this point in time.

I have witnessed myself, senior management teams getting frustrated because teams of consultants had been working for months on “The Analysis Phase” of business continuity planning and all they were wanting to learn was who was going to call them at two in the morning when a disaster occurs.

Sometimes I think we get so caught up in the business continuity planning aspect of things that we forget to first implement a baseline emergency response plan that addresses the crisis management components of the program.  After all, we need crisis management with or without a comprehensive business continuity capability.

Don’t get me wrong – we need to implement the BCP Methodology and all of its bells and whistles.  But I think we sometimes get so caught up in planning the menu, determining the best foods to eat, evaluating the nutrition content, balancing the diet and so on and so forth, while our patient starves to death waiting for some food.

Baby steps.

I think we serve our clients (internal or external) best by first documenting the imperfect programs in place today, even if the strategy is to figure it out at time of disaster.  If we can at least put together a baseline plan that includes a communication process, notification and escalation procedure and crisis management framework that gets the right people together to “figure things out” – we can at least ensure the patient is eating something while we design and implement the perfect meal plan.

Does any of this make sense?  I simply wish to suggest, that we do not blindly follow an academic approach to the planning process without first understanding what the patient needs.  Stop the bleeding before designing the perfect health care program.  To do that, we need to find the bleeding.  Rather than trying to explain the methodology – first ask, “What are you looking for your Business Continuity Program to do for you?”  You might be surprised by the answer.

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?