Business continuity process flowchart: invoke to stand-down

What the business continuity process flowchart: invoke to stand-down process is

The business continuity process keeps an organisation delivering its critical functions while something is broken. It is not IT disaster recovery. Disaster recovery is the technical work of restoring systems and data (failover, backups, recovery point objectives) and it is one input to continuity rather than the whole of it. Many invocations involve no IT failure at all: a building is inaccessible, a single-source supplier stops, severe weather or industrial action removes most of a shift. The question this process answers is not "when will the system be back?" but "how do we keep serving customers until it is?"

The boundaries with neighbouring processes are worth stating plainly, because charts that blur them get ignored during an actual disruption. A single service outage inside normal tolerances belongs to incident management, which restores service against an SLA. A confirmed cyber attack belongs to security incident response, which owns containment, evidence and breach notification. Rebuilding or failing over the technology belongs to the disaster recovery runbook. Business continuity sits above all three: it decides that the disruption has crossed a threshold, prioritises which business activities are protected first, and runs the manual and workaround arrangements that hold the business together while the technical teams work.

Continuity processes usually fail in four predictable places, and the chart below is drawn to close them. Invocation is delayed because nobody agreed in advance who can invoke or against what criteria. Priorities are set by whoever escalates loudest instead of by the recovery time objectives already recorded in the business impact analysis. Workarounds exist on paper but the printed forms, offline data and manual approval limits they assume were never prepared. And resumption happens without agreed criteria, so the business goes back to normal with an unowned backlog. Five lanes (Incident management team, Business unit leads, BCM coordinator, Communications and Executive) carry the flow across five phases, with two decisions: whether to invoke the plan, and whether to resume normal operations.

What this flowchart covers

In this template

• Five swimlanes with a named owner for every step (Incident management team, Business unit leads, BCM coordinator, Communications and Executive) arranged across five phases: assess and invoke, mobilise, continuity operations, monitor and review, and recovery and learning.
• A measured front end: 'Disruption reported to duty manager' feeds 'Confirm affected sites and functions' and then 'Assess impact against continuity thresholds', so the trigger is tested against the business impact analysis rather than judged by feel.
• The 'Invoke the business continuity plan?' decision, whose below-threshold branch runs 'Manage within business as usual' and loops back to reassessment if the disruption escalates, so a near-miss is monitored instead of forgotten.
• Mobilisation once the plan is invoked: 'Convene incident management team', 'Prioritise critical functions from the BIA', 'Notify staff and account for people' in the Communications lane, and 'Authorise emergency spend and delegations' in the Executive lane.
• Continuity operations proper: 'Activate workarounds and manual processes', 'Arrange alternative sites and remote working', and 'Brief customers and key stakeholders': the steps that distinguish continuity from technical recovery.
• A status cycle and controlled exit: 'Review status at agreed intervals' feeds 'Resume normal operations?', where 'Not yet' goes to 'Extend continuity arrangements' and back to the next review, and 'Resume' runs restore and clear backlogs, stand down, confirm return to service, post-incident review, and ends on 'Update the BIA and continuity plan'.

When to use this template

• Writing or refreshing a business continuity plan and needing one page that shows who decides what, in what order, before the plan is read under pressure.
• Agreeing invocation authority and continuity thresholds in advance, including who deputises out of hours, so the first hour is not spent deciding whether this counts.
• Separating your continuity plan from your IT disaster recovery runbook, so each document covers its own scope and the handover between them is explicit.
• Running a tabletop exercise: the two decisions, the review loop and the lane handoffs give you something concrete to test and to break.
• Briefing business unit leads on what they are expected to do during a disruption, particularly the manual workarounds and the reconciliation that follows them.
• Preparing for a business continuity audit or a customer resilience questionnaire that asks you to show a documented, owned process.

How it works

1. Rename the lanes to your real response structure

   Replace Incident management team, Business unit leads, BCM coordinator, Communications and Executive with the roles you actually have — crisis management team, gold and silver commanders, site leads, a resilience manager, a duty director. Smaller organisations often merge the BCM coordinator into the incident management team lane; delete a lane rather than leaving it unstaffed.

2. Write down the invocation criteria and authority

   Open 'Invoke the business continuity plan?' and set your own test: the expected outage exceeds the recovery time objective for a critical function, or a site or supplier is unavailable beyond an agreed period. Name who can invoke, name the deputy, and give an out-of-hours contact route. An invocation criterion that needs a meeting to interpret will not be used at 3am.

3. Attach your business impact analysis to the prioritisation step

   'Prioritise critical functions from the BIA' is only as good as the analysis behind it. List your critical activities in recovery time objective order and record what each one depends on: people, premises, systems, data and suppliers. If a function's dependencies are unknown, that is the gap the next exercise should target.

4. Make the workarounds specific and provable

   Replace 'Activate workarounds and manual processes' with the named workaround for each critical function, its capacity limit, how long it can run and what it needs prepared in advance — printed forms, offline copies of key data, a manual approval limit. Add who reconciles the manual records once systems return, because the backlog is where continuity failures usually surface.

5. Set the status cadence and the resumption criteria

   Decide how often 'Review status at agreed intervals' fires — hourly at first, then longer as the situation stabilises — and what evidence 'Resume normal operations?' requires: capacity restored, staff and premises safe, backlog quantified and owned. Resuming without criteria is how a second disruption starts.

6. Exercise the chart, then publish an approved version

   Walk it through with each lane and correct the steps people actually perform, then run it as a tabletop scenario that has nothing to do with IT — a site closure or a supplier failure. Record what the exercise changes, feed it into 'Update the BIA and continuity plan', and publish the agreed version so everyone can see which revision is current.

Frequently asked questions

What is the difference between business continuity and IT disaster recovery?

Business continuity keeps business activities delivering during a disruption — people, premises, suppliers, customers, manual workarounds. Disaster recovery restores technology: systems, applications and data, measured with recovery time and recovery point objectives. Disaster recovery is one capability that supports continuity, not a substitute for it. A continuity plan is invoked for events with no technical cause at all, such as a building being unavailable or a critical supplier failing, and even during an IT outage the continuity question is how the business trades while the DR team works. In this chart that difference sits in 'Activate workarounds and manual processes': the technical restoration is happening elsewhere, on its own runbook.

Who decides to invoke the business continuity plan?

A named role with delegated authority, plus a deputy for out-of-hours cover. In this chart the decision sits with the BCM coordinator applying documented criteria, with the executive lane authorising emergency spend and delegations immediately afterwards; many organisations place invocation with an executive on call or a crisis lead instead. What matters more than the job title is that the criteria are written before the event and are objective enough for one person to apply at night. Invoking is a business decision with a cost, but the more common failure is invoking too late and losing the first hours to debate.

What are continuity thresholds and where do they come from?

They come from the business impact analysis. For each critical activity the BIA records how long it can be interrupted before the consequences become unacceptable — the maximum tolerable period of disruption, also called the maximum acceptable outage — and a recovery time objective inside that limit. A continuity threshold turns those figures into a trigger: if the disruption is expected to outlast the recovery time objective for a critical activity, the plan is invoked. Regulated firms may have an equivalent set externally; UK financial services operational resilience rules, for example, require firms to identify important business services and set impact tolerances for them.

How long should continuity arrangements run before returning to normal?

For as long as the resumption criteria are unmet, which is why the chart loops rather than assuming a fixed duration. 'Review status at agreed intervals' and 'Extend continuity arrangements' exist because workarounds have a shelf life: manual processing capacity, temporary premises and goodwill all degrade, and the backlog grows the whole time. Set the review cadence tight at the start and stretch it as the picture stabilises, and treat resumption as a decision someone signs rather than a drift back into old habits.

Does this template make us compliant with ISO 22301?

No. ISO 22301 is the international standard for business continuity management systems, and conformity depends on the whole system — leadership commitment, a business impact analysis and risk assessment, documented plans and procedures, exercising and testing, performance evaluation and improvement — not on any one diagram. A clear, owned process map supports several of those requirements and is useful evidence in an audit or a customer questionnaire, but it is a component of the management system rather than proof of it.