| DISASTER
RECOVERY
JOURNAL
P. O. Box 510110
St. Louis, MO 63151
(314) 894-0276
Fax: (314) 894-7474
Internet
www.drj.com
E-mail drj@drj.com
PUBLISHER &
EDITOR-IN-CHIEF
Richard L. Arnold, CBCP
richard@drj.com
SENIOR EDITOR
Janette Ballman
janette@drj.com
MANAGING EDITOR
Jon Seals
jon@drj.com
ASSOCIATE
EDITOR
Ed Pearce, CBCP
ed@drj.com
COPY EDITORS
Richard Sandhofer
richards@drj.com
Pamela Clifton
pamelaclifton@hotmail.com
ADVERTISING
Robert Arnold
bob@drj.com
_____________
Corporate
President/CEO
Richard L. Arnold, CBCP
richard@drj.com
Vice
President
Robert Arnold
bob@drj.com
CONFERENCE COORDINATOR
Patti Fitzgerald, CBCP
patti@drj.com
CONFERENCE REGISTRAR
Merce Knese
mercedes@drj.com
CIRCULATION
Laura Baugh
laurab@drj.com
EXECUTIVE
COUNCIL
Jeff Dato, MBCP, KPMG
John Jackson, IBM
Edward S. Devlin, E.S. Devlin & Associates
James Hammill, CBCP, JMH Consulting Inc.
Pat McAnally, SunGard Availability Services
Brian Turley, Strohl Systems
Belinda Wilson, Hewlett-Packard
INTERNATIONAL
CONTACTS
England: Thom Hetherington
Business Continuity
Phone: 0161-237-1007
thomh@tempus.demon.co.uk
Australia: Anthony J. Harvey
Journal of Business Continuity
Phone: 0011-613-953-0055-8
fax: 0011-613-953-0528
sector@notability.com.au
Japan: Shinji Hosotsubo
Quake Japan Co., Ltd.
Phone: 03-3215-2880
fax: 03-3215-2881
Brazil:
Jose Carlos Ferreira
Disaster Recovery Mercosul
Phone: 55
11 3666-9506
conc2000@uol.com.br
www.drms.com.br
|
|
Click
Here for a Printable Version

Who is Responsible
for BCP?
By DAVE JOHNSON,
CBCP, FBCI, CISSP, CISM
Who is responsible for
business continuity planning in your organization?
As a business continuity consultant, I’ve had the opportunity
to ask that question in many organizations. Interestingly, I have had
many different responses. With apologies to David Letterman, here is
my Top Ten list of responses:
10. The BC coordinator
9. The IT department
8. The business units
7. The facilities management department
6. The risk management department
5. Senior management
4. Everybody
3. Nobody
2. We’ve hired a consultant
1. What’s business continuity planning?
Why is there so much inconsistency in the answers? I suspect the main
reason is that business continuity planning (BCP) typically begins as
a one-time project. After projects are completed, teams move on to new
challenges – leaving on-going responsibility to whomever wants
it. Unfortunately, no one may want it. As a result, BCP may end up as
an orphan, bouncing from one foster home to another.
Since BCP is now generally accepted as good business practice, the assignment
of responsibility for it should not vary dramatically from one organization
to another. If your organization is still struggling with this issue,
here are some “best practices” that may help you.
First of all, responsibility for BCP needs to begin at the top. A company‘s
executive management team and board of directors are collectively responsible
for managing risk, and automatically share responsibility for the BC
program. However, sharing responsibility can also mean that no one has
BCP as a principal area of focus. It is essential for a single member
of the executive management team assume primary responsibility for the
program. Ideally, this should be the executive specifically responsible
for risk management, or the chief operating officer. It should not be
the CIO, since BCP should be driven by business requirements, not technology.
The next level of responsibility is typically assigned to a BCP “steering
committee.” This committee should be comprised of senior management
personnel representing the various business units and the IT department.
The principal roles of the steering committee should be to ensure that
the BC program keeps pace with business requirements, and to assess
and prioritize recommendations for enhancing the program or the organization’s
BC capabilities.
Responsibility at the operational level should be assigned to a network
of BCP “representatives” throughout the organization. These
are individuals responsible for the various BCP processes (e.g. plan
development, maintenance, testing, exercising) within the business units,
the IT department, and other support areas. Although business continuity
is typically not their sole function, their BCP responsibilities should
be explicitly stated in their job descriptions. These responsibilities
should be assigned to individuals with appropriate expertise and authority.
Day-to-day responsibility for the BC program should be assigned to a
business continuity coordinator. This person should head up the business
continuity office and be a qualified BC professional. Ideally, the BC
coordinator should report directly to the executive in charge of business
continuity and take functional direction from the BCP steering committee.
He or she should not be buried several layers deep within the organization.
The BC coordinator should be responsible for providing training and
guidance to the various “representatives” throughout the
organization, and for ensuring compliance with the various BCP processes.
The BC coordinator may also be responsible for performing risk assessments
and impact analyses; coordinating strategy selection and plan development;
planning and overseeing tests and exercises; controlling plan maintenance,
etc. Typically, the BC coordinator would also play a key coordinating
role in an actual disaster.
Needless to say, the above “best practices” can come with
a significant price tag, and may require major cultural change. Many
organizations resist having so many people responsible for BCP, preferring
to encapsulate responsibility within a single area. The reality, however,
is that this is a recipe for disaster. Ensuring continuity of the business
continuity program itself requires commitment from all levels of the
organization, and the clear recognition that BCP is an essential, on-going
part of doing business.
Dave Johnson is a manager in Ernst & Young’s Security &
Technology Solutions practice. He is president of the South Western
Ontario chapter of the DRIE and a member of the DRJ EAB.
©Copyright
2004 Systems Support Inc. All rights reserved. Reproduction in whole
or in part in any form or medium without the express written permission
of System Support Inc. is prohibited.
|