Framework library · Operations and resilience
Business continuity planning
Business continuity planning starts from a business impact analysis: for each activity, how long the business can survive without it, and so how quickly it must be recovered and how much data it can afford to lose. Plans, workarounds and tests follow from those numbers, and the test that counts is whether a real recovery has ever met them.
Use it when
- A failure at one site, system or supplier would stop activities customers depend on, and nobody has written down how long that could last.
- A customer, regulator or insurer asks for evidence of recovery objectives and tests.
- Spending on recovery (a second site, backups, standby contracts) needs to be ranked by what it protects.
- A recent incident took far longer to recover from than anyone expected.
Avoid it when
- You need to decide how to lead through an incident as it unfolds. That is crisis management; continuity plans feed it but do not replace it.
- The question is how likely each disruption is. Use a risk register for likelihood. The impact analysis assumes the disruption happens.
- Only one system needs a recovery plan. A disaster recovery runbook for that system is enough.
How to run it
List the activities that deliver to customers
Activities, not departments or systems: "customer access to the halls", "billing". Name one owner for each.
Set the maximum tolerable period of disruption
The maximum tolerable period of disruption (MTPD) is how long before the damage (contractual, financial, safety, reputational) becomes unacceptable. It is a business judgement, made by the owner and signed off by the sponsor.
Set recovery objectives inside it
The recovery time objective (RTO) must be shorter than the maximum tolerable period, with room for the time it takes to decide to invoke the plan. The recovery point objective (RPO) is how many hours of data you can afford to lose.
Record dependencies and workarounds
The people, sites, systems, suppliers and data each activity needs, and how to keep going by hand until it is back.
Test, and record the time achieved
A tabletop exercise checks the plan; a live recovery checks the objective. Enter the recovery time the last live test actually achieved.
Close the gaps or accept them
Where a test misses its objective, invest, change the objective, or have the sponsor accept the risk in writing.
Work through it
Answer the questions below, or load the worked example to see a finished one. The drawing updates as you type. Export the result as a PowerPoint deck, a Word document, an Excel workbook, a PDF or plain text.
What you type stays in this browser, so you can close the page and come back to it. It is not sent to Blue Prysm or anyone else, and the exports are made here, on your device. Privacy policy.
Mistakes to avoid
- Setting a recovery time objective longer than the maximum tolerable period. The plan would bring the activity back after the business has already failed. The register flags any such line.
- Counting a plan as tested when only the document was reviewed. Record the time a live recovery achieved, or leave it blank as untested.
- Missing the dependency that sits in the same place as the thing it protects, such as monitoring servers in the hall they monitor.
- Letting the analysis go stale. Re-run it when the business changes, and at least once a year.
Where it comes from
No single originator. The current international reference is ISO 22301:2019, Security and resilience: Business continuity management systems: Requirements (the second edition, replacing ISO 22301:2012), with guidance on business impact analysis in ISO/TS 22317:2021. The terms used here (maximum tolerable period of disruption, recovery time objective, recovery point objective) follow common practice. The standards themselves are not reproduced. Source.
Use it with
Further reading
Work through it with us
The frameworks here are free to use as they stand. If you would rather work through the question behind this one with us, these are the ways an engagement starts.