Writing the plan.
Now,
we usually say writing the plan and we use the singular
often a business continuity plan,
but there is quite often for a large organization 100 different plans.
Our recovery in the case, for example, of a fire,
is very different than it is in the case of malware,
for example.
But we write plans to deal with the various types of
situations we could expect to face.
A plan should be thorough, it should address all types of situations.
We say yes, but there can always be things happen we didn't expect,
but if I've written good plans,
those could be adjusted to whatever type of incident this is.
We get the team together because we want the business continuity plan
and disaster recovery plans to address all areas,
not just IT or not just the business,
but we have to look at everything from finance to operations and logistics.
A plan should be a series of steps and actions.
We should try to minimize verbiage.
We don't want a person to have to read pages of
documentation in the middle of a crisis.
Instead, we want them to read and say do this,
then do this, check, do this, check off,
and all these things mean we move towards the actual
resumption of business processes.
We should write the plan for what we often call a worst case scenario,
the most resource intensive situation because then we can always use a
part of the plan if it's not a worst case scenario,
and that means that in a worst case scenario,
any type of lesser incident or situation would still be addressed in that plan.
One of the problems we have is that during a crisis,
we have an elevated level of risk.
We know that, for example,
many of the normal controls we would have had in place,
separation of duties, for example, are missing.
We have people making decisions that go beyond what was
their normal budgetary authority.
So this is an elevated security risk as well we have to watch for.
We want to have teams that are ready to go.
We assign roles and responsibilities, as well as,
of course, the leaders, but for every leader,
there should be a deputy,
a person who can fill in if that leader was not available.
Ideally,
we want to have people on the teams that understand more than
just their area so that if another team was in some ways
impaired from being able to do their job,
there is cross‑training and there is support that can be provided.
An important thing in a crisis is to have clear
leadership and lines of reporting.
We define who's in charge, who makes the decisions,
who talks to the media so that we have good and clearly
understood reporting relationships and it's not such that
everybody's just doing whatever they think is best.
We need to ensure that the people on our teams have the appropriate
training so they can execute their responsibilities,
as well as the tools they would need in order to do their job.
An important part in any crisis is communication,
communication with our employees, managers,
our customers, all of the stakeholders, or in other words,
all of the people who could be affected by this crisis.
We want management to know what's going on so they can provide
direction and certainly answer questions from the media.
We quite often have to report to government and regulatory agencies,
let's say if we had a spill of diesel fuel or some other type of
environmental issue, or even an injury to an employee or a customer.
We want to communicate with our customers so they have confidence that we are
there to support and help them and it's not such that we are going to
disappear and their warranties are now worth nothing.
This is especially important when we're dealing with a privacy breach.
We want all of our customers to be confident that we have done
everything we can to protect their information,
but also that we're being upfront about what had happened and how we
will prevent that from happening in the future.
We need to communicate with our suppliers.
We quite often rely on them some of the raw materials we'll need
and we don't want them to stop shipping those products because
they're afraid they'll never get paid.
And of course, our shareholders.
By law, in many cases,
we have to communicate with our shareholders all at the same
time so they're all aware of what's going on if this is
something that could affect share price.
When we talk about reporting,
we want to do regular reports on the status of the crisis to management,
and this quite often can be done through an emergency operation center,
the heartbeat or control point where we'll actually manage
all the various teams and activities, and from this point,
we can communicate to management what's going on.
We should have checklists, our plans are action‑oriented,
so we can show milestones and progress we've made towards
addressing various types of systems or issues.
And then, of course, we want to get back to normal.
We will call this the process of restoration.
To restore to normal means I will recover the business functions
at whatever is now going to be my primary site.
Now, normally, when we recovered after the incident,
we recovered our most critical business processes first,
but when I restore, I'm going to recover the actual less important areas.
That will allow me to test my migration plan,
my networks,
and my systems before I jeopardize my most critical business processes by
trying to move them into whatever the new normal is going to be.
No plan can be trusted unless it's been tested,
and we do tests of the plan with the intention of finding any deficiencies.
The point of the test is to find something that could go
wrong so we can fix it before the incident.
The testing also helps us to train our staff so they develop
skills and know how to respond effectively.
The test should be thorough,
they should be as accurate and realistic as possible so we know that this
is how things would work in a real world situation.
When we test, it's always good to start small.
Do some little tests of just individual processes before we
move on to more complex types of tests.
One of the problems is that very often from any incident and from any,
we could say, test, there have been lessons that have been identified.
It is important that those become lessons learned.
We apply what we learned so we improve it so it doesn't just happen again.
In summary, in this module,
we set out the requirements for disaster recovery planning.
This is for the most serious types of incidents that
would require relocation of operations.