Вы находитесь на странице: 1из 14

ARTICLE IN PRESS

International Journal of Information Management 26 (2006) 128141


www.elsevier.com/locate/ijinfomgt

A framework for business continuity management


Forbes Gibb, Steven Buchanan
Graduate School of Informatics, University of Strathclyde, 26 Richmond Street, Glasgow G1 1XH, United Kingdom

Abstract

An enterprise is exposed to riskssuch as acts of terrorism, natural disasters and utility failurewhich may disrupt
operations, disaffect customers and compromise business credibility and revenue streams. Risk can also be introduced to
an enterprise through changessuch as automation, down-sizing, process re-engineering or outsourcing of processes and
serviceseach of which may also bring changes in the type of risk. This paper proposes a framework for the design,
implementation and monitoring of a business continuity management programme within the context of an information
strategy.
r 2005 Elsevier Ltd. All rights reserved.

Keywords: Business continuity management; Risk management; Information strategy

1. Introduction

As discussed in an earlier paper (Gibb, Buchanan, & Shah, 2006), processes and associated services lie at the
heart of delivering an enterprises strategy. Processes consist of sets of activities which are designed to deliver
value to customers. These processes are dependent upon human resources to initiate, enact and control specic
activities, and on infrastructure, material, nancial and information resources to provide the context and
inputs from which value can be created (Vancoppenolle, 2001). Processes cross traditional functional and
organisational boundaries and must be effectively integrated, monitored and protected if breakdowns at
handover points and interfaces are to be avoided. Processes are also highly dependent on information and
technology, and failures of underlying systems can be both costly and embarrassing:

 Hi-tech companies in Silicon Valley lost systems and data when they were hit by a series of electricity
failures in January 2001 which cost in excess of $100 m (Faragher, 2001).
 The Woolwich was unable to cope with a sudden growth in its lending activity, a situation which was
exacerbated by underlying systems problems with direct debits, which affected thousands of its mortgage
customers (Steiner, 2002).
 WorldPay, a credit card transaction processing service, was subject to a denial of service attack involving
millions of e-mails generated by gangs in the Ukraine (Computer Crime Research Center, 2003).
Corresponding author.
E-mail address: forbes.gibb@cis.strath.ac.uk (F. Gibb).

0268-4012/$ - see front matter r 2005 Elsevier Ltd. All rights reserved.
doi:10.1016/j.ijinfomgt.2005.11.008
ARTICLE IN PRESS
F. Gibb, S. Buchanan / International Journal of Information Management 26 (2006) 128141 129

 The Halifax suspended its share dealing service ShareXpress when it was discovered that customers could
access other customers accounts following a failed attempt to repair a software bug (MacIver, 2003).
 Online betting companies in the UK have been threatened with denial of service attacks and the sending of
pornographic e-mails in their names unless they paid a ransom (Pesola, 2004).

Business continuity management (BCM) is a tool that can be employed to provide greater condence that
the outputs of processes and services can be delivered in the face of risks. It is concerned with identifying and
managing the risks which threaten to disrupt essential processes and associated services, mitigating the effects
of these risks, and ensuring that recovery of a process or service is achievable without signicant disruption to
the enterprise. The following sections describe a step-by-step approach to the design, implementation and
monitoring of BCM within the context of an information strategy.

2. A framework for BCM

Various authors have proposed different development cycles for BCM, each of which places emphasis on
particular aspects of BCM (CCTA, 1995; Barnes, 2001; Hiles & Barnes, 2001; Starr, Newfrock, & Delurey,
2002; Smith, 2002). The framework described here draws on these approaches and experience in the eld. Each
phase is illustrated in terms of a standard template which highlights the key activities that must be undertaken,
and the associated inputs and outputs. The phases (some of which will overlap) are:

1. Programme initiation.
2. Project initiation.
3. Risk analysis.
4. Selecting risk mitigation strategies.
5. Monitoring and control.
6. Implementation.
7. Testing.
8. Education and training.
9. Review.

2.1. Programme initiation

2.1.1. The programme charter


BCM should be an enterprise-wide activity yet research by Guardian IT has revealed that two-thirds of
enterprises view BCM as an IT issue rather than as an overall business issue. As a result inadequate resources
may be allocated to BCM until the effects of the loss of a critical IT resource are experienced. It is therefore
important to establish a programme of business continuity measures, and the CIO can have a key role in
championing this cause and helping to identify and publicise best practice.
A BCM programme should be the responsibility of a senior manager, ideally at director level, who should
lead the development of a charter for BCM. A charter is a top-level, strategic document which provides the
context for specic initiatives and guidelines for their delivery. This should be publicised in documents, such as
the annual report, to provide condence to investors regarding the enterprises attitude and readiness to deal
with risk. The charter will require input from many parts of the business and should be developed by a team of
representative stakeholders which should include the CIO (see Fig. 1).
Key steps in developing the charter are mapping business processes and associated resources, developing
guidelines, and establishing appropriate monitoring and control mechanisms. The importance of a process
map has been discussed in a previous paper (Gibb, Buchanan, & Shah, 2006) and is key to ensuring that
information resources are available and utilised. It will also help to develop a common vocabulary which is
shared and understood by process stakeholders. Business process owners must also be established to ensure
that BCM remains relevant and current with respect to the enterprises activities. For instance changes in
processes may introduce new risks or make aspects of the current plans redundant. Any devolution of
ARTICLE IN PRESS
130 F. Gibb, S. Buchanan / International Journal of Information Management 26 (2006) 128141

Inputs Key activities Outputs

Agreed key processes


Checklist of key external
Define and agree regulatory issues
Business strategy programme scope, Agreed ownership and
roles, responsibilities accountability matrices
Information strategy
and processes Business assumptions and
Policies and procedures expectations
Identify and specify Risk analysis toolkit
Regulatory regimes guidelines for Resource allocation and
accounting procedures
Organisational structure conducting BCM
Testing cycles and procedures
Review cycles and procedures
Processes and work flows Establish monitoring Training and induction policy
and control Documentation and reporting
Accounting standards
mechanisms policy
Compliance auditing procedures
Change control procedures

Fig. 1. The programme charter.

Inputs Key activities Outputs

Agreed prioritised initiatives

Project leaders
Business strategy
Project sponsors
Information strategy Collect stakeholder
input Terms of reference for
Financial plans
initiatives
Collect, merge and
Programme charter
assess business Cost-estimates
Business expectations priorities
Timetable
Scope programme
Business priorities
plan Dependency matrix
Customer and stakeholder
maps Documentation templates
and standards

Communication plan

Fig. 2. The programme plan.

responsibility will need to be supported by clear handover and succession procedures. Reporting mechanisms
and audit trails will have to be established to ensure that compliance can be demonstrated, particularly to any
external body which forms part of the regulatory regime.
The charter should establish budgeting principles and dene how potential overruns should be reported and
handled. The enterprise will also need to ensure that authority to spend is explicit in terms of individuals, the
ceilings to which they can spend, and the mechanisms needed in the event that conventional procurement
processes are disrupted. Services will change in line with market requirements, new regulatory demands,
improved technologies, etc. Review cycles for specic BCM plans will therefore need to be specied in order to
ensure that the components of the BCM programme are credible, relevant and cost-effective.

2.1.2. Programme plan


Once the programme charter has been specied the team will need to develop a programme plan (see Fig. 2).
This programme plan will specify, within the context of the charter, what, how and when specic BCM
projects will be initiated, who will run them, and how they will be nanced. The enterprise will have to assess
the criticality of specic processes in order to identify where investments should be directed. This will require
gathering stakeholder views to complement the expectations outlined in the programme charter and business
strategy.
Each project should have a project sponsor who is responsible for authorisation of expenditure and
acceptance and sign-off of project deliverables. The sponsor should be the agreed business owner of a process
ARTICLE IN PRESS
F. Gibb, S. Buchanan / International Journal of Information Management 26 (2006) 128141 131

and should facilitate access to both internal and external stakeholders. An initial estimate of the costs of each
initiative will need to be made for budget planning purposes in consultation with the project sponsors. Howe
(2001) suggests that a 515% buffer should be built into the estimates which should include lines for
development, implementation, training, testing, management and maintenance. Simon, Hillson and Newland
(1997) suggest that risk management should represent 15% of total project costs where BCM is being carried
out prospectively rather than just retrospectively.
Business continuity will introduce changes to working practices, and the workforce and selected customers
should be kept aware of when and how projects will be initiated. Acceptance of, and commitment to, business
continuity procedures by employees will be important to avert suspicion and to encourage co-operation.
Customers should be pleased to hear about increased service levels but may also need to be re-assured about
existing provision and upgrades, and that their opinions are considered to be both relevant and important.

2.2. Project initiation

Once the programme has been dened, the prioritised projects can be initiated following standard project
management methodologies. As with the programme charter a signicant amount of background data and
information will need to be gathered in order to initiate each project plan (see Fig. 3). Background data about
the process or service, and the resources needed to deliver it, will need to be collected. The development of a
portal which consolidates this information should be considered to facilitate access to information at the
desktop and when the BCM team is in the eld.
The goals of the project will dene the expected outcomes of the project and should reect the expectations
of the key stakeholders in the process or service. The associated objectives should be specic, measurable,
attainable, relevant and time-based (i.e. SMART) targets which can be used to measure the degree to which
the project plan is realising its goals. It will be essential to build teams which contain a wide range of skills as
BCM is a multi-disciplinary activity. Skills which may be required include those relating to human resource
management, legal and contractual issues, nancing, IT, procurement, estates, communications and
presentation, interviewing and elicitation, and actuarial and statistical methods. As more detailed information
is gathered, more accurate gures should be generated regarding development, implementation, training,
testing, management and maintenance costs.

2.3. Risk analysis

Risk analysis can be broken down into three distinct phases: risk identication, risk evaluation and business
impact analysis (BIA). This requires the team to identify events, the causes of these events and calculate the
consequences of these events (see Fig. 4).

Inputs Key activities Outputs

Business strategy
Information strategy
Programme charter
Programme definition Process/service knowledge
Existing plans and procedures Develop survey base
Vendors and service providers instruments
Project scope
Staff lists
Organisational chart and Gather background
data and information Goals and objectives
locations
Insurance coverage and policies
Create knowledge Team
Annual reports
base
Regulators codes of practice Budget and resource allocation
Stakeholder expectations
Identify business
Off-site facilities Survey instruments
needs and benefits
Key customers
Infrastructure descriptions Evaluate existing Workpackage descriptions
(architectures, configurations plans
floor-plans, inventory, etc.) Timetable and milestones
Maps Develop project plan
Events list (actions and impact) Deliverables
Contracts (suppliers and
customers)
Vital records schedule

Fig. 3. Project initiation.


ARTICLE IN PRESS
132 F. Gibb, S. Buchanan / International Journal of Information Management 26 (2006) 128141

Inputs Key activities Outputs

Programme charter

Programme definition

Project specification Identify risks


Technology architecture Evaluate risk
Risk register
impacts
Application architecture
Probability and impact scales
Estimate probability
Process map and workflows
of risk Probability-impact scores
Building plans
Estimate frequency
Prioritised risks
Maps of localities of risk

Generic risks checklist Calculate risk scores

Statistics on risk

Interviews

Fig. 4. Risk analysis.

2.3.1. Risk identification


Risks can be classied in a number of ways (see for instance: Vancoppenolle, 2001; OHehir, 2001;
Institution of Civil Engineers and the Faculty and Institute of Actuaries, 1998). Whatever typology is used to
categorise risks it is important to start with an exhaustive list. Risks can be broadly separated into those which
are naturally occurring and those which are the result of articial, man-made events. Naturally occuring risks
can in turn be divided into those which are generated by meteorological or geophysical conditions and those
which are generated by organic entities. Articial risks can be divided into those which are generated
accidentally and those which are the result of an intentional and generally malicious act. The enterprise should
create a risk register and any assessments and mitigation strategies associated with them. This will help to
ensure a consistency of approach across projects within the programme as well as saving time and effort in
arriving at credible measurements of risk.

2.3.2. Risk evaluation


This phase should concentrate on estimating and evaluating the likelihood of occurrence, likely frequency of
occurrence, and business impact of individual risks. This will require the project team to evaluate how
technological assets are congured and where they are located, to analyse building plans and local maps, and
to look at how applications are congured and accessed in order to identify potential points of failure and, in
particular, single points of failure.
The calculation of risk is a complex exercise and will require both operational data and external data on, for
instance weather statistics or crime gures. The probability of risk should be based on the context of the
process or service being evaluated. For instance, a terrorist attack on premises is more likely in the City of
London than in the centre of Glasgow, while ooding will be more likely in Norwich than in Zurich. The same
risk may therefore have different values associated with similar services which are located in different parts of
the enterprise. The likelihood of a threat will depend on a wide range of factors including (for intentional acts)
the motivation, capability, opportunity and resources of an individual and (for accidental acts) the location
and quality of systems, personnel and procedures. A wide range of methodologies can be used to identify,
evaluate and assess risks within an enterprise. These include qualitative techniques such as the Delphi
technique and quantitative techniques such as Monte Carlo analysis (Simon et al., 1997). A common set of
tools and methodologies should be selected to ensure that there is comparability across the enterprise and to
facilitate risk analysis for specic initiatives. Familiarity with a common tool set will reduce opportunity costs
and speed the risk analysis process.
The basis for the estimates should be recorded in the risk register and a condence factor attached to them.
Estimates with lower condence factors should be reviewed to see whether more reliable data are available
since the last evaluation took place. Risk review will also be necessary to reect changes in the operating
environment. A good example of how risk can alter is that of power supply: power problems are estimated to
ARTICLE IN PRESS
F. Gibb, S. Buchanan / International Journal of Information Management 26 (2006) 128141 133

be responsible for over 80% of IT downtime and power outages are increasing. Meanwhile the demand for
power is rising: large server farms consume the power equivalent of a town of 100,000 people. However,
wholesale prices for power have fallen by up to 40% in the UK in recent years. As a result, the margin of
excess capacity over peak demand has shrunk from 25% to 18% and generating capacity has been mothballed
to save costs (similar changes have taken place in the US). Fluctuations in prices, government policy, global
unrest, diminishing resources and climate change will all need to be regularly reviewed.
The calculation of estimates can also be based on simulations or on informed opinion from relevant
stakeholders. Simon et al. (1997) recommend the use of the Delphi technique for establishing group-based
consensus on the likelihood and impact of risks. Alternative approaches include the use of scenario planning
and internal and futures markets.
The next step is to establish the effects and impacts of a risk event. The effects of a risk are the damage or
loss that may occur to a process or service, while the impacts of a risk are the business consequences. In many
cases the impact may be simply a temporary failure to achieve service levels which has no long-term
consequences. However any sustained loss of continuity is likely to result in one or more of the following:

 nancial loss: e.g., the loss of orders for a period of time, additional costs to recover service, loss of market
share, etc.
 reputational damage: e.g., loss of goodwill or credibility, political or corporate embarrassment,
compromised health and safety, etc.
 legal action: e.g., contractual breaches, personal details being made public and infringing data protection
legislation, etc.

These impacts may also have to be contextualised to reect different supplier and customer perspectives.
For instance, the loss of automated teller machines (ATMs) for a clearing bank in the UK will result in the
bank incurring costs of 30 p per transaction when customers use competitor ATMs. However, independent
providers of ATMS would lose the surcharge of 1.001.50 per transaction that they impose on customers.
The inability to deal with the impact of a risk may lead to a ripple or escalation effect. If a process or service
is not recovered within a short space of time other processes and services may become compromised. It will be
important to establish whether there is a point of no return at which it will be impossible to reverse the damage
being caused by the disruption as the effects escalate. Processes and services which are particularly vulnerable
will be those where there are single points of failure or major dependencies on third party service providers.
Finally, the analysis will have to consider the impact of combinations of risk. This will require calculations for
both independent (i.e. the risks do not inuence the likelihood of each other) and dependent (i.e. the
occurrence of a risk will effect the occurrence of another) risks (see Fig. 5). A risk model can then be built to
calculate the enterprises exposure to risk.
Once estimates for the likelihood of risks and their impacts have been established, it will be possible to scale
and group these risks in order to identify priorities for investment. There are several methods available
(Beatty, 2001; Charters, 2001; Humpidge, 2001; Institution of Civil Engineers and the Faculty and Institute of
Actuaries, 1998; Simon et al., 1997), the most popular approach being to use a matrix. Simon et al. (1997) use
a ve-point scale for the probability of the occurrence and severity of the impacts of risk. A score for each risk
can then be calculated by multiplying the probability by each impact using a weighting for each point on the
scale. They recommend a linear scale for probability and a logarithmic one for impact as shown in Table 1. It
should be emphasised that the scores which are achieved have no absolute meaning; they are simply a method
of indicating the relative seriousness of individual risks.

2.4. Selecting risk mitigation strategies

This phase deals with identifying and evaluating the options for dealing with the risks identied in the
previous phase (see Fig. 6). These approaches can be divided into two classes: those which proactively deal
with risk by transferring, minimising, absorbing or pooling it (see Fig. 7), and those which react to risk events
through disaster recovery plans. For each risk there may be one or more solutions for mitigation. Option
appraisal will have to be undertaken to assess the impact of the solution and the value that it will generate in
ARTICLE IN PRESS
134 F. Gibb, S. Buchanan / International Journal of Information Management 26 (2006) 128141

Fig. 5. Risk combinations.

Table 1
PI score matrix (Simon, Hillson, & Newland, 1997)

Probability

Impact VLO 0.1 LO 0.3 MED 0.5 HI 0.7 VHO 0.9

VLO 0.05 0.005 0.015 0.025 0.035 0.045


LO 0.1 0.01 0.03 0.05 0.07 0.09
MED 0.2 0.02 0.06 0.10 0.14 0.18
HI 0.4 0.04 0.12 0.20 0.28 0.36
VHI 0.8 0.08 0.24 0.40 0.56 0.72

Inputs Key activities Outputs

Programme charter

Programme definition

Project specification

Information strategy
Risk mitigation strategies
Technology architecture
Option identification Disaster recovery plans
Application architecture
Option appraisal Emergency response teams
Process map
Command and control structure
Building plans

Maps of localities

Prioritised risks

Incident reports

Fig. 6. Selecting risk mitigation strategies.

cost savings or protected revenues. It will be essential to look at the effect that the solution will have on the
level of risk and the consequences of the risk. Solutions may also introduce their own risks and will have to be
evaluated using the procedures applied in the risk analysis phase. For instance some technologies may be
scarcer in the marketplace or may require specialist and/or scarce skills to implement. The costs of each
ARTICLE IN PRESS
F. Gibb, S. Buchanan / International Journal of Information Management 26 (2006) 128141 135

Mitigation of Risk

Transfer Risk Minimise Risk Absorb Risk

Insurance Outsourcing
Pool Risk Allocate
Contingency
Funds
Redundancy Improved Improved Improved
IT and Information Security
Facility System
Management Procedures
Procedures

Fig. 7. Risk mitigation strategies.

solution will have to be considered and compared with the nancial savings expected from reducing or
eliminating the risk.

2.4.1. Transferring risk


Transferring risk (or part of the risk) is generally achieved through insurance and outsourcing. Insurance
policies have had to adapt to advances in technology and now cover risks ranging from extortion, viruses and
hacking. It may also be desirable to insure the company against the loss of key personnel (Gascoigne, 2000).
For instance, the renaissance of the mainframe has created a shortage of skills capable of operating legacy
systems as experienced personnel retire and often take with them decades of experience which is not readily
transferable to more recent recruits. More recently there has been a trend towards outsourcing part or all of
the development and management of processes and services. Outsourcing is the transfer of responsibility to a
third party for the provision of a service which used to be carried out by an enterprises own staff. However,
outsourcing introduces new types of risk and these will have to be assessed as part of the overall cost.

2.4.2. Minimising risk


Minimising risk can be achieved by reducing it, eliminating it, or by avoiding it altogether. Redundancy is
typically used to eliminate single points of failure by building more components and nodes into a system. The
key components of a system will be: data, the application, storage, servers, the communications network, and
utilities. However, there is a danger that BCM only considers core devices such as servers. Evaluation of
devices at the edge of networks (e.g. desktops machines, local switches) should be undertaken to establish their
criticality.
Data redundancy will take the form of back-ups which may be cached, retrievable from online media or
loadable on request from ofine media. Applications may be available from alternative hot systems or
executable on demand. The storage media may be replicated in the form of disk duplexing or redundant arrays
of individual disks (RAID) on individual servers to provide fault tolerance, or in the form of generations of
back-up tapes. Servers may, in turn, be clustered to allow for server failure.
The criticality of the data and applications will dictate the complexity and costs of the congurations which
are used to ensure high availability and integrity. For instance many to one replication may be acceptable for
data generated across a LAN in an ofce environment while one to many replication may be used for mission-
critical applications where 24  7 availability is essential. Real-time back-up of data will be essential for such
applications but this is restricted by distance and a cascaded approach which provides strength in depth may
have to be adopted. Typically this will involve production servers replicating to a local high availability server
and also to an off-site server to provide contingency against, for instance, the catastrophic loss of power in a
city or destruction of a building complex.
Fault-tolerant hardware incorporates duplicate components such as fans, power units, disks and hot
swappable memory which can automatically take over in the event of component failure. The new generation
of fault-tolerant hardware is based around autonomic systems which have the capability to self-congure, self-
optimise, self-heal and self-protect. Communications networks can be hardened by using a high level of
ARTICLE IN PRESS
136 F. Gibb, S. Buchanan / International Journal of Information Management 26 (2006) 128141

meshing to ensure that there are alternative transmission paths in the event of congestion or link failure.
Multiple points of entry to critical facilities should also be considered as well as back-up communications such
as dial-up and voice over IP. The loss of a third-party telecommunications service provider may be addressed
by having dual or multiple contracts.
Around 43% of data loss is caused by problems with power and IBM estimates that a typical computer
experiences more than 120 power problems a month (Coult, 2001). There are minor to major variations in
power supply in the form of spikes, blackouts, brownouts and surges. Although many of the major
manufacturers build in a degree of tolerance, protectors should be considered for key devices. Uninterruptible
power supplies (UPS) will be essential for servers and other critical devices while back-up generators will be
needed to deal with longer power outages.

2.4.3. Absorbing risk


There may be circumstances where it is uneconomic or impossible to transfer, eliminate, reduce, or avoid a
risk. In these circumstances, the enterprise will have to absorb the risk and allocate appropriate nancial
contingencies to deal with the risk should it occur. Alternatively it may be possible to pool the risk with a
number of other enterprises by, for instance, sharing an off-site hot facility.

2.4.4. Disaster recovery plans


A threat may materialise into an active attack which is able to circumvent or negate the protective measures
which have been put in place. The aim of the enterprise will be to identify when the process or service has been
compromised at as early a stage as possible, to contain the threat, and to reduce the possibility of ripple and
escalation effects. It may then be necessary to initiate disaster recovery procedures and re-establish the
performance of the process or service. This will require the development of comprehensive disaster recovery
plans which specify the policies and procedures which should be invoked when a disaster occurs. It should be
recognised that conventional reporting and authorisation channels may not be available and alternate
mechanisms for establishing communications will need to be considered. This may include the use of pagers,
automated text messaging, and emergency numbers where pre-recorded messages can advise on the
availability of staff and contact numbers. Reporting protocols should also be established for customers,
suppliers, regulators, investors and the media.
Disaster recovery requires establishing the resources (staff, accommodation, utilities, etc.) needed to achieve
a minimum acceptable, and then full, level of service. The acceptable time to recover a process or service is
often referred to as the recovery time objective (RTO) and the acceptable transaction loss as the recovery point
objective (RPO). Although processes and services may cross many functions and sites Barnes (2001) advises
that there should be one plan for each building in order to simplify identication of the resources needed to
restore a facility. The plan should be dened in a continuity handbook (Coult, 2001) which should include
procedures for invoking the plan, securing a site, salvaging assets, etc. It should also provide essential factual
information such as oor plans, inventories of information assets, lists of personnel, succession lists, recovery
teams, etc. This will have to be supported by facilities for ordering and paying for goods and services at short
notice and probably in large quantities.

2.5. Monitoring and control

The BCM strategy will require an effective communication, command and control structure to be in place to
ensure that the requirements of the plan are translated into action (see Fig. 8). The monitoring and control
phase is concerned with assuring that:

 existing staff have been appropriately trained and that new staff are inducted into the relevant BCM
procedures (see Section 2.6),
 testing is undertaken to the agreed levels and cycles (see Section 2.7),
 risk reduction measures are put in place (see Section 2.8),
 procurement of technologies and services takes place in line with the requirements of the risk mitigation
strategies (see Section 2.8),
ARTICLE IN PRESS
F. Gibb, S. Buchanan / International Journal of Information Management 26 (2006) 128141 137

Inputs Key activities Outputs

Programme charter

Programme definition
Education and training
Ensure governance programme
Project specification
of BCM
Testing regime
Information strategy Assure BCM
requirements are Incident reports
Risk mitigation strategies
met
Review regime
Disaster recovery plans

Emergency response teams

Fig. 8. Monitoring and control of BCM.

 effective incident reporting is in place (see Section 2.9) including both successful and unsuccessful risk
management.

2.6. Implementation

This phase is concerned with putting in place any improvements to operating procedures, infrastructure,
security, etc., which can help to transfer, minimise or absorb the risks of processes and services being
compromised (see Fig. 9). The plan will require ratication by the risk manager, process owner and
programme manager and may involve secondary project management to specify, select, procure and monitor
implementation of additional technologies and services. Procurement of the necessary technologies and
services to achieve the plan will pass through the standard request for proposal (RFP), request for tender
(RFT) or invitation to tender (ITT) cycle. This phase should ensure that BCM is integrated with the systems
development life cycle where new projects are being initiated (Witty, 2001). This phase is also concerned with
ongoing testing of any recovery plans once they have been made fully operational. Other activities include
arranging insurance cover and ensuring that documentation about the BCM plan is up-to-date and accessible.

2.7. Testing

Testing of risk mitigation strategies and disaster recovery plans should be carried out both regularly and
comprehensively to see whether the plans are still relevant and deliverable (see Fig. 10). As a minimum, plans
should be tested within 3 months of implementation and thereafter on an agreed cycle of not more than 1 year.
Testing can be desk-based, technology oriented, and process or service oriented. In all cases a report should be
generated which evaluates the effectiveness of the tested components of plans and highlights areas that need to
be addressed with recommendations for action.
In desk-based testing the accuracy of the plans can be established by carrying out a walk-through of
procedures, and checking contact details, call trees, familiarity with the plan and its components, clarity of
instructions, times to initiate and respond, etc. This can be a low-cost exercise with low stress and minimal
involvement of staff. In the UK the Financial Services Authority undertakes a sector-wide desk-based exercise
on an annual basis to test the preparedness of the key nancial services companies in the event of a major
disruption.
Technology-oriented testing is concerned with ensuring that all hardware elements are operating and that
they still have appropriate capabilities. For instance back-up devices should be tested to see that they request,
receive and store data, and that the data is recoverable. Similarly, back-up power supplies should be tested to
see that the generators run, that fuel is clean and available in sufcient volume, and that they have been
ARTICLE IN PRESS
138 F. Gibb, S. Buchanan / International Journal of Information Management 26 (2006) 128141

Inputs Key activities Outputs

Track costs and


resource utilisation Financial reports
Issue RFT/RFP
Select suppliers Contracts with suppliers
Programme charter Implement risk
management Insurance policies
Programme definition strategies
Implement disaster Disaster recovery plan
Project specification recovery plans implementation logs

Risk mitigation strategies Co-ordinate with Risk mitigationstrategy


project managers for implementation logs
Disaster recovery plans new systems
Arrange insurance Variance reports
cover
Document Progress reports
implementation

Fig. 9. BCM implementation.

Inputs Key activities Outputs

Establish business
expectations

Programme charter Develop Testing assumptions


measurement
Programme definition criteria Testing scope

Project specification Develop testing plan Testing objectives

Risk mitigation strategies Negotiate availability Testing schedule


of staff and material
Disaster recovery plans resources for test Testing procedures

Training materials Brief staff in Testing targets


affected areas
Interviews Test report
Conduct test

Debrief staff

Fig. 10. Testing BCM.

regularly maintained. Technology testing is a higher cost exercise but can be undertaken without involving
staff outside the technical functions.
Process- or service-oriented testing will involve testing the ability of staff to respond to selected threats or
events and to recover from the effects of these threats, and their familiarity with the plan. It should be accepted
that such tests will not be able to reconstruct the stressful conditions under which staff will have to operate,
and the way in which they will respond, in the event of a real crisis. However they will indicate the general
effectiveness of the plans and the minimum time that it will take to put them into operation.

2.8. Education and training

This phase is concerned with ensuring that the benets and objectives of the BCM strategy have been
communicated to the workforce and that education and training ensures that the objectives can and are being
achieved (see Fig. 11). Communication is vital as all stakeholders need to be aware of their roles and
responsibilities. In addition to educating staff about the purpose of, nature of, and their involvement in BCM,
there will be a requirement to provide training for specic staff in relation to particular processes and services.
New staff should have BCM training as part of their induction and existing staff should have re-orientation
training every 612 months, and when new procedures and systems have been implemented. For critical
processes self-assessment and or certication procedures should be considered.
ARTICLE IN PRESS
F. Gibb, S. Buchanan / International Journal of Information Management 26 (2006) 128141 139

Inputs Key activities Outputs

Structure training Training materials


Programme charter
events Training presentation
Programme definition
Develop instructional
Assessment materials
Project specification and assessment
material Training events
Risk mitigation strategies
Identify staff for
Attendance and certification
Disaster recovery plans training events
logs

Fig. 11. BCM education and training.

2.9. Review

This phase is concerned with ensuring that the BCM strategy is responsive to changes in business
requirements. New processes, applications, technologies and personnel all bring new risks and requirements,
and it is essential that the enterprise does not become complacent and fails to update its BCM procedures. The
review should be informed by operational data such as incident reports and should identify best practice and
successes as well as failures (see Fig. 12). It should also be kept informed about changes in the business
environment, business priorities and new projects. Some of the questions which the programme manager
should ask are:

 Is documentation effective and current?


 Is the project sponsor appropriate and involved?
 Do staff understand their roles and responsibilities?
 Are contact details for staff, vendors and service providers accurate and complete?
 Could nominated staff authorise and make purchases and allocate resources if required?
 Are vendor and service agreements still viable, credible and deliverable?
 Have back-up and testing procedures been followed?
 Are there staff with the authority to approve re-start of, and access to, off-site facilities?
 Are alternative communication channels available?
 Has succession been addressed?
 Is the plan regularly reviewed and updated?
 Are all critical components of production and service been addressed?
 Are we protecting components which are no longer critical?

The review phase should feed back to the programme and project managers as well as managers responsible
for the day-to-day running of services.

3. Conclusions

Business continuity management (BCM) is key to ensuring that an enterprise can protect itself against the
risks which are inherent in its environment. Enterprises are increasingly reliant on the availability of
information in order to provide services to customers. Effective information management requires developing
an environment within which information can be provided to any authorised person, anywhere and at any
time. The common thread between BCM and information management is that they are both concerned with
ARTICLE IN PRESS
140 F. Gibb, S. Buchanan / International Journal of Information Management 26 (2006) 128141

Inputs Key activities Outputs

Business strategy

Information strategy Identify changes in


processes and
Programme charter services
New or altered risk list
Programme definition Identify new business
requirements Priority areas for action
Project specification
Identify changes in Cost estimates
Risk mitigation strategies business environment
Timetable
Disaster recovery plans Highlight successful
handling of risk Balanced scorecard or
Testing regimes events similar benefits analysis

Education and training Highlight failure to


programme handle risk events

Incident reports

Fig. 12. Review of BCM.

being able to deal with uncertainty. The CIO therefore has a key role to play in both promoting the philosophy
of BCM and ensuring that information management incorporates effective plans, procedures and policies to
protect an enterprises key information assets. These assets include IT infrastructure, the applications that run
across this infrastructure, content (digital and non-digital), and information personnel. It is important to
emphasise that contingency plans must be in place for the loss of assets other than technology-based ones. The
ooding of an academic library, for instance, will require plans for the salvage, drying and restoration of rare
books and documents with a clear set of priorities for targeting material before exposure to water and
contaminants makes them non-recoverable.
The temporary or permanent loss of information personnel must also be considered as many parts of an
enterprise are reliant on scarce skills and experience. Some businesses have planned for the potential impact of
avian u on both their staff and on their customers (Jack, 2005). For instance, restrictions on travel may mean
an increased reliance on online services and changes in work patterns and system loading. In the event of a
disaster, employees will be operating under stressful and unfamiliar conditions and may have to cope with the
loss of personal possessions and, in extremis, colleagues. Assistance with accommodation, transportation,
sustenance and counselling should all be factored into a disaster recovery plan. The location and deliberate
dispersal of staff is another issue, as whole disaster recovery teams were lost during the attack on the World
Trade Center.
In summary, a lack of investment in BCM can result in loss of revenue at best and cessation of business
activities at worst. The enterprise will need to consider:

 What is the worst thing that could happen to our business?


 Where would we be operating tomorrow if a disaster occurred?
 How quickly could our business reach the point of no return?
 How quickly can we return to business as usual?

The CIO must therefore ensure that plans are in place to protect information assets, and that rapid and
effective recovery of core business systems can be accomplished. The framework described above should assist
in this planning.

References

Barnes, J. C. (2001). A guide to business continuity planning. Chichester: Wiley.


Beatty, G. C. (2001). Emergency response and operations. In A. Hiles, & P. Barnes (Eds.), The definitive handbook of business continuity
management (pp. 179193). Chichester: Wiley.
CCTA. (1995). An introduction to business continuity management. London: HMSO.
ARTICLE IN PRESS
F. Gibb, S. Buchanan / International Journal of Information Management 26 (2006) 128141 141

Charters, I. (2001). Risk evaluation and control: II. Practical guidelines for risk assessment. In A. Hiles, & P. Barnes (Eds.), The definitive
handbook of business continuity management (pp. 131138). Chichester: Wiley.
Computer Crime Research Center. (2003). Hackers in attack on RBS credit card rm. Available from: http://www.crime-research.org/
news/2003/11/Mess0802.html, last accessed 23 December 2004.
Coult, C. (2001). Disaster recovery. Managing Information, 8(8), 3639.
Gascoigne, C. (2000). Safeguard the indispensable. Financial Times, 25 October, 12.
Hiles, A., & Barnes, P. (2001). The definitive handbook of business continuity management. Chichester: Wiley.
Howe, J. (2001). Project initiation and management. In A. Hiles, & P. Barnes (Eds.), The definitive handbook of business continuity
management (pp. 107122). Chichester: Wiley.
Humpidge, P. (2001). Why have a disaster if you dont have to? In A. Hiles, & P. Barnes (Eds.), The definitive handbook of business
continuity management (pp. 7589). Chichester: Wiley.
Institution of Civil Engineers and the Faculty and Institute of Actuaries. (1998). Risk analysis and management for projects. London:
Thomas Telford.
Jack, A. (2005). Avian u danger highlights continuity planning. Financial Times, 3 October, 10.
MacIver, K. (2003). The UKs ten worst web application failures. Information Age, May, 3640.
OHehir, M. (2001). Effective risk management and BCP drivers. In A. Hiles, & P. Barnes (Eds.), The definitive handbook of business
continuity management (pp. 2542). Chichester: Wiley.
Pesola, M. (2004). Child porn blackmail threat to website. Financial Times, 27 October, 1.
Simon, P., Hillson, D., & Newland, K. (1997). PRAM: Project risk analysis and management guide. Norwich: APM Group.
Smith, D. J. (Ed.). (2002). Business continuity management: Good practice guidelines. Caversham: Business Continuity Institute.
Starr, R., Newfrock, J., & Delurey, M. (2002). Enterprise resilience: managing risk in the networked economy. Strategy and Business, 30,
7379.
Steiner, R. (2002). Woolwich growing pains hit customers. Sunday Times Business, 27 October, 1, 13.
Vancoppenolle, G. (2001). What are we planning for? In A. Hiles, & P. Barnes (Eds.), The definitive handbook of business continuity
management (pp. 324). Chichester: Wiley.
Witty, R. (2001). Integrating BCP into the IT project life cycle. Gartner. Available from http://www4.gartner.com/DisplayDocument?
doc_cd 98830.

Forbes Gibb is a Professor of Information Science in the Graduate School of Informatics at the University of Strathclyde. He has been
involved in several major EU-funded research projects (SIMPR, STAMP, AUTOSOFT, MIND) and teaches in the areas of information
strategy, service management, and content management. He is currently Director for the M.Sc. in Strategic Information Systems, a course
which was designed for, and delivered exclusively to, the Royal Bank of Scotland.

Steven Buchanan is an Information Systems Lecturer in the Graduate School of Informatics, University of Strathclyde. He has carried out
consultancy work and research in the areas of information strategy, information systems development, and information audits. He has
worked across Europe and throughout Australasia for a number of public and private sector organisations, spanning telecommunications,
nance, education, local government, and microelectronics. He has previously held executive positions within two global ICT consultancy
and professional services organisations (SMS Management & Technology and Ericsson Edgecom Australia).

Вам также может понравиться