A business continuity plan explains how an organisation will continue priority products and services at an acceptable level during disruption, then return to normal operations. A useful plan is built from an approved scope, a business impact analysis, recovery objectives, named decision-makers, tested workarounds, and evidence that the arrangements are maintained.
ISO 22301:2019 remains the published business continuity management-system standard, with a 2024 amendment; ISO also lists a future revision as under development. NIS2 Article 21(2)(c) separately requires in-scope entities to address business continuity, including backup management, disaster recovery and crisis management. Neither source makes one generic document sufficient for every organisation.
What the plan must decide
Start with decisions people will need during an interruption:
- which products, services and legal obligations take priority;
- the minimum acceptable operating level for each priority activity;
- who may activate the plan, spend emergency funds and accept residual risk;
- which people, facilities, technology, information and suppliers each activity depends on;
- how teams communicate if ordinary channels are unavailable; and
- what conditions allow restoration, validation and formal stand-down.
Avoid treating the plan as a directory of phone numbers. It should give responders usable criteria, authorised options and current references to detailed technical runbooks.
Build the business impact analysis
Interview process owners and validate their answers with operational data. For each activity, record the impact of interruption over time, peak periods, dependencies, manual workarounds and any legal or contractual deadlines.
Define recovery terms consistently:
| Term | Decision it records |
|---|---|
| Maximum tolerable period of disruption | The point beyond which the impact is unacceptable |
| Recovery time objective (RTO) | The target time for restoring an activity or resource |
| Recovery point objective (RPO) | The maximum acceptable data-loss interval |
| Minimum business continuity objective | The acceptable capacity or service level during disruption |
An RTO is a target, not proof of capability. Compare it with measured restoration time, supplier commitments and staffing constraints. If the current capability cannot meet the target, record and fund the gap.
Select and document recovery strategies
Choose strategies after the impact analysis, not before it. Options can include alternate sites, remote operation, redundant infrastructure, offline backups, substitute suppliers, cross-trained personnel, manual processing and prioritised service degradation.
For each strategy, document:
- activation criteria and authority;
- required people, access, equipment and data;
- the sequence for continuity and recovery;
- dependencies and assumptions;
- communications and escalation; and
- validation criteria before service is declared restored.
Cyber incident response, disaster recovery, crisis management and business continuity overlap but are not interchangeable. A cyber incident plan manages the security event; a disaster-recovery runbook restores technology; the continuity plan keeps priority operations running.
Plan for suppliers and shared dependencies
List critical third parties and the service, data, location or concentration risk each introduces. Review continuity evidence proportionate to the dependency: recovery commitments, test summaries, notification duties, subcontractors, exit assistance and data-return arrangements. A supplier's certificate or questionnaire answer is useful evidence, but it does not prove your end-to-end service can recover.
Link supplier findings to your vendor-risk programme and give high-impact gaps an owner and deadline.
Exercise, measure and maintain the plan
Set an exercise schedule from risk, change and obligations rather than claiming one frequency fits all. Use different formats:
- walkthroughs to check roles, contacts and assumptions;
- tabletop exercises to practise decisions and communications;
- technical recovery tests to measure restoration and data integrity; and
- integrated simulations to test cross-team and supplier dependencies.
After each exercise or activation, record what happened, actual recovery times, decisions, evidence, corrective actions, owners and due dates. Retest material fixes. Review the plan after major system, supplier, location, product or regulatory changes and confirm controlled copies remain accessible during an outage.
Practical plan structure
- Document control, scope and objectives
- Activation, escalation and stand-down criteria
- Incident and crisis roles with alternates
- Priority activities and approved recovery objectives
- Dependencies, resources and supplier contacts
- Continuity strategies and manual workarounds
- Technology recovery references
- Internal, customer and authority communications
- Return-to-normal and validation steps
- Exercise, review and corrective-action log
The best next step is to test one priority service end to end. That quickly exposes hidden access, data, staffing and supplier assumptions.
Sources and review
This guide was substantively reviewed on 8 August 2026. It distinguishes plans, targets and demonstrated capability and does not claim that ISO 22301 or NIS2 imposes a universal template or exercise frequency.
Robert Lozo, mag. iur., is a Partner at Vision Compliance specializing in EU regulatory compliance. He advises organizations on GDPR, NIS2, AI Act, and financial regulation, delivering audit-ready documentation and compliance roadmaps across regulated industries.