How to Build a Business Continuity Plan That Holds Up

This guide shows how to create a business continuity plan: a written record of the services the business needs, how long each can be down, and the named person who acts when one stops. Step 2 is a business impact analysis, a look at what each stoppage does to the business over time. The reader is an IT manager or business owner at a mid-size firm in India or the GCC. Perhaps the firm has no written plan, or only a template filled in once.

Why work stops in the first place is the subject of what stops a business. For scoring a plan once it exists, see reviewing a finished plan. The steps sit under the Signisys use case on planning for continuity and less downtime.

What a Business Continuity Plan Holds

It names the services the business needs and how long each can be down. It then says what keeps each one going, and who decides and who acts.

The AWS disaster recovery whitepaper says a disaster recovery plan should be a subset of the business continuity plan. In other words, it should not be a standalone document. For example, it describes an earthquake, where the transport of goods could stop even while the application stays up.

In Signisys’ working description, the plan covers people, premises, suppliers, systems and communication. Recovering IT systems is one part of it. For where that part ends, see how the two differ.

This guide is a method for writing the plan. It does not claim to meet, or to certify against, ISO 22301.

Two terms come up from here on:

• Business impact analysis: a look at what happens to the business, service by service, as a stoppage grows longer.
• Tolerated downtime: the longest a service can stop before its owner finds the loss unacceptable.

Business Continuity Plan Step 1: Scope, Owner and Sponsor

Start with one page that names the sponsor, the plan owner and a person from each department. The same page says what the plan covers: sites, teams and services. The sponsor is a senior person on the business side who backs the work and signs the result off.

Ready.gov’s planning page describes organising a continuity team and compiling a plan to manage a disruption. In addition, its training sets out six steps. The first three are to prepare, to define objectives, and to identify and prioritise risks and impacts.

Two decisions belong in this step. First, who may say “start the plan”? Second, who signs the finished plan off? Then write a name against each, and a deputy as well.

In Signisys’ working description, a plan with no business sponsor can turn into a document that IT owns.

For example, take a distributor in Dubai with a warehouse, a sales office and a finance team. It would name one person from each, with the managing director as sponsor. The scope line would then list the two sites and the services each one runs.

Business Continuity Plan Step 2: List the Services the Business Depends On

The output is a ranked list of services, such as order entry, payroll or customer support. Next to each one, write who depends on it. Then add the people, premises, suppliers and systems it needs.

Ranking them is the job of a business impact analysis. For each service, write what happens to the business as the stoppage grows longer. The AWS whitepaper says a business impact analysis should quantify the business impact of a disruption and identify the effect on internal and external customers. It adds that impact may depend on timing. For instance, its payroll example has a high impact just before pay day and a low one just after.

Set out your business impact analysis as a four-column grid. The cells below are prompts for each row, not data.

For the IT rows, use NIST’s contingency planning guide, SP 800-34 Rev. 1. It provides a business impact analysis template. It dates from May 2010, updated in November 2010. Its scope is federal information systems. Use it for systems rather than premises or people.

Business Continuity Plan Step 3: Set How Long Each Service Can Be Down

Ask each service owner how long the work can stop before the loss becomes unacceptable. Then write that figure next to the service. The owner decides the figure, while IT says what meeting it would take.

The AWS whitepaper adds that recovery objectives should not be set in isolation. It names the probability of a disruption among the factors that inform them. Two IT terms meet the business figure here. The recovery time objective is how long a system may take to return. The recovery point objective is how much recent data the business can afford to lose. In this plan, both feed only the tolerated-downtime column. For the full treatment, see recovery targets for data. Similarly, for help setting them, see the use case on meeting recovery targets.

From this step on, your business continuity plan grows into a grid, one column per step. The order of the rows comes from the business impact analysis in step 2.

For example, a payroll owner in Riyadh may give one figure for the week before pay day. The rest of the month may get a longer one. In that case, write both figures, with the dates each one covers.

Business Continuity Plan Step 4: Choose the Measure for Each Service

Pick one measure per service from five groups, and write it in the fourth column of the grid.

• People: cover and deputies for the people the service relies on.
• Premises: an alternate place of work, or remote work.
• Suppliers: a second source, or a fallback agreed in advance.
• Systems: where IT recovery sits for that service.
• Communication: how staff, customers and suppliers hear what is happening.

This guide makes no claim that any one measure is right. The choice belongs to the service owner, with IT advising on the systems row.

Systems recovery is one row among five here. For how keeping a system available differs from bringing it back, see high availability and recovery compared. The guide on how the two differ, linked above, covers the wider line.

For highly critical workloads on AWS, the same page says you might consider deploying across multiple Regions, with data replication and continuous backups in place.

For example, a clinic group in Bengaluru might choose remote work for its call centre. For test results, it might add a second laboratory. Each choice then needs its own owner and figure.

Business Continuity Plan Step 5: Assign Who Decides and Who Does

The output is a roster with a named lead and deputy for each role. It also holds the trigger for starting the plan, and a contact list. Four roles cover the decisions:

• Decision lead: decides when the plan starts and when it ends.
• Service owners: decide which measure their service uses on the day.
• Communications lead: decides what staff, customers and suppliers hear, and when.
• IT lead: decides the order in which systems come back, within the figures from step 3.

Next, write the trigger in plain words. Name the event, or the length of stoppage, at which the decision lead may start the plan. Then, for each audience, write who speaks and through which channel if the main one is down.

A cyber incident has its own first moves, and a separate plan covers them. For that case, see handling a cyber incident. In addition, keep the two plans pointing at each other.

Finally, ask one question about the roster itself. Who holds a printed or personal-phone copy of the roster?

For example, a retailer in Pune with stores in three cities might name a deputy decision lead in each city. The roster then shows who acts while the head office is out of reach.

Business Continuity Plan Step 6: Test It, Then Keep It Current

The output is a test schedule and a list of changes that trigger a review. Ready.gov’s continuity planning page lists exercise materials. These include test exercise planner instructions and a test facilitator and evaluator handbook. The same page says the Business Continuity Planning Suite is “no longer supported or available for download”. This guide offers no template either.

In Signisys’ working description, a first test is a tabletop exercise. Walk one service through the plan with the people named in step 5. As you go, write down each place where the plan said nothing. Then fix those gaps, and walk the next service through.

After that, keep the plan current. Review it when a system, a supplier, a site or a key person changes. That list of triggers is yours to set.

For testing the recovery of the systems themselves, see the use case on testing disaster recovery readiness.

Where This Plan Stops, and Who Can Give a Second View

This guide covers how to create a business continuity plan. It is not a template, a route to ISO 22301 certification or a guide to any sector’s rules. A regulated firm, for example in banking, should check its regulator’s rules first. This guide names no rule it has not read. Beyond that, causes of downtime, scoring a finished plan and data restore steps sit in the articles linked above.

Bring in specialist help when one of these is true:

• The business runs from several sites, and each site has its own owners.
• The firm is regulated, and the plan has to meet a stated rule.
• A service depends on a supplier the firm does not control.

Signisys provides business continuity services through its Business Continuity and Disaster Recovery solution and its consulting and managed services. This note describes a Signisys service, not neutral advice, and it makes no promise.

Frequently Asked Questions