Let's continue with this Business Continuity,
Disaster Recovery,
and Incident Response for the Certified in Cybersecurity certification
with a more detailed look at business continuity.
Earlier on, we saw this definition, business resilience,
a common word being used today,
and it can be defined as the ability to continue operations,
even during adverse circumstances,
so this is the heartbeat or the main thrust of some type of
business continuity program continuing operations,
not just recovering.
We saw before that incident response is very often the first step,
but when it's a severe incident,
it might trigger the need to implement and start to
use business continuity plans.
The outcomes of the business continuity management system were to have an
incident response plan focused on life safety containment,
documentation, and return to normal,
but then to have a business continuity plan focused on business impact analysis,
critical business functions, recovery time objective,
the data recovery point objective, and the recovery requirements.
When we looked at disaster recovery planning,
we're looking at a catastrophic event that meant we had to relocate
IT and other services to an alternate location.
Business continuity is just simply project management.
It starts with project initiation, then moves on to business impact analysis.
Based on the business impact analysis, we'll select our recovery strategy.
Then we write plans for how to implement that recovery
strategy in the event of a serious incident,
but we know that all plans need to be tested.
We need to roll it out,
communicate it so that everyone is aware of what to do in a crisis,
and certainly through testing, we train our staff,
and we also find any flaws in the plan.
Every type of use of the plan, whether it's a test or a real incident,
will allow us also to learn more about how to make the
plans better and maintain the plan.
The heartbeat of business continuity is understanding the business,
and this is a process known as analysis of the impact on the business,
or BIA,
and it could easily be said this is the critical and most important step
in the actual business continuity planning process.
Through business impact analysis, we identify what is critical,
the critical business functions, processes,
for example, that are going to have the most impact on the profitability,
the reputation, and operations of the organization.
Some departments are more important than others.
For a while, I worked in internal audit,
and believe me, we weren't a critical process.
Most of the business thought they'd run better without us,
but the ones that are important need to be identified so
that's where we set our priorities.
We also need to know what are the critical supporting processes in
order to support those critical business functions.
In other words,
the dependencies that critical business functions have on supporting processes.
When we want to recover a business process,
we need to know what we need in resources,
people, data, facilities, equipment, and supply chain.
The BIA allows us to determine our priorities for recovery.
Let's look at how this all works.
We have the element of time and business impact
analysis is all about impact over time.
In that way,
it's different from risk management because when we looked at risk
management back in the Security Principles course,
we saw that risk was based on impact and likelihood.
So here, we're looking at impact over time,
so very much an overlapping type of supporting process,
but slightly different from a risk assessment.
Over time, the business is running as normal,
normal operations, but then one day, we encounter a crisis.
As a result of that crisis, our level of business drops to 0.
We're no longer producing a product, we're no longer meeting our mission.
Now,
immediately we should start to determine what is the impact of
that inability to operate our business over time,
and we can see that that quite often will grow kind of exponentially at the end.
Over the first few hours,
people understand if we've got a little bit of an outage,
but the longer it goes,
the greater the damage to our reputation and finance becomes.
Now, this is different for different business processes.
Obviously, if this is the life support system,
this is measured in minutes, not in hours or days.
One of the things we try to determine through all of this is
when the level of impact would be high enough that we
actually encounter business failure, the business has to shut down.
We are unable to continue business operations.
We've lost the confidence of our customers,
our owners, our bankers, for example,
and that point in time at which we would encounter business failure
can be called the maximum tolerable downtime.
Sometimes we'll hear that called the maximum tolerable period of disruption.
In the old days, we used to hear it called maximum allowable downtime.
I think sometimes they change the name just to keep us all a little confused.
So we look at all the business processes of the organization.
We said that some are more critical than others,
and we want to know what are the critical supporting processes for
each of the critical business processes as well.
We'll quite often then group.
There is no way to recover a business process without also
recovering its supporting processes,
so our recovery plan should look at recovering both of them,
should we say, concurrently.
We can say it simply this way,
you cannot recover essential services without recovering supporting processes.
One of the things we need to learn is what will our owners,
what will regulators, and what will our customers tolerate?
These would be tolerable levels of outage.
We all know that, in some cases, the customer will say,
oh yeah, sure, your systems are down, I'll call back in an hour.
In other cases, we will lose the customer.
So this is where we have to understand what our customers expect.
Are there regulations that say we must provide a
certain level of service bound by say, government regulations?
All of these can help us determine the point of business failure,
something we called before the maximum tolerable downtime for those
critical processes and their supporting processes.
Then we want to determine what is our ideal time of recovery,
and this is known as the recovery time objective and will have
different recovery time objectives for different processes.
The, of course, requirement is that the recovery time objective must be,
in fact, we could say, significantly less than the maximum tolerable downtime.
I don't want to write a plan that would have me recover my critical
business process an hour before the business would fail.
The other thing we have to look at is the recovery point objective,
and I always call it the data recovery point objective because what
this refers to is what is my data recovery point.
I'm really saying that if I have a major interruption,
how much data can I afford to lose.
So really what this measures is the amount of data that
can be lost in the case of an outage and how old the data
would be when it's restored.
When we looked at the resource requirements,
we need to identify what would be required in order to restore systems.
Now that, as we said, also included some of our supporting processes,
our dependencies,
but also it includes things like the controls we put in
place that could be added to try to make sure that this
doesn't just happen again right away.
So let's go back to that diagram we looked at before.
The idea here of BIA was that we determine what was the level of
impact over time until the point of business failure.
Then we want to say, okay, what would it cost for us to recover the business?
Now, the cost of recovery is often the inverse of the duration of the outage.
In other words, I could have a very minimal amount of,
should we say, outage time, but then the cost of the recovery is very high.
So in most cases, instead,
we will try to find more of that crossover point at which point
we could say the cost of recovery is sort of,
I should say, inline with the impact.
This is where we want to set our recovery time objective.
So we write plans to try to recover these critical
business processes by this point in time.
But when I recover, say after a fire that wiped out my head office,
I have to go to my data backups and maybe I did data backups on a regular basis,
but the time of the failure was not the same as the time of my last data backup.
So I, when I rebuild my systems,
am going to have to use the most recent backup I have,
which quite simply means that quite likely all of the data
from the time of the last backup until the time of the
crisis will actually be lost data.
All of this allows me to set out my priorities and plans for recovery.
I establish one of the priorities for system recovery based on cost,
as well as the level of impact to the business.
And of course, I must have a plan which is feasible,
not unrealistic, I can't recover a major system in a few minutes.
It must be something which is acceptable,
acceptable to should we say our customers,
our owners, management,
something which is suitable for the type of business we're in.
And of course, this is something that quite often is a little bit contentious.
We'll have a lot of different people think,
well, my department is most important so you should recover my department first.
In the end,
we need to go back to senior management and hope that they will
approve the actual choices we've made for which parts of the
business should be recovered first.
The key points review.
Its business impact analysis that provides us the
information we need in order to move ahead with selecting
our recovery strategies and writing plans.
It's critical to the business continuity planning process.
It identifies all of the critical business processes,
documents the resources required to restore those processes,
and gives us now the ability to choose restoration timelines.
It sets out our priorities, and through this,
helps us to move on so we can write effective plans for business continuity.