Primary navigation:

QFINANCE Quick Links
QFINANCE Reference
Add the QFINANCE search widget to your website

Home > Operations Management Best Practice > Business Continuity Management: How to Prepare for the Worst

Operations Management Best Practice

Business Continuity Management: How to Prepare for the Worst

by Andrew Hiles

Making It Happen

Phase One

The BC project should start with a clear understanding of the needs of the stakeholders and the support of the board. BC policy needs to be set.

A high-level steering group needs to be set up to decide priorities and define the scope of the project. For instance, is the objective to be “business as usual”—or will it just cover the 20% of goods or services that generates 80% of the profits? Will it cover all customers, or just the most important ones? Does it embrace all locations, or just head office? How far does it go down into the supply chain? Will it cover only local disasters, or is it to cope with wide area disasters—hurricanes, major floods, etc.?

Next, a project plan should be developed, identifying the milestones and deliverables of the project. These include:

  • risk and impact assessment;

  • agreeing BC strategies;

  • developing the BCP and implementing contingency arrangements;

  • audit and exercising the BCP.

A budget can be established for Phase One from a knowledge of how many sites are to be covered, how many people are to be interviewed, how many processes are to be included at each site, and an assessment of time for research and report-writing.

Risk and impact assessment can be broken down into subactivities:

  • identification of assets and threats to them;

  • weighting threats for probability and impact (in cash and non-cash terms);

  • identification of MCAs and their dependencies;

  • establishing the recovery time objective (RTO) for each (the maximum acceptable period of service outage);

  • establishing the recovery point objective (RPO) for each (the timestamp to which data and transactions have to be recovered);

  • identifying the resources needed for recovery and the timeframe in which they are required;

  • identifying any gaps between the RTO, RPO, and actual capability (for example, the IT backup method may not permit recovery within the RTO);

  • establishing the organization’s appetite for risk;

  • making recommendations for risk management and mitigation;

  • making recommendations to close any gaps revealed.

The risk and impact assessment is usually conducted by analysis of building plans and operational layouts; review of reports on audit, health, safety, and environmental and operational incidents; interview of key personnel; and physical inspection.

Once these activities have been completed, possible contingency arrangements can be considered. The instinctive reaction is to replicate existing capability—but there may be more cost-effective options.

Holding buffer stock could cover equipment downtime. Increased resilience and “hardening” of facilities may reduce risk to an acceptable level. Items or services could be bought-in, rather than undertaken in-house. Contracts could be placed with commercial BC service vendors for standby IT, telecommunications and work area recovery requirements.

The risk and impact assessment then forms the basis for a cost–benefit analysis of the contingency options and allows a BC strategy to be recommended and agreed.

This report, incorporating the findings and recommendations from the risk and impact assessment, forms a natural close to Phase One. Usually there is a natural break while recommendations are considered and the budget for Phase Two is agreed.

Phase Two

Once the BC strategy has been agreed, the BC plan can be started, bearing in mind what constraints may be placed on your organization by emergency services, public authorities, regulators, and landlords and other occupants (if you occupy a building with more than one tenant).

Incident and emergency management plans (for instance, evacuation, fire, bomb threat, etc.) need to be consistent with the BCP, and there needs to be escalation processes from them into the BCP. Triggers should also be identified for escalation from customer complaints, failure of service-level agreements, problem and incident management processes, etc., into the BC process.

The BC organization may not necessarily mirror the normal organization—for instance, multidisciplined teams may be appropriate—and the BC manager or coordinator may not usually hold the level of authority they are accorded under disaster invocation.

Typically the board will be separated in two: one to manage the ongoing business, the other to deal with the disaster situation. The emergency, crisis or business continuity management team (BCMT) will include board-level decision-makers. These include members from business and support units, and the BC manager (effectively the project manager for recovery) will report to them.

Business and support unit teams, including ICT, will report on recovery progress and seek clarification, information and support from the BC manager. The BC manager will resolve any priority clashes within his or her authority and refer others to the BCMT.

Table 1 is a partial example of a BC organization. Additional BC teams will be created as necessary to cover each MCA, business or support unit.

The overview at Table 1 needs to be amplified by detailed action plans covering each BC team.

BC Management team

Leader: BC management team leader Alternate   Members: CFO Alternate COO Alternate P RO Alternate Marketing director Alternate Estates manager Alternate: TBD Admin support: TBD   Reports: BC manager Alternate   Roles: Consider group (corporate) impacts. Manage recovery. Coordinate all team action. Consider safety and security and environmental issues. Decide on priorities. Reassure media and authorities.
IT team Leader: TBD Alternate: TBD   Members: Applications manager Alternate PC Servers/LAN manager Alternate Data/voice communications manager Alternate: TBD Admin support: TBD   Roles: Recovery of all platforms, systems applications and data at standby site: TBD Data/voice communications recovery at standby site: TBD Base site recovery team Leader: TBD Alternate: TBD   Members: Office services manager Alternate PC Servers/LAN Alternate: TBD Data/voice communications Alternate: TBD Damage assessment/salvage Alternate Loss adjuster: TBD Admin support: TBD   Roles: Damage assessment, limitation and salvage Recovery at base site Recovery of operational capability at base site IT, data/voice communications recovery at base site

TBD – to be determined

The BCP coordinator is not necessarily the same person who will be BC manager once the BCP is completed. The BCP coordinator’s role is to ensure that all BCPs are completed consistently and comprehensively.

The BCPs should not be scenario-based, since the disaster is unlikely to fit neatly into any scenario envisaged. Instead, they should be based on a worst-case scenario: total loss of MCAs. However, if they are developed in a modular fashion, if a lesser disaster happens, only that part which is relevant can be invoked.

The BCP coordinator will draft a BCP for the BCMT and for his or her BC activities, including BCP invocation procedure, and will provide advice and guidance to the business and support unit BC coordinators.

Next, a template BCP should be developed that can be used for each team. Once they have had training, BCP development coordinators for each business and support unit complete these. A support program can be created for their guidance as they develop their BCPs.

Each BCP should spell out assumptions so they may be challenged (for example, an assumption that more than one site will not suffer a disaster at the same time; or that skilled people will be available post-disaster).

The minimum content should include:

  • prioritized MCAs and a credible action plan for their recovery within RTO and RPO;

  • lists of team members, alternates, roles, and contacts;

  • resource requirements and when and how they are to be obtained;

  • contact details of internal and external contacts;

  • information on relevant contracts and insurance;

  • reporting requirements;

  • instructions on handling the media;

  • any useful supporting information (such as damage assessment forms; maps and information about alternate sites; detailed technical recovery procedures).

Once the BCPs have been developed they can be audited, reviewing each BCP for comprehensiveness, clarity, and accuracy. This also ensures that interrelationships between BCPs are reflected in the counterparty BCP.

Rigorous exercises probe BCP effectiveness under different disaster scenarios and provide realistic training for BC team members.

Lessons from BC audit and tests should be incorporated into the BCPs. Where this has not yet been done, a list should be provided at the beginning of the BCP stating what weaknesses were found to exist; who is responsible for rectifying them; and the timeframe for doing so.

The BCP may take many forms: hard copy; handheld devices; memory sticks, etc. Whatever the format, it should be kept secure, and steps should be taken to ensure that only the current version can be held.

Back to Table of contents

Further reading


  • Hiles, Andrew. Business Continuity: Best Practices—World-class Continuity Management. Brookfield, CT: Rothstein Associates, 2007.
  • Hiles, Andrew. The Definitive Handbook of Business Continuity Management. 2nd ed. Chichester, UK: Wiley, 2007.
  • Hiles, Andrew N. Enterprise Risk Assessment and Business Impact Analysis: Best Practices. Brookfield, CT: Rothstein Associates, 2002.
  • Von Roessing, Rolf. Auditing Business Continuity—Global Best Practices. Brookfield, CT: Rothstein Associates, 2002.



  • BS 25999 Business Continuity Management (UK)
  • HB 221 Business Continuity Management (Australia)
  • NFPA 1600 Emergency Management and Business Continuity (USA)

Back to top

Share this page

  • Facebook
  • Twitter
  • LinkedIn
  • Bookmark and Share