Clause 8 is the largest and most operationally consequential clause in ISO 22301. It is where business continuity capability is actually built. All the analysis in Clauses 4–7 — context understanding, leadership commitment, planning, and resource support — exists to enable what Clause 8 requires. If Clause 8 is not well executed, the BCMS is incomplete and capability does not exist, regardless of how thorough the planning was.
Clause 8 addresses: operational planning and control (ensuring continuity considerations are built into all relevant processes); business continuity strategy (the decisions about how to respond to and recover from disruption); business continuity plans (the detailed operational documents that guide recovery); crisis management integration (ensuring incident response and continuity activation work together); ICT continuity (ensuring technology recovery supports business recovery); and the exercise and testing programme (the mechanism through which capability is demonstrated and continuously improved).
The exercise programme is particularly important. A BCMS without exercises is a theory. An exercise that tests actual recovery capability, challenges assumptions, and identifies gaps is how capability becomes real. Organisations that conduct rigorous exercises annually and systematically implement findings have BCMSs that actually work. Organisations that conduct exercises every three years and do not track findings have BCMSs that satisfy certification requirements but would fail under real disruption.
Operational Planning and Control (8.1)
Clause 8.1 requires the organisation to plan, implement, control, and maintain processes needed to meet the BCMS requirements. This means continuity considerations must be embedded in how the organisation operates. When a new technology system is selected, continuity is evaluated as part of the selection criteria. When a supplier is chosen, their continuity capability is assessed. When staff are hired for critical roles, succession planning is initiated. When real estate decisions are made, continuity implications are considered.
Change management is a critical element of operational control. When the organisation makes significant changes — new systems, new suppliers, major staffing changes, new locations — the BCMS must be updated to reflect those changes. A BCP that is outdated because the organisation has moved to a new technology platform or added a new critical supplier is not an operational BCP. Change management ensures the BCMS stays current as the organisation evolves.
Outsourced processes must be treated consistently with internal processes. If a critical function is outsourced to a third party, the BCMS must address the outsourced function’s continuity. Supplier continuity requirements must be established and monitored. If a supplier cannot recover within the RTO required by the organisation, the outsourcing arrangement creates risk. Clause 8.1 requires the organisation to manage this.
Business Continuity Strategy (8.3)
The continuity strategy is the set of decisions about how the organisation will respond to and recover from disruption of critical activities. It is derived from the BIA and risk assessment: the BIA identifies what activities are critical and how long they can be unavailable; the risk assessment identifies threats and their likelihood; the strategy determines how to address these risks and meet the recovery time objectives.
Strategy decisions typically address five resource types: people (cross-training, succession planning, contractor agreements, remote working capability); premises (alternate site arrangements, work-from-home capability, mutual aid agreements); technology (redundant systems, cloud failover, hot/warm/cold standby, manual workarounds); suppliers (dual sourcing, contractual BCM requirements, supplier assessment); and finance (pre-approved credit lines, insurance, emergency procurement procedures).
For each critical activity, the strategy specifies: what resource strategy will be used to recover it (e.g., for payment processing, a hot-standby system in an alternate data centre); what the MBCO — minimum business continuity objective — is during recovery (e.g., 60% of normal transaction volume); what pre-positioned resources are required (systems, staff, equipment, information); and what the recovery sequence is (which activities are recovered first, which second, accounting for dependencies).
| Resource Type | Strategy Options | Selection Criteria |
|---|---|---|
| People | Cross-training in critical roles; succession planning; contractor agreements for rapid augmentation; remote working capability; mass casualty insurance | Availability of qualified people; training investment required; cost vs. risk of key person dependency; time to train vs. RTO requirement |
| Premises | Alternate site (owned or leased); mobile recovery facilities (vehicle-based); mutual aid agreements with partner organisations; work-from-home capability; reciprocal arrangements | Rent vs. ownership cost; geographic separation from primary site; site readiness (hot/warm/cold); compatibility with organisation’s operations |
| Technology | Redundant systems (two primary systems); hot standby (replica system running in parallel); warm standby (replica system ready to take over); cold standby (backup available but not running); cloud failover; manual workarounds | RTO requirement vs. system recovery time; cost of redundancy; complexity of failover; data consistency requirements; whether manual workarounds are acceptable temporarily |
| Suppliers | Dual sourcing (two suppliers for critical goods/services); contractual BCM requirements in supplier agreements; regular supplier BCM assessment; inventory buffers for critical items; alternate suppliers identified | Supplier market (how many qualified suppliers exist); cost of dual sourcing vs. risk of single supplier failure; feasibility of inventory buffers; lead time to switch suppliers |
| Finance | Pre-approved credit lines at banks; insurance (business interruption insurance, cyber insurance); emergency procurement procedures; contingency funds set aside; cost reduction plans if revenue is disrupted | Whether credit is available when needed (some banks deny credit during crises); insurance premium vs. risk; whether cost reduction plans are feasible without service disruption |
| Information | Regular backups with multiple copies; offsite backup storage (geographically separated); backup encryption and testing; document management system for critical procedures; redundant communications and data stores | Backup frequency (RPO requirement); offsite distance (must be far enough from primary location); backup testing frequency; access speed when recovery is needed |
Business Continuity Plans (8.4)
A Business Continuity Plan is an operational document that tells the people responsible for a critical activity exactly what to do to continue or recover that activity when normal conditions are disrupted. A compliant BCP must include: who activates it (the decision authority), what triggers activation (specific conditions or thresholds), the resources required for recovery (not normal operations — the reduced or alternate resources), step-by-step procedures in operational sequence, communication scripts for internal and stakeholders, and the criteria for standing down the plan and returning to normal operations.
BCPs must be specific to the activities they cover. A single “company BCP” that is too generic to guide actual recovery is not compliant. BCPs for payment processing, customer onboarding, risk reporting, and IT operations must each specify what those activities do, how they are disrupted, what the recovery looks like, and what decisions are required. A BCP without activation criteria is not a plan — it is a document.
A BCP typically includes several sections: executive summary (one-page overview of the plan); activation authority and criteria (who decides to activate, on what basis); roles and responsibilities during recovery (who does what, who makes decisions); step-by-step recovery procedures (in operational sequence, with decision points); communication procedures (who communicates what to whom); recovery site and resource details (where recovery happens, what resources are required); dependencies on other activities or systems (what other activities or systems must also be recovered); and criteria and procedures for ending the recovery and returning to normal operations.
| KEY IDEA | A Business Continuity Plan is not a disaster recovery plan and it is not an emergency response plan. It is an operational document that tells the people responsible for a critical activity exactly what to do to continue or recover that activity when normal conditions fail. It must include: who activates it, what triggers activation, the resources required at recovery (not at normal operations), step-by-step procedures in operational sequence, communication scripts for internal and external stakeholders, and the criteria for standing down. Plans without activation criteria are not BCPs — they are documents that look like plans but cannot be executed. |
ICT Continuity (8.5)
ICT continuity addresses the specific requirements for technology systems and infrastructure recovery. This includes: backup and recovery procedures that ensure data can be restored and systems can be restarted; testing of backup and recovery to ensure they work (a backup that has never been restored is not a tested backup); documentation of system interdependencies (which systems depend on which other systems); procedures for managing data during recovery (ensuring data consistency when using backup copies); and remote access capability for staff to work from alternate locations.
Recovery time objectives for technology systems must be achievable given the technology platform and backup strategy. A system with a 1-hour RTO requires either redundant systems, a warm standby, or very fast backup restoration. A system with a 24-hour RTO can use cold backups stored offsite and restored as needed. The relationship between RTO and technology strategy is explicit: if the RTO cannot be met with available technology, either the RTO must be revised or the technology investment must increase.
Technology recovery testing is critical. Many organisations maintain backups but have never tested whether those backups can actually be restored or whether restored systems can operate at the MBCO required by the business. Recovery testing — taking a backup and actually restoring it to an alternate system to verify that it works — is the only way to have confidence in recovery capability. This testing is distinct from exercises and should occur annually for critical systems.
Exercise and Testing Programme (8.5 continued)
The exercise and testing programme is the mechanism through which continuity capability is demonstrated and continuously improved. Exercises range from tabletop reviews (discussion-based) through functional exercises (deploying actual resources to a simulated event) to full simulations (activating plans as if a real event had occurred). Each type tests different aspects of the BCMS and reveals different gaps.
Exercises should test whether actual procedures work, whether resources are available and accessible when needed, whether staff know their roles, whether communication protocols function, whether recovery time targets can be met, and whether dependencies are correctly identified. A well-designed exercise includes inject scenarios — planned disturbances that stress the plan and force realistic decision-making. Exercises where everything works perfectly are pleasant but not informative. Exercises where communication fails, resources are unavailable, and staff are uncertain of their roles reveal the gaps that need to be addressed.
After each exercise, a structured post-exercise review captures findings, identifies improvement actions, assigns owners, and tracks closure. The most important BCMS quality indicator is not the number of exercises conducted, but the number of findings identified and the percentage of findings that are closed with real improvements implemented. Exercises drive improvement only when findings are tracked and acted upon.
| Exercise Type | Description | What It Tests | Frequency Guidance |
|---|---|---|---|
| Tabletop exercise | Walk-through of BCP with key stakeholders around a table; scenario is presented and decisions are walked through; people discuss what they would do without actually executing the plan | Plan logic, roles, decision-making authority, communication flows, whether procedure steps make sense, whether procedures match how the organisation actually operates | Minimum annually per critical BCP; good for initial testing or after significant plan updates |
| Functional exercise | Deploy actual resources (staff, systems) to a simulated disruption; staff work through their actual procedures; systems are actually used (though in a test environment); decisions are actually made | Operational procedures, resource availability and accessibility, team coordination, timing against RTO, whether procedures can be followed in practice, whether people understand procedures | Annually or after significant change; especially valuable for testing technical recovery and resource coordination |
| Full simulation | Declare a fictional continuity event and activate BCPs fully; staff report to recovery location, activate systems, follow procedures as if a real event had occurred; no prior warning to some participants | End-to-end capability, timing against RTO, recovery under pressure, decision-making when the stakes feel real, communication under stress, whether activity can continue at MBCO level | Every 2–3 years or on certification cycle; resource-intensive but most informative about real capability |
| Technical recovery test | Restore systems from backup to test RPO/RTO achievement; take actual backup copies and restore them to test systems; verify data integrity and system functionality after restoration; test failover procedures | Whether backups actually work, whether restoration time is achievable, whether data is correct after restoration, whether restored systems can operate, system interdependencies | Annually per critical system; often conducted outside of broader exercises; essential for confidence in technology recovery |
| Post-disruption review | Structured analysis of an actual disruption event, even if it did not trigger BCP activation; what happened, what worked, what failed, what needs to improve | Real capability revealed, whether plans reflected reality, actual recovery timing vs. assumed timing, whether decision-making was effective, what assumptions in plans were wrong | After every declared continuity event or significant disruption; the most valuable learning occurs during actual events |
| IMPORTANT | An exercise that does not generate improvement actions has not tested hard enough. Experienced BCM practitioners design exercises with inject scenarios specifically intended to stress the plan — communications failures, resource unavailability, supplier non-response, data that cannot be recovered, customer dissatisfaction. Exercises where everything works perfectly are pleasant but not informative. The improvement actions generated by a rigorous exercise — and the closure of those actions before the next exercise — are the mechanism through which the BCMS improves. ISO 22301 Clause 8.5 requires the organisation to act on exercise findings. Exercise findings that do not result in improvements indicate a BCMS that is not being actively maintained. |
Crisis Management Integration (8.4 continued)
The relationship between incident response (crisis management) and business continuity is critical. Incident response addresses the immediate response to an emergency: evacuating the building if there is a fire, calling IT security if there is a suspected cyber attack, activating communications channels if there is a major disruption. Business continuity addresses the recovery of critical activities to meet business objectives.
The boundary between crisis management and BCP activation must be clear. A fire in the building is handled through emergency procedures. If the disruption is brief, crisis management procedures alone suffice. If the disruption will last long enough to affect business continuity, the BCP is activated. The crisis management team makes the decision to activate the BCP based on the criteria defined in the plan.
Deactivation of the BCP (ending recovery and returning to normal operations) must also be planned. Decisions required include: when is the activity sufficiently recovered that MBCO is no longer needed; how quickly can normal operations resume; what is the transition procedure from recovery state to normal state; what is the post-incident review process to understand what happened and what needs to improve?
| BITLION INSIGHT | The most reliable indicator of a mature BCMS in Indonesian organisations is the exercise programme. Organisations that conduct exercises annually, use realistic Indonesian disruption scenarios (flooding, power outage, cyber incident), involve business unit heads not just the BCM team, and systematically track exercise findings to closure have BCMSs that actually work. Organisations that conduct exercises every three years, use generic scenarios, and do not track improvement actions have BCMSs that satisfy certification requirements but would fail under an actual disruption. The exercise programme is where BCM intent becomes BCM capability. Invest in it. |