Okay, so we've looked at the first phase of the plan, which is Project Initiation. And that's where we get the policy. The BCP policy, which essentially is management's backing in writing now. The first riel action I didn't, though for those of us on the BCP Committee is to conduct the business impact analysis.
This is huge. And as a matter of fact, when you find failings with actually carrying out the plan Ah, lot of times the problems can be traced back to the B I. A.
Okay, so the job of the business impact analysis is to identify and prioritize all business functions based on criticality,
so identify and prioritize all business functions based on criticality.
Okay, we identify first,
business functions. Not I t functions, but business functions. And then basing that prioritization on criticality is all about time sensitivity. What we're trying to figure out here is what causes the greatest loss. So, for instance, if I'm in it, you know, uh, Amazon, for instance,
when we look at Amazon, think about how much money they lose for every hour they're offline.
Wherever 15 minutes, they're off lawn for that matter and it could be millions of dollars. So you can rest assure that one of Amazon's most critical processes is their web presence. Right. And it's based on how much money do I lose as this goes down.
Ah, we want to get both of value qualitatively and quantitatively, so I want to know. Okay, this is a high priority. But I also want the numeric data to say Yeah, for every five minute time down, we lose $100,000 because it's that quantitative value that's going to justify
the counter measures I'm gonna put in place won't vote that qualitative and quantitative.
Now you have to know certain metrics and several of these air really important service level of direct objectives, recovery point objectives, maximum tolerable downtime. Those air. Probably the biggest on here. So your service level objective is gonna be identified in the B I A.
the service level objective is understanding that were, if there has been a disaster, we're gonna be operating at a reduced capacity. But we still are gonna have targets we want to hit for customer service. So for instance, years ago, I worked for a large customer service call center,
and we had to answer 96% of incoming calls
with a minimum of maximum whole time of five minutes. I'm just kind of making these metrics up, but But we had a pretty tough metrics to me and, um, you know, day in India, day out. We had to meet those goals.
Now, this was back in North Carolina. In one winter. We had just a crazy snowstorm dumped something like 25 inches and greens for North Carolina
and that just shut the city down. So most of the roads were closed. We couldn't get into work. So what happens? They sent the call center operations from Greensboro down to Fort Lauderdale, Florida,
because obviously, they were not affected by the snowstorm.
So Fort Lauderdale had to answer their normal incoming calls. Plus all the calls that have been rerouted from Greensboro. Were the folks in Fort Lauderdale gonna meet their goals? No, But does that just mean management said Hey, get out there and give it a try. Good luck. No management still has expectations.
So the service level objectives were to answer 85% of incoming calls
to have a maximum whole time. No longer than 10 minutes. So they're understanding we're gonna reduce capacity. But we still have objectives we want to reach for service. Okay, that's an SL. Oh, don't confuse that with an S l A. A service level of green.
And that's a vendor's commitment for a certain amount of up time for their profit. Okay, which could also come in and be very relevant with business continuity.
All right, recovery point objective is my tolerance for loss of data.
How current must my dad would be
Now I can guarantee if you go ask senior management say so. How much data are we willing to lose? The answer's gonna be Nolan. We can't lose any Gavin.
Well, good. I can do that for you to get your checkbook. It's gonna be expensive,
right? 24 7 up time. Ah, 100% data recovery. That's costly. That's not cheap. That's not easy to guarantee. So usually when you come back and say, get your checkbook Management says, Well, what I meant was an hour's worth of death
or days working. Whatever. And if you think about it, if your organization does nightly back up, you back up. Dab it
every night at midnight. Um, in your own Monday through Friday, 8 to 5. Company. If you're only doing nightly backups, you're essentially saying you're willing to lose a day's worth of death.
And, you know, I mean, technically, you could have a failure for 45 not be able to recover anything and have to restore from the night before his backup and having lost everything from the day.
So you know, sometimes coming through this plan and developing the plane is a good time to open up discussions with senior management and make sure that we're really able to meet their requirements.
Usually, there's a backing fourth, where senior management wants no downtime, no data loss. Well, that's gonna take money. Then we go back and forth, and generally what we'll do is we'll create, you know, 234 options. And if you truly want 24 7 up time, here's the expense. Here's what we have to implement
if we can sustain an hours downtime that here's how we would go forward.
So we generally like to give senior management multiple options and have them sign off by the at option that they've chosen because ultimately, what we decide as our metrics for the business impact analysis plan, that's what everything else is gonna be based on. So we want to make sure that senior management acknowledges
what they put in place, their metrics so that when we you know, if they decide that losing a day's worth of data is okay based on cost,
and then we have a disaster in a day's worth of data is lost. We want to make sure that it's their name match to that decision. My philosophy is I never want my name to be the highest on a bad decision,
right? I'm gonna get somebody hired me to sign off maximum tolerable downtime. That's exactly what it sounds like. What is the absolute longest We can tolerate having this system or service or process down sometime? That's you. Sometimes that's used in conjunction with Rto
Recovery time objective. I've even seen it written that those two were the same terms. They're technically not. Usually the Rto is how long it takes to get the hardware restored and then work recovery. Thomas, how long it it takes to restore the software and the process is so usually the recovery time objective in the work recovery time together
Give us the MTT. I do not expect them to go that detailed into it. Okay, So, honestly, if they see if you see maximum color of downtime or recovery time objective, think of that as the longest we can be without this process before we suffer a loss.
That's unacceptable to senior mange.
All right, meantime, between failures and meantime to repair this is with hardware components in T B F. It's the life span of the device. So hardware has an MTV F three years. That's its life span
meantime, to repairs, how much it takes us, it does fail to rebuild
and then minimum operating requirements. M. O. R. You know, if I've got a sequel database, I'm not gonna be able to run that on opinion 200 megahertz system. So if I've got specific at Applications Service's, I need it Well documented. The hardware and software necessary to run those surfaces and that would be documented in
minimum operating requirements.
So with this Plan B. I A or the key elements of the plan, the most important element is the B. I. A management, Uh,
management specifies and signs off on the priorities for the business they want personnel named. We've gotta have succession plans, you know, people move in the organization. So if the director of I t. Is not available than the co director or
if the lead technician isn't available than this,
M o use and m o a. CZ are also gonna be important because that makes sure
that the people responsible for activities sign off and acknowledge they're aware of their roles and responsibilities on the test. If they say someone was supposed to be there and didn't show up,
what document would have corrected this problem? They're getting at either an em away or a MOU, and they do not differentiate between the two on the test.
All right, we've got to think about recovering technologies, facilities, our communication systems, their records, the data. You know, we've got to think about the criticality and how we're gonna rebuild all this stuff. But it starts by figuring out what impact loss of these elements have on the business.
So once the B I A is completed, we've identified all our business processes and our assets not just the critical ones. We've identified them all and prioritize based on criticality.
We have documented how critical those elements are and what our tolerance for losses
and that's gonna lead us to put in recovery strategies. And those recovery strategies are going to make sure that we can cover out the metrics specified in the B I. A. So, for instance, if I say I only have a max, I have a maximum taller debt. Tolerable downtime for my email server of two hours.
Well, my recovery strategies, which come next,
better be set up to maintain and to restore that server within two hour time, period. So every decision that we make from this point forward really stems from the B I. A. Look to the B I. A. Is being the source of the problem, but also of the solution