Hi, this is Justifying Business Continuity. I'm Richard Barr, and I'm here to help you explain business continuity to your board and employees. We need to justify it; justify the cost, justify the time, and justify the resources.

In this short workshop we’re going to have five different sections. It's a dangerous world, risks and threats. We're going to start to delve into the external threats that different types of risks that you face. Next section, what is business continuity? A lot of people confuse business continuity for disaster recovery, for business as normal. What we're going to do is look at business continuity.

In the third section we'll do some basic definitions. A lot of jargon is thrown around, but after we go ahead and look at the risks and threats and understand what business continuity is, we need to put some logic, some understanding to all the jargon that's thrown around. So we'll look at some basic definitions to do so.

Once we've done those three sections, we'll be able to ask a question and hopefully answer that question. Why is business continuity critical? Do we need business continuity? The pat answer is yes, but why? And we're going to answer that here. Make use of it going forward so that you can justify to your board and employees a B.C.M. or Business Continuity Management Program which is our last section within this workshop, justification for a Business Continuity Management Program.

In this section we'll be able to look at different methodologies for justification. Take what you want, build your own presentations for the board and other senior staff, and hopefully the amount of information you garnered from this particular workshop will help you succeed in getting that ever critical buy-in from the important parties. All right. Let's get started.

Yes, indeed, it is a dangerous world out there, lots of risks and threats. You can see that with our tornadoes sweeping around. Nope, this isn't Kansas, and it isn't the Wizard of Oz, it is near your data processing site. It is a tornado coming through to your branch offices. It's a whirlwind of trouble entering your business which is why we're going to have business continuity in place when that happens.

Now let me ask you a question. What is risk? What is risk? Can you define it? Now obviously the dictionary definition is fine. I'm not going to tell you that it isn't. It's the possibility of loss, injury, death, or disease, but for our need that's too general. We need to go into a deeper understanding of what is operations risk. Those are the things that affect our business. Those are the things that affect our processes and our operations, the risk of loss resulting from inadequate or failed internal processes, people, and systems or from external events.

Those are the things that we start looking at when we focus business continuity. The broad areas of risk, of course, that a Business Continuity Program should encompass are those environmental risk factors within your geographies. If you're a worldwide organization, you have different environmental risk factors in different areas. If you're a localized firm, you'll have a much greater concentration of risk of a specific type or nature. They are including, but not limited to, your systems, your location, and changes within the environment itself where you're sitting.

Of course, your industry, business organization units are critical to the processes and interdependencies. So now what is that critical process chain that you're looking at? What are the interdependencies within the different business units that your organization faces? Those have to be understood if we're going to create a business continuity program dealing with risk. Technology, of course, is very important, like your body has a spine supporting it, allowing for your limbs to move, technology allows for your organization to move. It supports your business. Now unless you're a technology provider, technology is not your business, but without it you'd find it very difficult to run your organization's business.

Of course, your business policies and procedures, the policies and procedures as set out by your board of directors and your senior management, it's very important to understand how those work within each of the business units, within the interrelationships of the business units. You are going to need to take those into account when we build a Business Continuity Management program or B.C.M.

Threats, of course, are plentiful, internal and external. And I'm not going to be exhaustive in my list, but just to give you an idea, we have malicious activity, such as fraud, theft, blackmail, sabotage, terrorism, sadly, and those are just examples. Natural disasters, you'll notice earthquake, fires, storms, floods.

You'll notice interestingly enough I have two, or possibly one, that really aren't natural disaster, but we put them here for a specific reason, those being air contaminants which could be natural, such as a volcano and volcanic ash and hazardous chemical spill which really is manmade. But because of the area coverage of something like that, it's a wide area coverage at times, we're going to put it there under natural disasters just to give you some thought provoking ideas about what are the results of these particular disasters. And that is, they're a wider area rather than a limited fire in a small building because someone smoked in the back room, was smoking a cigarette and shouldn't be, so just to give you an idea.

Of course, there are technical disasters too. What you may not even notice, like you do those pictures on the right, those are all very dramatic but communications failures may not even be physically seen. It's something that pops up on you, and all of a sudden you become aware of it after the fact if you're not immediately talking on the phone, for example. Power failures, equipment, software failures, transportation system disruption could occur without you noticing it right away. So those technical disasters are still very important and are still threats to be looked at.

Now in addition to that, of course, are things to be concerned with, interdependencies. Interdependencies, of course, how are the different parts of your organization related? How do you communicate with each other? How does the information flow? How do the orders flow? How does the servicing of the client flow? All the interdependencies can, indeed, become affected or create the failure where you need to enact business continuity. It's a critical nature, very important. It's necessary for you to design those redundancies that allow for no single point of failure.

We'll talk about single point of failure in a moment. It's very important that you look at effective backups, voice data, for power. Back in the '70s, '80s, there were actually not one but two failures on the part of N.A.S.D.A.Q. Exchange. The exchange in New York, N.A.S.D.A.Q. where it had a single power line into the exchange feeding it with electricity. That power line went down, and there was no redundancy, so the exchange had to close while they fixed the power line.

Now it sounds kind of basic to say, "Well, power line down, we don't worry about it because we built it underground, not necessarily up in the trees. We built some safety features." But the cause of the N.A.S.D.A.Q. exchange's power failure was that a squirrel ate through the power lines. So something that couldn't be perceived but happened, happened twice. It was only after the second failure that that the N.A.S.D.A.Q. built a second redundant power line into the exchange.

So that was some years ago, I admit. Of course, the egg on their face has been cleaned off since, but it just points out how important it is to take into account the unexpected such as a squirrel going through the power cable. Now don't feel too horrible about it, the squirrel, actually it was two squirrels, paid the ultimate price. They were electrocuted for their crimes. So each squirrel died of electrocution, not in a little electric chair. Don't worry, but under their own doing, and the exchange has since learned better.

In terms of that single point of failure that we point out with the power, it can also exist with telecommunications unless we build in the redundancies. Remember risk resides within the public network sometimes. We don't always get a choice in terms of that because they're outside your control; however, you can in some instances build in redundancy, feeding in and out of your organization's facilities where it's important. So you need to be proactive in establishing a diversity in your communications and your power where needed.

As, of course, technology modernizes as it advances, as it evolves, you'll notice here the pictures on the right to help along with that. You also need to take that into account with your business continuity practices as well. Then there are, of course, third-party providers. You do outsource some of you, and you do have key suppliers and business partners. So reliance on these third-party providers may expose your organization to points of failure that you hadn't taken into account. That's something that you need to build into your business continuity. They are a threat if you don't do so otherwise.

The risks in outsourcing information, transactional data processing, the availability of those systems that you have no control over, the integrity of the systems, confidential information, even regulatory compliance. All must be taken into account, something that you build into your program. If you don't, then you've increased the chances of failure rather than decreased the chances of failure and increased the chance of success.

So whenever a third-party performs a service on your behalf, take into account that third-party. They are a threat if we don't do that, and, of course, the question that we have to ask ourselves after we've looked at all of that is who am I talking to. Well, I'm talking to you obviously, but who are you talking to? It's not just the board and senior management. There are actually two distinct audiences that you need to be concerned with.

There are commercial and private entities. Those are your board of directors, of course. Those are your suppliers. Those may be some of your clients if our clients aren't the retail side. But you also have to be concerned with the government and public authority, the regulators, the people that you have to comply with, whether it's things like O.S.H.A., whether it's the F.C.C., the S.E.C., the Federal Reserve if it's a financial, your state regulators, your national regulators. There are any number of authorities that you need to be concerned with.

Their concern, of course, is the public's resiliency, the public sector. As a private enterprise your organization is part of that, and so you need to be concerned with them. Obviously these two groups have different perspectives, different roles, and responsibilities in terms of a major operational disruption. The government is much more involved with the entire public safety issue, public workings whereas you are concerned with your organization's workings, perhaps your suppliers and your customers on a much more limited basis but they are related. One can't actually work without the other very well. Both are integral. They're very important to the system's resiliency. So there should be communication taking place within that.

Now one of the case in points that I'm making with that would the fact that the public sector and the private sector has been exhibited in the history many times. Obviously one of the ones that you probably think of immediately would be the World Trade Center disaster, the terrorist event of September 11th, 2001. But I'm not going to go back quite that far, though I will refer to it a little bit.

I'm going to go back, and we're going to move to London for this to the U.K. resilience benchmarking project in 2005. You may or may not recall that in 2005 London unfortunately had its own terrorist act that occurred in the London underground where bombs were set within the underground system which brought London to a halt. Thankfully it didn't have the major disaster component that the World Trade Center had. But it still had the effects that the terrorists so desired sadly for us.

What we learned from this, from the ultimate U.K. benchmarking project that occurred in the third and fourth quarter after that is that the markets in London could recover the whole sale payment trade clearing settlement very rapidly, actually within two hours. The reason for that is because it was the financial infrastructure. That was the public domain, and those were able to be recovered within two hours.

What they further noted was that the core firms could recover in an average of 60 to 80% of normal volumes for their part of the system, but that meant that 20 to 40% of the volumes were lost during that period. They were delayed; they weren't carried out. There was a stagnation of some nature that needed to be caught up with.

It was much greater when we look at the World Trade Center back in 2001. You'll notice that the numbers were much more dramatic. Further within the London U.K. resiliency benchmarking project they discovered that trading was a resumption of more normal trading. It was more gradual where less than half of the participants could actually get to a level of 80 to 100% of normalcy within the day. So that meant that the day's business basically had to be put off. It created some uncertainty in the markets which, of course, no one likes. That uncertainty led to, of course, loss of value with things like the Securities Exchange, loss of value in terms of public confidence, and so forth which is where the public bodies, the regulators, are very much concerned.

Of course, that loss of normalcy meant that you, as a business, also lost. Your volumes lost, your profits for the day, created uncertainty with your product, so a very uncomfortable place to be in the short term. Through the next working day most core firms were able to get to that 80 to 100% normalcy, so much better in terms of by the second day. That generally meant it would take a week to two weeks for these firms to actually make up all the lost activity to reach full normalcy.

One of the important things that we discovered like in the World Trade Center was that our firms generally have an overly large concentration within a geographical center. Our backup, our business continuity, our disaster is much too close to our main processing, main servicing sites. In this case the geographical concentration for London, and London is one of the world's financial centers, just like New York, that there was a heavy, heavy concentration of primary and recovery sites within London.

Four hundred, almost 400 sites were located within six miles of Bank Junction. That would be the very epicenter of London's financial world, so 400 critical sites within a six mile radius of this financial hub. Of these three-quarters are within a three mile radius. When you have a disaster of the magnitude that we had with the underground bombings, we find that the damage wasn't to loss of life, though there was loss of life, the magnitude, the loss was to the infrastructure, allowing for transportation, allowing for communication. All of that was blocked, was shut. We had a gridlock effect that meant that the backup sites could not open as anticipated and planned for.

Here's a nice picture to give you an idea of what I'm talking about. That very much that concentration was in and of itself a point of failure. We might even consider it a single point of failure because of the concentration, the closeness of the primary and secondary sites. That's one of the key things we took away from that. We also took that away from the World Trade Center disaster in 2001. So it's a theme that seems to repeat itself unfortunately. I'd like to think that we've learned from these and were able to mitigate that particular risk in our business continuity program. Now while I'd like to think that, I don't know that.

I'm going to ask you some questions so you can tell me whether or not that's the case. What does your organization's business continuity look like? Do you have one? Let's go through a set of questions. I want you to take out a piece of paper, take out a pencil, a clean piece of paper, even a lined one, but you're going to make some diagrams and pictures so your choice, so just to give you a moment to do that. Go ahead. I'll wait a second. All right.

Now I'll give you an idea. We've talked about London. We've talked about the World Trade Center just a little bit. I've mentioned, of course, other small issues that we have experienced. So now let me ask you some questions. Does each department in your organization have a business continuity plan in place? Just a yes or no. If yes, what do they look like? What do those plans look like? Have they experienced, has each of your units, your business units, your departments experienced a failure where business continuity needs to be tested, has been tested? And if you haven't, why haven't you tested it without then or have you?

Now you probably answered yes, and you've probably answered that we've tested it. And it's happened in scattered places, but let me ask you. Does your organization have a global business continuity plan in place? Yes or no? If so, what does it look like? Have you tested it? When's the last time you've tested it? And if you haven't tested it, why not? A plan not tested is a plan doomed to fail when it is enacted for real. Are these questions relevant to your organization? I think they are.

Now these were fairly easy questions to answer, and if you couldn't you need to do some research and homework and come up with the information so that you can answer them to yourself, so fairly easy. Last point, if required, could you draw a diagram or blueprint illustrating the organization's business continuity plans? Not each of the departments but as a whole, a global plan for business continuity. Could you draw me up a simple diagram or blueprint? Yes or no? Okay, you've answered that.

Now that you've answered it, here's your chance to prove it. I want you, on one or two pages. Keep it very high level. I don't need you to create reams of paper, not a whole thousand pages, and not, you know, gigabytes worth of material. But for our exercise, and I don't want you to go digging in blueprints. I want you because you're the expert here now, right? You're the one who's got to justify business continuity. I want you on a high level to give me a diagram of how your business continuity plan looks. How are the departments interrelated? How are the processes going to be taken care of? Who's going to do what? When is it going to happen? How are you going to resume normalcy?

So that's what I want you to do, not as easy as a yes or no question from the previous slide but still very important. Now even, and I know some of you are now shaking your head no, so stop that right now. I want you to make an attempt based on your knowledge of the institution. You must have some sort of knowledge of your organization. So even if you can't blueprint it, I want you to give it a try. Give it your best shot. No one else is going to see this. You're not going to hand it in to me. You're not going to hand it in to your bosses.

This is something that you need to have in place so that you can carry forward with that important task of justifying business continuity. And if what you have in front of you when you're done is very little, that will help you justify the need to build a business continuity plan. If you have a business continuity plan in place, and you have a very nice full page or two, that will help you to justify why you need to keep it in existence. Or maybe why you need to alter it, but you're going to need this as you move on. So go ahead and give it a shot. Give it some thinking, your best thought, and come up with what you believe is the blueprint or the high level diagram of your business continuity plan.

Good luck on that!