We’re often asked about the Business Impact Analysis (BIA) process, a part of the Business Continuity lifecycle, and how that should be structured within an organization.
Over the next two episodes, we’ll take a look at the BIA, starting with the traditional business impact analysis process, followed by a look next week at the trend towards not doing the BIA at all.
In this episode of the Managing Uncertainty Podcast, Bryghtpath Principal & CEO Bryan Strawser and Senior Consultant Jennifer Otremba talk through the traditional business impact analysis process. Topics discussed include how to structure the BIA process, how to use the results, connections to the ISO 22301 and 22317 standards, and some of our lessons learned from conducting the BIA at multiple clients over the years.
Episode Transcript
Bryan Strawser: We’re going to put on our business continuity and disaster recovery hat today and talk about, I think a two-part podcast is what we’re talking about here. We’re going to start by talking about the traditional idea of the business impact analysis. What is the BIA, Jen?
Jen Otremba: That’s a good question. The BIA, or the Business Impact Analysis, to me it’s sort of just a process to help determine critical functions within a company and what the relationship is with each other, in Jen’s words.
Bryan Strawser: That’s a good plain English description of the BIA.
Jen Otremba: In Jen words, not the ISO definition, the Jen definition.
Bryan Strawser: ISO says in the 22301 standard that the business impact analysis is a formal end document and evaluation process for determining continuity and recovery priorities, objectives and targets.
Jen Otremba: Yeah, what I said.
Bryan Strawser: It goes on to say that this is really about understanding the organization and its context and the needs and expectations of interested parties in order to be able to select business continuity strategies, implement business continuity solutions and write business continuity plans using this data.
Jen Otremba: Yes.
Bryan Strawser: I like your simple explanation.
Jen Otremba: We’ve had to describe this to organizations-
Bryan Strawser: Many people.
Jen Otremba: … recently quite a bit, right?
Bryan Strawser: Yeah.
Jen Otremba: Because there is a lot of confusion as to what exactly do I need, how do I get there, and then what do I do with the information once I have it?
Bryan Strawser: In the traditional world of doing the BIA, the way that I would say business continuity has been done for many, many years, there’s kind of a multi-part process here that you’re starting with a risk assessment to understand the risks and threats to an organization. Through that conversation you determine through some mechanism the criticality of functions because companies have teams. Those teams perform functions or processes, depending on what term you want to use, and those processes are either critical or not. Companies define what is and not critical. For example, in the world that I grew up in with BC a function that needed to be recovered within 30 days was a critical function, everything else wasn’t. We have lots of definitions as to how you get there. We would typically do a survey or some type of mechanism in a tool like Archer or Fusion or LDRPS or something that allows us to capture enough detail to understand whether or not this process is critical or not.
Jen Otremba: Yes. If you’re not a huge organization it doesn’t need to be an expensive tool. It can be as simple as, like you said, a survey to determine what’s critical and why it’s critical. The company can set the definition of what makes it critical, what time line makes it critical. Like you said, you remember doing 30 days when you grew up doing this. It’s to determine your criticality, right?
Bryan Strawser: Right.
Jen Otremba: It could be two weeks depending on what it is.
Bryan Strawser: That’s right, or it could be a week.
Jen Otremba: Longer.
Bryan Strawser: It could be longer. The company sets this. You just need to define it, like, “Critical function to us means X.” Once you define that, then you conduct the business impact analysis on that team or function or division or department, whatever the organizational layer is that you’re going after. What do we do in that BIA process? What are seeking to understand?
Jen Otremba: Again, Jen’s definition here, which is not always the book answer, but essentially you’re asking yourself a series of questions. In this business unit you’re ultimately determining what makes it critical, and what upstream, downstream units may also be required to keep his function going.
Bryan Strawser: Right, is it dependent upon something, and is something dependent upon it?
Jen Otremba: Sometimes it’s based in a dollar figure, “Without this after a certain amount of time it’s going to cost the company 50 million dollars,” or something like that. It also will outline how many people you need to make this function work. How many facilities you need to make this function work. It sort of starts to outline all that you need to keep this critical function going. That’s Jen’s words. How’s that?
Bryan Strawser: Yeah, I think you’re on the right track. We should point this out, some companies or tools will separate the idea of what information goes in the plan and what information boes in the BIA. Often some of the things you describe like facilities and dependencies might just be in the plan as opposed to being in the BIA. In our mind it doesn’t really matter. You capture it in the place that makes the most sense for the processes that you’re using. What we’re really seeking here to understand is what is the impact of a disruption or outage to the function? What are the things that can make that outage happen? A lot of this for us is what’s the financial or regulatory or legal or reputational impact of being offline for an hour, two hours, four hours, eight hours, 12 hours, 24, a week, you set the timelines onto what you want to measure. That’s really what you’re going after, is what is the impact if this function is disrupted.
Often you’re also looking at what are the things that can cause that disruption where you’re mostly looking around loss of facility, loss of the team, loss of technology, loss of third party or vendor services, and what does that mean for the impact to that organization? Out of all of that you get to, “Hey, here’s my …” You can call it a recovery time objective, an RTO, you can call it a maximum allowable outage, an MAO. I don’t really care what you call it, but you’re aiming towards some metric that you’re going to use consistently across the organization to understand what that impact looks like and how quickly do you need to recover this thing, this particular process.
Jen Otremba: Once you get through that process with all the critical functions it’s kind of like a mind-blowing all of this information comes together. Sometimes you’re identifying things you didn’t realize existed, but everyone else knew, but maybe a certain team didn’t know. That certain team didn’t know that all of these other teams counted on them within 24 hours or two hours or four hours or whatever that looks like.
Bryan Strawser: Right. We often hear when talking about technology teams and you get into like a Wintel engineering team in a company that uses actor directory for everything, and usually you hear one of two answers. You hear the person that’s not cognizant of the real world which is, “Yeah, I just manage actor directory, and if it goes down no big deal,” which I heard recently. Or, you get the more mature answer we heard from a head of systems engineering recently, which was, “Yeah, so I’ve got two functions here that if they go down we are in a world of trouble, starting with actor directory. If that’s down we’ve got problems.” The second was Ping Fed. If that goes down we’ve got problems all because it’s tied to authentication, and, literally, if you can’t get into your computer, you can’t bet into an app, you can’t get into the internet. All these dependencies tied to that, which are all obvious to this individual, but not obviously to the business team who is like, “What’s Ping?”
Jen Otremba: I can work from home.
Bryan Strawser: “I can work from home,” and so you’re like, “You can’t because Ping’s down.” And they look at you and go, “What’s Ping?” This is great information that you get in the BIA process, or you pick up as a part of being involved in dealing with technology incidents. My experience is normally the business won’t know about this until you highlight it through a BIA and business continuity planning process.
Jen Otremba: It certainly is a tool that you can then use to education your leadership.
Bryan Strawser: Right.
Jen Otremba: Whether that be we need to put more time or energy or money into making sure this function works because here is what the impact is on the rest of the company. “Oh, we stop making money if we don’t have X, Y and Z,” often times helps sell that picture.
Bryan Strawser: Which is why it’s important to capture financial impact. If this function is offline, that function being offline can cost us money in that I need to spend because it’s offline, or I can’t do something that generates money, and, therefore, I’m going to lose money during this outage. I know the world I came from, POS authentication for credit card transactions and processing of check payments, it’s a big issue at point of sale because if our point of sale gateways and systems were down we couldn’t process, or we at least couldn’t authenticate. We did have some ways to process manually and then deal with it later when the systems came back up. I remember a Black Friday one year Visa went down at the retailer that we worked at for a brief period of time, and, man, people were freaking, even though we knew within a minute or two what had happened, and had it back up within a couple.
Jen Otremba: But a couple of minutes in that scenario can really cost.
Bryan Strawser: It felt like a long time. My boss was in the room breathing down my neck.
Jen Otremba: It’s also a reputational concern. Let’s say you have a company that uses that same type of system, but you have a vendor that provides that service to you, and that vendor has an issue. Customers don’t care if it’s the vendor. They’re there trying to buy from you, not the vendor. It’s also reputational concern.
Bryan Strawser: The BIA also helps you answer the question, particularly in a larger organization where you have multiple facilities and you’re probably in multiple cities, but it helps you answer the question when you get the phone call that, “Hey, Building four is down. We have a power outage, and it’s not going to be restored for 48 hours, and the generator’s not working, and we have no generator fuel.” What’s the impact of that? Your BIA can help you answer that question because you can go into your tool or your spread sheet or your records and say, “Well, here are the 10 organizations based in the building, and here’s the revenue loss and here’s the impact to reputation and here’s the community impact.” Whatever your criteria are that you’re capturing in the BIA you’ll have it because you’ve one this work and captured that data.
Jen Otremba: Absolutely. The other thing, actually, you can kind of point out with all of this, I was just thinking as you were talking, is the functions that are not as critical. You may have originally thought that they were the most critical functions, but, actually, it’s this function over here that’s what’s keeping the company going. It helps to identify that as well, so where to put the time and energy and money.
Bryan Strawser: Right, and how do you tier the recovery?
Jen Otremba: Exactly.
Bryan Strawser: Let’s go to our building four example, that building four is down, but I’m going to get back into building four in 48 hours, but only on the first floor. Who do I want to go take the spots on the first floor? Is it the team that’s already there, or am I going to prioritize differently based upon the BIA telling me, “Hey, these eight guys and women that are up on the eighth floor, these are the ones that are most important to get back up first.” Not to mention that, but what are their strategies, like, can they work remotely and all things that you’re capturing in their plan.
Jen Otremba: Right.
Bryan Strawser: Sorry, edit out that dead space there. Let’s talk about how to conduct the BIA. This really changes depending upon whether or not you have a tool, if you have software to be able to do this for you with you. Manually you can do this. We’ve done the BIAs often with an Excel spreadsheet that kind of outlines the questions that we want to ask. We create drop downs with information about the client’s facilities and technology platforms and position titles and things that you should be able to get an advance. That simplifies your data entry. It makes sure it’s consistent, which is very helpful for later analysis and use. Or, you can do this in a tool like Archer, Fusion, LDRPS or one of many different platforms that are out there.
Jen Otremba: Yeah, it would make life easier if you had that available to you.
Bryan Strawser: It makes it much easier.
Jen Otremba: Because you can pull reports and things like that from those tools, which makes it really easy to be able to really outline the things that you’re trying to outline here.
Bryan Strawser: Our typical process is to train the leaders and people from their team that will be doing the BIA, providing them the template or access to the tool, letting them complete the data entry, and doing some follow-up calls or making available some conference calls or onsite support where they can come and talk with you as they’re working through the process.
Jen Otremba: So they understand the questions that are being asked.
Bryan Strawser: Right, and we often get questions about interpreting some of the questions and what have you. Then give them a date for the data to be returned, and then we look and normalize the data. We review that back with them, and then you’re done in terms of the initial step with the BIA. After that you want to kind of level-set this with really their peers on the same operational team and then with the leaders of the organization to really say, “Hey, okay, the 80 things that your company does, 40 of them are critical. These 40 are ranked in the following ways in terms of how they get recovered and why. Like, why does that have to be recovered within an hour? Well, here’s the reasons why that we captured in the BIA.” “Oh, okay.” Or, “Well we argued this with the business, but the business disagreed, so we’ve left it as is.” Then the seniors they can go, “Well, that’s crap because they need to be recovered after these four or five other functions,” and you can realign this based upon executive priorities.
Jen Otremba: Right. The executive, then, buy-off at that point. The executives can review all the data that you present to them. Then at some point decisions will need to be made, like you said, ranking what will be recovered first, what functions. Then lastly I think would be the information sharing, right?
Bryan Strawser: Mm-hmm (affirmative).
Jen Otremba: Once you have all the information you’ve made decisions, you have plans as far as how to move forward and who to create the plans for, you do the information sharing.
Bryan Strawser: That’s our view on the traditional BIA. We’ll link and the show notes. We have a couple of blog posts describing why to do BIAs and what does a BIA look like and what is the BIA. I think we have a few other resources on the site, so we’ll link those in the show notes for you to take a look at. Then in next week’s episode we’re going to take a counter view here. I think we’re going to call this episode “To BIA or not to BIA. That is the question”. A little play off of Shakespeare, but the question we’re going to ask is, should you do the BIA? There’s a growing belief that perhaps the BIA is not the most effective way to build a BC program and there are some alternate paths to consider. We’ll explore those on next week’s episode. Thanks for listening.
