Fig Group · Practical resource
Business-continuity template and exercise example
A business-continuity plan describes how to maintain priority activities during disruption and restore normal operation safely. Start with service impact and dependencies, agree recovery objectives and test the fallback with the people who will use it.
By Fig Group · Updated
The example is fictional and its recovery targets are illustrative. Agree targets through your own business impact analysis. A completed template is not proof of resilience or ISO 22301 certification.
Identify what must continue
Name priority activities, accountable owners, minimum staffing, systems, data, sites and supplier dependencies. Explain how disruption affects customers, staff and obligations over time. A long list of applications does not replace that impact analysis.
Agree a recovery time objective (RTO) for restoring a service and a recovery point objective (RPO) for acceptable data loss measured in time. Record the maximum tolerable disruption separately and check that proposed recovery targets and dependencies support it. A backup schedule alone does not establish an achievable RTO.
Worked example: booking-service outage
| Planning field | Fictional example | Evidence or action |
|---|---|---|
| Priority activity | Receive and manage customer appointments | Operations lead confirms minimum service and customer impact |
| Recovery objective | Illustrative RTO: four hours; illustrative RPO: one hour | Validate against actual impact, contractual needs and recovery tests |
| Dependency | Hosted booking service, identity provider and staff access | Identify correlated failures and a trusted supplier escalation route |
| Fallback | Telephone intake with a protected temporary booking log | Test capacity, access controls, duplicate handling and later reconciliation |
| Recovery evidence | Restore and reconcile a recent test export | Measure elapsed recovery and data gap; record failures as actions |
Run a tabletop exercise
| Exercise point | Inject | Expected decision or evidence |
|---|---|---|
| Start | Booking service is unavailable; duration is unknown | Name the lead, start the log, assess impact and contact the supplier |
| After 15 minutes | Supplier cannot confirm restoration time | Decide when to activate fallback and communicate the next update |
| After 30 minutes | Two staff cannot access the fallback log | Test an authorised alternative; record access and capacity gaps |
| Recovery discussion | Service returns with missing recent bookings | Reconcile duplicates and missing data before approving return to normal |
| Debrief | Compare observed results with agreed targets | Record actual timings, failures, owners, due dates and a retest |
Example result: record a failed assumption
Illustrative result: the team reached its contacts, but the fallback log was held behind the unavailable identity service. Record that as a failed dependency assumption. Assign the operations lead to arrange an approved alternative, test access with deputies and schedule a retest. Do not report the plan as effective just because the exercise took place.
Use fictional customer records during the exercise. In a real disruption, protect personal information in temporary workarounds and reconcile it safely when the main service returns. Link the continuity plan to incident response when the cause may be malicious.
Prepare a plan you can test
Agree impact and recovery objectives
Identify priority activities, owners and dependencies. Agree minimum service, tolerable disruption, RTO and RPO with the business.
Document activation and fallback
Name the decision-maker and deputies, reliable contact methods, fallback instructions, resource needs and return-to-normal criteria.
Exercise and improve
Run a safe scenario, measure what happens, record failed assumptions and assign corrective actions. Retest before claiming the gap is closed.
Copy or download the template
Use the blank worksheet in your own document editor. Replace the prompts with your organisation’s details, obtain the relevant approvals and keep a controlled copy.
BUSINESS-CONTINUITY PLAN Organisation / plan version / owner / approver / review date: Priority activity and minimum acceptable service: Impact over time / maximum tolerable disruption: Agreed RTO / RPO and rationale: People / site / systems / data / supplier dependencies: Lead / deputy / contact method / out-of-hours cover: Activation triggers and authority: Fallback instructions and required resources: Customer/staff/supplier communication owner and cadence: Data protection for temporary processes: Recovery sequence / verification / reconciliation: Return-to-normal authority and criteria: EXERCISE RECORD Date / facilitator / participants / scenario / safety limits: Inject | Time | Expected response | Observed response | Evidence Service outage | | | | Uncertain restoration | | | | Fallback inaccessible | | | | Missing data at recovery | | | | Actual recovery time and data gap: Objectives met / not met / not tested: Lessons and failed assumptions: Corrective action | Owner | Due date | Verification | Retest date Plan changes and approval:
Explore the workflow in Fig Group
Fig Group’s continuity capability connects business impact, service dependencies and exercise management. Bring this scenario to a demonstration to explore owners, recovery objectives, exercise findings and follow-up evidence. Confirm the agreed scope and configuration; recording a plan cannot guarantee service recovery.
Common questions
What is the difference between RTO and RPO?
RTO is the target time to restore a service. RPO describes the acceptable data-loss window in time. Both need business agreement and practical validation against dependencies.
How often should we test the plan?
Set a risk-based exercise schedule and review it after material changes or incidents. Retest failed assumptions and record what was actually tested rather than treating attendance as success.
Sources and further reading
Use the current source guidance alongside your own requirements when completing the worksheet.