|
| Business
Continuation Plans |
Question:
Our CEO suggested that I help creating
such a document | (requested by some
of our clients). Before meeting the
relevant VP, I | googled it and was
amazed by the wealth of information
regarding such | plans
and their complexity. My question
is: did anyone out there | participate
in such a project and if yes, on what
level: - helping | with the writing
- part of the project team - leading
the project.
Answer:
I've worked on several such plans
over the years, and they can be pretty
interesting, particularly as you see
new aspects of the company. These
are also often called, more tellingly,
disaster recovery plans,
so you might also google on that.
Key things to consider: Is it a real
plan, designed to implement, or a
make-work plan, designed to keep your
clients happy? It's unlikely you can
really ask this, but the answer here
will make a lot of difference as far
as the effort and time for the plan.
For example, if you're talking about
where offsite tapes will be stored
and who can get them, ask where the
tape library for the recovery will
be located. If that question is "out
of scope", it's a make-work plan.
If that question causes the IT director
to turn pale, it's real.
How will you keep the plan "live"
after the project is complete? Even
if you do a really good (and real)
plan, it will cease to have value
quickly if it's not updated to reflect
new business
realities and processes. (Hint: Don't
volunteer for this part--it's tedious,
thankless, and essential.)
If you want to have fun w/ the CEO
and IT folks, poke them about how
it'll be tested. They'll say, possibly
correctly, that it cannot be, but
if you don't test, you really won't
know--it's just like writing any other
docs w/o doing the procedure, and
the little stuff that was overlooked
will get you. E.g., if your process
calls for recovery within 24 hours
of declaring an emergency, but restoring
the key business
data from backups requires 72 hours
per the physical limitations of the
hardware, you'll have an issue. Or
if the backup system administrator
is supposed to work at the recovery
site within 12 hours, but doesn't
have appropriate 24x7 access privileges
to a secure site that your company
may not own, it'll be interesting.
My company writes these for others
as a business.
Its part of numerous security projects.
Business Continuity Plans (BCPs) are
very difficult to write. They demand
an intimate and comprehensive understanding
of the business, its risks, and its
tolerances to failure. It requires
extensive training in risk management,
information security, and business
governance to write a successful BCP.
Typically, technical writers ist in
such projects, they don't lead them.
A security or business auditor should
lead such a project.
Ideally, your company needs should
conduct a full security assessment
that includes a business continuity
and gap analysis. From that, you can
outline the risks and tolerances for
your organization. Then you'll be
ready to write a BCP based on the
findings of your security assessment
Eric is right, BCP work can be very
fun. But if you have never done one,
you should seriously consider contracting
somebody who has experience doing
them. Just running around and documenting
paranoia "how many backups do
we have" "what happens if
a tornado hits the building"
is not a BCP. A BCP is a corporate
governance document that needs to
address fundamental business, financial,
and personnel issues. The paranoid
stuff is merely a fraction of what
a BCP contains.
There are some good templates out
there that can serve as a framework.
I'd look into ISACA (). Good group.
They are mostly focused on IT governance
and auditing work. Technically a BCP
crosses the IT boundary into business
and finance issues.
If you're CEO is asking for one just
to placate clients, then you can throw
one of these together. It might not
be useful, but if that's the goal
of the BCP, it will work.
 |
|
|
|
|