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. 2. 3. 4. 5. 6. 7. 8. 9. Programme initiation. Project initiation. Risk analysis. Selecting risk mitigation strategies. Monitoring and control. Implementation. Testing. Education and training. 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

Business strategy Information strategy Policies and procedures Regulatory regimes Organisational structure Processes and work flows Accounting standards

Define and agree programme scope, roles, responsibilities and processes Identify and specify guidelines for conducting BCM Establish monitoring and control mechanisms

Agreed key processes Checklist of key external regulatory issues Agreed ownership and accountability matrices Business assumptions and expectations Risk analysis toolkit Resource allocation and accounting procedures Testing cycles and procedures Review cycles and procedures Training and induction policy Documentation and reporting policy Compliance auditing procedures Change control procedures

Fig. 1. The programme charter.

Inputs Key activities Outputs
Agreed prioritised initiatives Business strategy Information strategy Financial plans Programme charter Business expectations Business priorities Customer and stakeholder maps Collect stakeholder input Collect, merge and assess business priorities Scope programme plan Project leaders Project sponsors Terms of reference for initiatives Cost-estimates Timetable Dependency matrix 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
Business strategy Information strategy Programme charter Programme definition Existing plans and procedures Vendors and service providers Staff lists Organisational chart and locations Insurance coverage and policies Annual reports Regulators codes of practice Stakeholder expectations Off-site facilities Key customers Infrastructure descriptions (architectures, configurations floor-plans, inventory, etc.) Maps Events list (actions and impact) Contracts (suppliers and customers) Vital records schedule

Key activities

Outputs

Develop survey instruments Gather background data and information Create knowledge base Identify business needs and benefits Evaluate existing plans Develop project plan

Process/service knowledge base Project scope Goals and objectives Team Budget and resource allocation Survey instruments Workpackage descriptions Timetable and milestones Deliverables

Fig. 3. Project initiation.

ARTICLE IN PRESS
132 F. Gibb, S. Buchanan / International Journal of Information Management 26 (2006) 128141
Inputs
Programme charter Programme definition Project specification Technology architecture Application architecture Process map and workflows Building plans Maps of localities Generic risks checklist Statistics on risk Interviews Identify risks Evaluate risk impacts Estimate probability of risk Estimate frequency of risk Calculate risk scores Risk register Probability and impact scales Probability-impact scores Prioritised risks

Key activities

Outputs

Fig. 4. Risk analysis.

2.3.1. Risk identication 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.05 LO 0.1 MED 0.2 HI 0.4 VHI 0.8 VLO 0.1 0.005 0.01 0.02 0.04 0.08 LO 0.3 0.015 0.03 0.06 0.12 0.24 MED 0.5 0.025 0.05 0.10 0.20 0.40 HI 0.7 0.035 0.07 0.14 0.28 0.56 VHO 0.9 0.045 0.09 0.18 0.36 0.72

Inputs
Programme charter Programme definition Project specification Information strategy Technology architecture

Key activities

Outputs

Risk mitigation strategies Option identification Disaster recovery plans Emergency response teams Command and control structure

Application architecture Option appraisal Process map 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 missioncritical 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, selfoptimise, 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
Inputs Key activities Outputs

137

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

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

Programme charter Programme definition Project specification Risk mitigation strategies Disaster recovery plans

Track costs and resource utilisation Issue RFT/RFP Select suppliers Implement risk management strategies Implement disaster recovery plans Co-ordinate with project managers for new systems Arrange insurance cover Document implementation

Financial reports Contracts with suppliers Insurance policies Disaster recovery plan implementation logs Risk mitigationstrategy implementation logs Variance reports Progress reports

Fig. 9. BCM implementation.

Inputs

Key activities

Outputs

Establish business expectations Programme charter Programme definition Project specification Risk mitigation strategies Disaster recovery plans Training materials Interviews Conduct test Debrief staff Develop measurement criteria Develop testing plan Negotiate availability of staff and material resources for test Brief staff in affected areas Testing assumptions Testing scope Testing objectives Testing schedule Testing procedures Testing targets Test report

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
Inputs Key activities Outputs

139

Programme charter Programme definition Project specification Risk mitigation strategies Disaster recovery plans

Structure training events Develop instructional and assessment material Identify staff for training events

Training materials Training presentation Assessment materials Training events Attendance and certification 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
Business strategy Information strategy Programme charter Programme definition Project specification Risk mitigation strategies Disaster recovery plans Testing regimes Education and training programme Incident reports Identify changes in processes and services Identify new business requirements

Key activities

Outputs

New or altered risk list Priority areas for action

Cost estimates Identify changes in business environment Timetable Highlight successful Balanced scorecard or handling of risk similar benefits analysis events Highlight failure to handle risk events

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 denitive 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 denitive 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 denitive handbook of business continuity management. Chichester: Wiley. Howe, J. (2001). Project initiation and management. In A. Hiles, & P. Barnes (Eds.), The denitive 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 denitive 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 denitive 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 denitive 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).