Business Continuity Plan (BCP): How to Implement It with Dedicated Software
A Business Continuity Plan (BCP) is the set of documented procedures, strategies, and resources that enable an organisation to continue its critical activities following a disruption and recover them within defined timeframes. ISO 22301:2019, Security and resilience, Business continuity management systems, Requirements, sets the international standard for a Business Continuity Management System (BCMS). It applies to any organisation that wishes to demonstrate its ability to maintain continuity during disruptions and to reduce the likelihood and impact of incidents. Beyond voluntary adoption, business continuity is increasingly a regulatory obligation: DORA and NIS2 that require continuity plans for financial and essential entities represent the two most significant European frameworks that mandate BCPs with specific content and testing requirements. Organisations in scope of both ISO 22301 and DORA or NIS2 must align their BCP to both frameworks; a single document that satisfies one but not the other creates compliance gaps. Optivalue.ai provides the structured workspace to build, test, and maintain a BCP that meets the requirements of ISO 22301 and the applicable regulatory frameworks.
Business Impact Analysis: Identifying Critical Processes
The Business Impact Analysis (BIA) is the diagnostic step that precedes the BCP. Clause 8.2 of ISO 22301:2019 requires organisations to determine the activities that are critical to delivering their key products and services, and to identify the maximum tolerable period of disruption (MTPD), the recovery time objective (RTO), and the recovery point objective (RPO) for each critical activity. The BIA must be conducted with the business units that own each critical process; the outputs are only reliable when the owners of the process validate them. A BIA that is produced by the business continuity team alone, without input from operational owners, will underestimate dependencies and overestimate recovery capability. Optivalue.ai guides each process owner through a structured BIA questionnaire, consolidates the outputs into a prioritised list of critical activities, and links each activity to its recovery strategy.
Recovery Strategies: Choosing and Documenting Scenarios
Clause 8.3 of ISO 22301:2019 requires organisations to determine and select strategies and solutions that enable them to protect prioritised activities and their supporting resources, and to restore them within defined timeframes. Recovery strategies must be designed for each critical activity identified in the BIA; they must cover personnel, premises, technology, information, and supply chain dependencies. Each strategy must be assessed for feasibility and cost before selection; a strategy that is selected but not resourced is not a strategy. The chosen strategies must be documented with the resources required, the named owner responsible for activation, and the activation conditions. A scenario that has not been documented cannot be activated reliably during a crisis.
Testing and Exercises: Why and How Often
Clause 8.5 of ISO 22301:2019 requires organisations to confirm that the BCP procedures are in place and functioning by conducting exercises. Exercises may take several forms: tabletop exercises (discussion-based, no operational disruption), functional exercises (testing specific functions or processes), and full simulation exercises (testing the entire response and recovery capability). Each exercise must be planned, conducted, evaluated, and documented; the evaluation must identify gaps between planned and actual performance. Lessons from each exercise must be incorporated into the BCP before the next scheduled review. DORA requires financial entities to test their ICT business continuity plans periodically and to document the results; NIS2 requires essential entities to test their response and recovery capabilities. The regulatory watch that identifies new continuity obligations is the mechanism that keeps the BCP aligned with evolving regulatory requirements.
How Software Structures BCP Documentation, Testing and Updates
Business continuity software addresses three problems that a document-based approach cannot reliably solve: accessibility (plans must be available during a crisis when normal systems may be unavailable), completeness (every critical activity must have a plan with named owners and documented resources), and maintenance (plans must be updated after exercises, incidents, and organisational changes). A plan that exists only in a shared drive that requires network access is not accessible during a network outage. Optivalue.ai provides offline-accessible plans, version-controlled documentation that records the history of every update, an exercise management workflow that tracks planning, execution, evaluation, and lesson incorporation, and a notification system that alerts named owners when their plan requires review. The platform connects the BIA outputs to the recovery strategies, the strategies to the exercise schedule, and the exercise results to the improvement backlog.
Book a demonstration with Optivalue.ai
FAQ
What is the difference between a BCP and a disaster recovery plan?
A Business Continuity Plan (BCP) covers the full range of activities required to maintain and restore the organisation's critical business functions following any type of disruption, including loss of premises, personnel, technology, or supply chain. A disaster recovery plan (DRP) or IT disaster recovery plan focuses specifically on the recovery of IT systems and data. The DRP is a component of the BCP; a BCP that covers only IT recovery is incomplete. ISO 22301 explicitly distinguishes between business continuity, which includes operational and organisational recovery, and IT recovery. Organisations regulated under DORA must address both the ICT dimension and the broader operational continuity dimension.
Who should own the BCP in an organisation?
Ownership of the BCP typically sits with a business continuity manager or a dedicated business continuity function; in smaller organisations, it may sit with the chief operating officer, the chief risk officer, or the IT director. Individual plan components must be owned by the business unit or function responsible for the relevant critical activity; the BCP owner is responsible for the overall framework and the exercise programme, but cannot substitute for the operational owners who must validate recovery times and resources. Governance (board or executive committee) must approve the overall BCP and the acceptable levels of disruption defined in the BIA.
How does ISO 22301 relate to DORA and NIS2?
ISO 22301:2019 provides the international management system framework for business continuity. DORA (Regulation (EU) 2022/2554) imposes specific ICT business continuity requirements on financial entities, including written ICT business continuity plans, documented crisis communication plans, and periodic testing. NIS2 (Directive (EU) 2022/2555) imposes business continuity obligations on essential and important entities in critical sectors. An organisation that implements ISO 22301 has a structural framework for meeting the continuity requirements of DORA and NIS2, but must verify that its BCMS satisfies the specific content requirements of each regulation. ISO 22301 certification does not substitute for regulatory compliance under DORA or NIS2.
How often should a BCP be tested?
ISO 22301:2019 does not prescribe a fixed exercise frequency; it requires organisations to plan, conduct, and document exercises at intervals appropriate to their business continuity objectives. In practice, a minimum annual exercise cycle is common for critical plans; exercises of different intensity may be alternated across the cycle. DORA requires ICT business continuity plans to be tested at a frequency determined by the financial entity's risk assessment. NIS2 requires essential entities to test their response and recovery capabilities, with a frequency to be specified in national transpositions. Organisations subject to multiple frameworks should adopt the most demanding frequency and document its rationale.
What is the maximum tolerable period of disruption?
The maximum tolerable period of disruption (MTPD) is defined in ISO 22301:2019 as the duration after which an organisation's viability will be at risk if a product or service cannot be delivered. It is determined by assessing the impact of extended disruption on stakeholders, contractual obligations, regulatory requirements, and financial position. The MTPD sets the outer boundary for recovery; the recovery time objective (RTO), which is the target time for resuming a critical activity, must be shorter than the MTPD. Both are outputs of the Business Impact Analysis and must be validated by the business unit owners of each critical activity.
Back to top