Instructor: Business impact analysis.
In this lesson, we are going to talk about
the concept of a business impact analysis.
And this is really focused on how do things
affect our business.
Now when I talk about a business impact analysis
this is also abbreviate as a BIA.
This is a systemic activity
that identifies organizational risks
and determines their effect on ongoing
mission critical operations.
Let me give you a great example
of a business impact analysis from my own company.
My company happens to reside in Puerto Rico.
Puerto Rico is a small Island in the Caribbean.
Now you can see it here on the screen.
Now because our company is in Puerto Rico,
we have to worry about natural disasters
and their impact to our business.
For example, after a massive hurricane in 2017,
the Island of Puerto Rico was without power for months.
So, when we decided to move our company to Puerto Rico,
we had to consider the impacts to our employees
and our business if another huge storm came through.
Because we are in Hurricane Alley
and we're likely to get more storms.
Now another thing we have in Puerto Rico
that happened recently is earthquakes.
So right after I moved my company to Puerto Rico
the island started shaking
and started having a series of earthquakes
at the southern part of our island.
Now this started creating damage to many businesses,
houses and churches, as you can see here.
Now because of our choice to be based out of Puerto Rico,
our company, our employees and my family
all have to have primary and backup plans
to continue our operations even when the local power grid
goes offline due to storms or earthquakes
or any other reason.
That is one of the main things we have to think about
as part of our business impact analysis.
Now, when you're conducting your business impact analysis
this is going to be governed by metrics
that express your system in terms of availability.
For example, are you a 100% available
or are you 90% available?
In our company, we try to achieve 99% uptime,
meaning we want to be available to you 99% of the time
during normal business hours.
Now, when we start talking about these metrics
there are lots of different ones we have to consider.
We have things like our Maximum Tolerable Downtime or MTD.
We have Recovery Time Objective RTO.
The Work Recovery Time WRT,
or Recovery Point Objective RPO.
Let's talk about each of these.
Now when we talk about a Maximum Tolerable Downtime or MTD,
this is the longest period of time
a business can be inoperable
without causing irrevocable business failure.
Essentially, how long can you be down
without going out of business?
Now, the MTD is going to be different for each organization
and even within each organization
each of your business processes can have its own MTD.
For example, some may be just a couple of minutes
or a couple hours for critical functions.
You may have up to 24 hours for urgent functions
and up to seven days or longer for normal functions.
It really does depend on your organization
and you have to figure that out for yourself.
Now the MTD is going to set your upper limit
on the recovery time that the system and the asset owners
have to have to resume your operations.
So keeping that in mind,
let's take a look at my own business.
I already mentioned
that power was a really important thing for us.
So we know that power is critical to our business functions.
Without it we really can't do our job.
I can't film courses and I can't answer student questions
if I don't have power to turn on my computers
and be able to run our internet.
Now, without this power, we can't do our job at all.
So we have multiple backup systems
to protect power to our building.
First, we have power from our local electrical company
coming through the wires on their grid.
Then, we have solar power that provides as a backup
during the day if the grid goes out
and it actually acts as our primary electrical source
during the day because it's so bright
and sunny in Puerto Rico.
Now after that, we have some Tesla power walls
that we've installed.
These are batteries.
And these collect power from our solar system
during the day,
and that way, even if the grid goes out,
we can end up having those batteries
provide the power to us.
And that can happen at night as well.
When the sun goes down,
we can actually survive off those batteries
if the grid is gone.
Now, if it becomes cloudy then the solar won't work.
Well, we still have the batteries.
And so we have primary of grid, secondary solar,
tertiary of batteries.
But for us, that's not enough.
We actually in addition to that,
have a diesel generator as well.
And that diesel generator has a hundred gallons of fuel.
That's enough for us to run seven days straight
without the need for more fuel.
So for us to be without power takes a lot these days.
Because we have the grid, we have solar, we have battery,
we have diesel, we have all of these systems in place
because we realize that is an important
mission essential thing for us is to have power
for us to be able to do our jobs.
Now, if the power grid goes out for more than 60 minutes,
we found another issue though.
And that's that our primary internet connection
from our cable provider dies.
Now, that isn't a problem for me if I'm filming,
but if I'm trying to answer your questions
and do student support,
we can't do that without internet
because we have to be able to reach to you, right?
And so that's another issue for us.
And so we have a secondary service for that.
We have a cellular modem that we use as a backup.
Now we realized recently,
there's a big storm that came through
and our area lost power for three days.
Now we didn't lose power
'cause we had all these systems in place,
but our internet connection died.
And so we tried to switch over to the cellular modem
and we found out the speed was horrible.
Why?
Because everybody else was out as well.
And they all went onto their modems.
And because they went to a cellular modem,
the cell towers were being flooded with users.
And so we were getting speeds that were 10
or 20 or 30 or 40 kilobits per second.
And we were hardly able to even open up our ticket system
to be able to answer our students' questions.
So now that we've learned from that,
we have a third internet provider as well
that provides a service over microwave
and they have a better backup plan for power outages.
So they maintain services up
even when the local cable company is down.
So this helps eliminate that bottleneck.
My point here is that you have to do this business impact
for yourself in your organization.
And figure out what things are critical to your operations
and put things in place to help protect those.
So when I look at my support services
what is our MTD for our support services?
Well, we calculated that our maximum tolerable downtime
is 12 hours.
Now, how do I come up with 12 hours?
Well, we started thinking about
if I was a student, what was the longest period of time
I would want to go
without getting an answer to my questions?
And we figured that 12 hours was a reasonable time
in an emergency situation.
Now to accommodate that
we actually have our staff split in two parts.
Half of my team resides in Puerto Rico.
The other half of my team is in the Philippines.
They are 12 hours off sync from each other.
So when it's daytime in the Philippines,
it's nighttime in Puerto Rico.
And when it's daytime in Puerto Rico,
it's nighttime in the Philippines.
And so we actually can cover almost 24 hours a day
using these two locations.
'Cause each side works eight hours.
And so there's a little bit of time
that isn't covered by both teams.
Now that again works within our 12 hours of time.
Now, the other good thing about this
is because they're so geographically distance
if there's a big storm that takes out Puerto Rico,
hopefully it doesn't affect the Philippines.
If there's a big storm that takes out the Philippines,
hopefully it won't affect Puerto Rico.
And so by having our geographic diversity here
it allows us to maintain that 12 hour response time.
Because even if Puerto Rico was down
well, in the 12 hours, the Philippines team would be awake
and they'll be able to take on that load
I'll be able to answer your questions.
And so that's why we do that.
And that's why we break up our company.
It was a risk management decision
that we've made to provide better service to our students.
Now, again, you need to figure out what your MTD is
for your company in the real world,
so you can design your risk management plan
around supporting that MTD.
What we've done for us,
was thinking about the biggest threats to us,
which are natural disasters.
And so we have our MTD built around that
for our student support services
and we put power and internet connectivity
at the top of that list of things that we need to have
two and three and four different mechanisms
to be able to provide backups to our backups,
to make sure we can always support you.
Now, the next one we want to talk about is our RTO.
This is our recovery time objective.
Now this is the length of time it takes after an event
to resume your normal business operations and activities.
When you start thinking about recovery time objective
I want you to think about the fact of something went down.
We lost power.
How quickly do you need it back?
In my case, we have a 60 second time for power.
We want to make sure our power is back up
and online within 60 seconds.
Now, is that achievable?
Yes.
If you have a backup diesel generator
it will turn on, in about 45 seconds
and transfer power to the diesel generator.
Now my wife, wasn't happy with 45 seconds or 60 seconds
and she wanted a recovery time of zero.
Now, can I achieve that?
The answer is yes.
And that's one of the reasons
why we have those battery backup systems.
Because if power goes away,
those batteries come on instantly.
There is zero lag time there.
And so we're able to hit a recovery time objective
for power of zero seconds.
Now the overall power of getting it back to the grid,
we can't control that.
That's up to our local power company.
But we can make sure that we can recover our business
and make sure we're on battery, on solar, or on generator
within zero seconds.
And that's our recovery time objective.
Now, the next one want to talk about is work recovery time
or WRT.
This is the length of time in addition to the RTO
of individual systems to perform re-integration and testing
of a restored or upgraded system, following an event.
So let me give you an example.
Let's say in my organization, we had a power outage
and we didn't have the batteries yet.
We had to rely on those generators.
So we had a 60 second recovery time.
Well, in 45 seconds, power comes back up.
But if those systems went down because of a power surge,
and I had to replace one of my servers,
well, that's going to take additional work recovery time.
I fixed the main problem
the recovery time objective of getting the power up.
But now I have to fix the second and third order effects
to get work product going again
which might be rebooting your computer.
It might be rebuilding a computer.
It might be replacing a hard drive.
Whatever those things are,
I have to perform that re-integration and testing
to bring those systems back online
in an upgrade or restored state
to be able to get us back to regular work product.
And our final one we want to talk about is RPO.
This is our recovery point objective.
This is the longest period of time
that an organization can tolerate lost data
being unrecoverable.
Now the way I like to think about this one,
when I think about RPO is think about ransomware.
If you have ransomware on a system,
it's going to encrypt your files.
Now you've got a couple of choices here.
You can pay the ransom, which we never recommend.
You could try to crack the ransomware key
which could take you days, weeks, or months or years,
depending on how strong it is
or you can actually wipe that system
and recover from a known good backup.
Well, that's great.
Let's go ahead and choose that option.
Well, if we do that, what is the longest period of time
that we can tolerate data loss?
Well, there's going to be time that we're going to be lagging
as we're recovering all that data back.
And that data may have several hours
since it was last backed up.
For instance, if you run your backup once a day at midnight,
that's when your data was backed up.
And if this ransomware hits you at six in the morning,
you have six hours worth of lost data
because you don't have a backup of that.
This is what we're talking about
when we're talking about recovery point objective.
That six hours is going to be lost period of time.
And so if your RPO was 12 hours, that's fine.
If your RPO was four hours, you've just broken your RPO.
So you need to keep that in mind.
When you're thinking about your recovery point objective
you are focused on how long you can be without your data.
That is the whole idea here.
Now, when we start thinking about your MTD and your RPO
these are key terms you need to know for the exam.
They're going to help you determine
which business functions are critical.
And they're going to specify appropriate risk countermeasures
to help you make sure
that you're going to be able to get those systems
up and running and within those MTD and RPOs.
For example, if your RPO is measured in days
then a simple tape backup will work fine.
Or you could use a network attached storage array,
or something like that.
But if your RPO is zero or measured in minutes or seconds,
then a more expensive server cluster backup
and redundancy solution is going to be needed.
A good example of this is my own company.
We have a server cluster backup
and full redundancy solution for our web servers.
This is because
we can't afford to be down for long periods of time
when over 200,000 students are relying on our servers
to learn from our videos and our practice exams
to prepare to pass their certifications.
When I sold you a course, I sold you access to that course.
We want to make sure you have access.
And we can't say, "Oh, I'm sorry.
We lost all of your data for the last three weeks.
We're going to have to have you start over."
So we want to make sure we have that set up right.
And so we've taken the risk management mitigations
to help make sure we maintain a good MTD and RPO
based on that need keeping our MTD very low in time
and our RPO, very low in time.
So you get a better experience.
Now we've covered the basics
but there's still another piece we have to talk about.
Because when you start designing your disaster recovery
and continuity of operation plans,
it requires that you have an understanding
of your availability and reliability levels.
This is because disasters can be caused
by either internal or external forces.
I mentioned a lot about external forces
so far in this video.
I talked about the fact that the power can go out
or a hurricane can come, or earthquakes.
Those are all external forces to my company.
But I also have internal ones.
For example, I might have a system administrator
who makes a mistake and deletes the file share.
I might have somebody who's trying to upgrade something
and they crashed the servers.
I may have a router or switch
that just decides it's done working and it crashes itself.
Or the power supply goes out.
These are all things that are internal to my organization,
and we have to take care of those.
Now, when we talk about this,
there's really two terms we need to talk about.
And this is the mean time to repair
and the mean time between failures.
Now, when I talk about the mean time to repair
I'm talking about the time on average that it takes
to go from system failure to resuming operations.
So if I have a server that crashes
and I have to install a new server
there's time involved with that.
And that is what we're talking about with time to repair.
Now when I talk about the time to repair,
I want you to think about this
in terms of the recovery time objective
and the recovery point objective.
Because those are the goal of what we're trying to go for.
So if my recovery point objective is going to be four hours
and it takes me two hours to recover the system,
that's fine.
But if I know it's going to take me
eight hours to recover this system
well, we need to come up with a new plan
because we're not meeting the goal that we set in that RPO.
Now the second part of this is our time to failure.
And this is a time when you go from a normal operations
into a system failure.
Essentially, I like to think about this as the uptime.
So when you think about the time to failure,
if I started running all my servers today
and they run flawlessly for one year and three days,
and then they fail.
Then my time to failure is one year and three days.
If I take all the time that I've had that server
and I average it together,
I can figure out what my mean time to failure is
over that extended period of time.
Now the reason that the meantime to repair
and the time to failure are important
is because this tells me how long I expect to be down
and how long I expect to be up.
And that helps building my knowledge
as I start building my continuity plans.
Now when we talk about the time between failures
this is the time going from one failure to the next failure.
So for example, if I have a switch and it fails today
and I put in a brand new switch and it took me three hours
well, the time to repair was three hours.
I had a failure, I fixed it within three hours
and now we're back online.
And so now that we're back online
let's say we're going to continue operating.
And it takes us a year before the next failure.
That means I had time to repair of three hours,
time to failure of one year.
And if I put those together, I get the time between failures
which in this case would be one year and three hours.
That way I know how long I can expect a given piece of gear
to work for me before I need to replace it.
If I know my meantime between failures
happens to be three years,
then at two and a half years,
I would want to replace that
so I can plan to replace it before it fails.
So just as a review,
now that we've talked about what this looks like
when we talk about meantime to repair,
we're talking about the average time it takes
to repair a network device when it breaks.
And when we start talking about the meantime
between failures,
we're talking about the measure
of the average time between failures of a device.
So keep these two terms in mind for the exam,
because you may see questions on them.