>> Business impact analysis.
The learning objectives for this lesson are
to define the business continuity plan,
to explore business impact analysis,
and to explain recovery objectives.
Let's get started. We're going to
begin discussing business impact
analysis at a high level.
Risk is just a part of doing business
and it's not something we can avoid.
But it's critical that we define the types
of risks that our organization is likely to face,
and then what those impacts
would be on our organization if
that risk were to actually happen to us.
Some risks will be unlikely to
happen and others will have
a higher chance of occurring,
and we need to make sure that
we take into account those and
then how those different things
will cause a problem to our business.
It might be something as simple as a
hacker breaking into our website for defacing it,
or it may be that we have
a natural disaster that takes down a production facility.
The natural disaster while
might be less likely to happen,
if we do live in an area where
natural disasters do sometimes occur,
we need to make sure that we account for that
and have a plan to know what is that,
what would that do to us,
and then we can use this later on to
build our plans on how to recover from that.
We need to make sure we have plans
created to address these different types of things but.
Before we can make any plans,
we have to have our business impact analysis.
Now we're going to go into more detail
into this a little bit later in this lesson,
but I want to give you a high-level overview of
what business impact analysis looks like.
The key point to remember is,
what are the risks that our organization faces,
and how will those risks impact us, should they occur?
The business continuity plan.
The best way to describe this
as a business will be able to continue
delivering its product and services at
an acceptable level following an incident.
An incident has occurred, but
the business still needs to be able to
function as a business to
keep delivering its product or services.
It covers a wide scope from
forming business continuity plans and policies,
and by creating the following;
we need response plans,
we need evaluation activities,
and we need planned maintenance.
The NIST Special Publication 800-34 Revision-1,
Contingency Planning Guide for
Federal Information Systems.
This is a guide that focuses on
computer systems and it has
the following steps for continuity planning.
Develop the continuity planning policy statement,
conduct the business impact analysis,
identify preventative measures,
create contingency strategies, and to develop
an information system contingency plan
moving to ensure plan testing,
training and exercises, and
finally, ensure plan maintenance.
This is a very in-depth strategy to
help you develop your own business continuity plan.
We begin with making a statement.
Our policy statement is,
what are we trying to achieve with this?
What level of recovery do we
want to be able to do should an event happen?
Then we perform our business impact analysis;
what are those risks and how are they
likely to impact our business if should they occur?
Then we begin to identify things we can
do to prevent those things from happening.
After that, we create our contingency strategies.
But we also need to come up with
an Information Systems Contingency Plan
because IT assets are so
critical to all modern organizations.
We need to make sure we have a plan in place ahead of
time to react to those risks.
Then we want to test, train,
and then do exercises for this.
It doesn't matter if we have these policies
and plans in place if no one knows about them.
We need to make sure that we
inform our staff and then we train our staff,
but they will need to test them.
Just because we wrote a good policy or
in a procedure in place for these types of things,
if they're not tested, we don't
know that maybe something doesn't work right.
We need to have some testing to ensure that all that goes
through and that leads us to exercises.
Exercises allow us to have
a fairly real-world feel
to a given risk that has occurred,
and then be able to use our plans to see
how well those plans hold up against that type of risk.
Then we want to make sure we maintain the plan.
Are we keeping it up-to-date?
Has anything changed since
the last time we made the plan?
By making sure we keep it up-to-date,
we're ensuring that it's ready for us when we need it.
Disaster recovery plans.
These are part of the overall business continuity plan,
but they're focused on the immediate needs
of a specific event.
Because when an event happens,
you're going to be under a lot of stress,
and the disaster plan includes
specific steps that will need to be carried
out to recover critical systems.
No one wants to be thinking about all those steps
when you have something very serious that's happened,
you want to build or open up a
playbook and look at it and say,
''First I do this and then I do this,
then check those things off.''
But for that to be able to work,
we go back to the previous slide where
we need to make sure we're
keeping those things up-to-date,
we've trained our staff on them,
and we've done exercises to ensure that
those plans are actually going to work when we need them.
Business impact analysis.
Now we're going to go into a little bit deeper about it.
The first step is to identify all the parts of
our information systems and what they are composed of.
This includes your internal hardware, your apps,
your third party connections,
as well as external services.
Then you need to identify if there are
any regulatory or compliance concerns that you may have,
such as HIPAA or PCI.
These are very critical
because when you have an incident,
you want to make sure that if it hasn't yet
been a breach of one of
these types of compliance frameworks,
then you want to make sure that it doesn't get to that.
Then all of these will play a part in
your overall business impact analysis.
Because again, different risks
are likely or unlikely to happen.
But given certain frameworks,
a risk of data being
exposed is of a higher concern
if you're under one of these frameworks.
Mission critical services.
Identifying your critical services is not
always as straightforward as it would seem.
Typically, you would say my server,
or my Internet connection
or databases, that type of thing.
But the more complex your organization is,
you're going to have critical services that
maybe you didn't realize.
It requires you to meet with
all the business units and discover what is important
for them and how
those units are going to interact with each other.
By doing this, you're going to
uncover things that, again,
like I said, you didn't consider before.
From there you can make a truly inclusive list
of what is mission critical.
Until you have that list,
you really don't even know about
creating a continuity plan
because you might be missing something.
Instructor side note. I had a customer that at
one point they were very
focused on selling products quickly,
restocking so that they continue selling,
and then paying their vendors quickly
so they could keep receiving the products.
We were building a disaster recovery
plan for the organization,
and it had more than 50 locations at that time.
They were using a time clock system
that was in their corporate office,
and then all of the 50 locations
were streaming back to
that central location in their central office.
When we sat down with everyone and
we went over everything,
in our initial setup of this customer,
it was never mentioned how important
this aspect of their business was,
but when we re-framed the conversation in
the contents of recovery and being back up and running,
they were far more concerned with
making sure that time clock was up and running
so that all their employees were giving
their proper work times
logged than they were about paying vendors or
even receiving product or any of that.
If we hadn't sat down
and re-frame the conversation to them,
we never would've been able to
identify that this time clock system
was far more important to them than
they had first lead us to believe.
Even they had not thought of it in that way when we
were talking about what is important to you,
they would tell us it's our accounts payable system,
and we need to make sure that we're paying our vendors.
That server is very important.
We need to make sure that it's backed up and everything.
But the time clock was more of yeah,
that's over there and we need to make
sure that it's functional,
then has access, and that it works,
but it was never discussed in the context
of what would happen if it totally crashed;
is it more important than your other servers?
Having these discussions is critical.
Make sure you meet with
all of the units in your organization so
that you can identify everything that's
critical to the organization as a whole.
Recovery objectives.
When we're thinking of recovery,
it's not enough to just get things back up and running.
Speed is a factor.
If systems were down for a week,
would this be acceptable as long as they recovered?
Some organizations, maybe that's not such a big deal.
But in others, even an hour down is unacceptable.
To improve our recovery capability,
we have to be able to measure
how fast we get things back up and running.
We have recovery objectives.
The first is our recovery point objective.
This is the amount of data that can be
lost before an organization is irreparably harmed.
Then we have our recovery time objective.
This is the maximum amount of time that it should take to
perform the recovery activities
and be back up and running.
On the next slide, I'm going to give
you a visual to help you better
understand and differentiate between these two.
We can think of the explosion there is the event.
Our recovery point objective is
how far back do we have data?
That is the last usable backup that we have,
and that would be our recovery point objective.
Our recovery time objective is going the other way.
How long is it
going to take for us to be able to recover?
Right of bank moving away from the event,
how much time is going
to occur before we're up and running?
That is our RTO,
or recovery time objective.
Privacy impact assessment.
This is performed to discover where
privacy data is stored, how it is stored,
and the impact that would occur if the confidentiality,
integrity, and availability of
that data were compromised.
This is critical to ensure
that privacy data is kept safe,
especially under
the regulatory and compliance systems
that we've mentioned.
This is also a part of our
overall business impact strategy.
I keep coming back to these compliance laws
because these are things that
a lot of people just don't think about.
You can have significant penalties for
allowing data that is protected under
a compliance framework such as HIPAA for being exposed.
Some of these fines could be millions of dollars.
It's been rare, but there
have been occurrences where jail time
was a punishment for a breach of patient information.
You want to make sure that in the course of making
your business impact assessment
or your business impact analysis,
that you're ensuring that you have accounted for
any areas where breaches of privacy would
be a possibility and
then how you're going to mitigate that.
Let's summarize. We discussed
the business continuity plan and
the business impact analysis.
We also went over mission-critical services,
recovery objectives, and the privacy impact assessment.
Let's do some example questions. Question 1.
True or false; the IT department is the
one that makes the decisions
on what is critical and what is not.
False. All business units
should be included in establishing what
is critical to the organization. Question 2.
This measures the amount of time that
a system is down before it is recovered.
Recovery time objective or RTO.
Question 3. This measures how much data
can be lost until an organization will be harmed.
Recovery point objective or RPO.
Finally, Question 4.
True or false; a privacy impact assessment
is separate and not a part of the BIA.
False. A business impact assessment
is inclusive of many parts,
including a privacy impact assessment.
I hope that this lesson was helpful
for you, and I'll see you in the next one.