When a site, system or supplier fails, an organization needs to know what must continue, at what capacity and within what time. ISO 22301 helps organize these decisions through a business continuity management system. This article explains how priorities become usable arrangements, and how exercises reveal the difference between a written plan and an actual ability to recover.
What does ISO 22301 organize?
ISO 22301:2019 specifies requirements for a Business Continuity Management System (BCMS). It addresses preparation for disruption, response and continued delivery of products and services at a predefined acceptable capacity. ISO’s official page also lists a 2024 amendment titled “Climate action changes.” Check the standard and its amendments when establishing your implementation reference. The amendment is not a separate edition called ISO 22301:2024.
Start with an operational question: which service would cause unacceptable consequences if it stopped? Assign its owner and define its boundaries, locations and suppliers. Management needs to approve priorities, provide resources and resolve conflicts between them. Asking a coordinator to write plans is insufficient when funding and operational decisions sit outside that person’s authority.
Business impact analysis: what recovers first?
Business Impact Analysis (BIA) examines the consequences of interrupted activities over time. Gather information from process owners and challenge it against order records, deadlines and commitments. A short interruption might be manageable during a quiet period but damaging near a critical delivery deadline. Record these differences instead of applying one estimate to every circumstance.
Identify when impacts become unacceptable, then set recovery objectives before that point. Connect each activity to the people, data, equipment and approvals it needs. Avoid assigning the highest priority to everything: that hides the trade-offs the organization will face when resources are scarce. You can begin with one service and expand the analysis after checking the quality of the information.
Recovery time and data recovery point are different
The Recovery Time Objective (RTO) sets the target time for restoring an activity or resource to its agreed level after disruption. In a data context, the Recovery Point Objective (RPO) identifies the point in time to which data must be recovered. With a 15-minute objective, recovery should not depend on data older than 15 minutes before the outage.
Starting a server does not mean a service is ready. Teams may still need to validate data, sign users in, reconnect interfaces and test a complete transaction. Specify the required service level alongside the time objective, such as the number of orders that can be processed. These objectives come from organizational needs; the standard does not prescribe one recovery time for every organization.
Turn disruption risks into workable alternatives
Risk assessment asks what could interrupt activities and how it could happen. Scenarios might include losing a site, an essential skill or a shared supplier. Impact analysis helps prioritize recovery according to the consequences of interruption. Use both: risk assessment informs prevention and scenario preparation, while impact analysis clarifies continuity priorities.
Compare alternatives by time, capacity, cost and dependence on other parties. Can the alternate site accommodate the team? Does the backup supplier actually have available stock? Do both telecommunications providers use the same route? Seek evidence proportionate to the importance of each assumption, such as an operational trial or a capacity check. A contract or a supplier’s name in a table does not demonstrate readiness.
Write a plan people can use under pressure
Define activation conditions, the decision owner and deputy, initial actions, authority limits and escalation arrangements. Keep contact details and the approved plan accessible when the usual system is unavailable. To check usability, give the plan to a qualified person who did not write it. Ask them to identify their first action and whom they would contact.
Coordinate emergency response, crisis management, technical recovery and operational continuity. Protecting people remains a priority; a recovery target never justifies unsafe operation. Decide who updates customers, employees and suppliers, when updates are sent and who checks their content. Include the return to stable operations and reconciliation of accumulated transactions. Restarting the service is not the end of recovery work.
Hypothetical example: service restored, but was the objective met?
Suppose an order service has a target to resume within 4 hours at a minimum capacity of 20 orders per hour. Its data recovery point must be no more than 15 minutes before the interruption. These are illustrative assumptions, not client results or limits specified by the standard.
During an exercise, the team resumes service after 3 hours and 30 minutes and demonstrates processing 20 orders per hour. It meets the time objective with a 30-minute margin and the capacity objective under the exercise conditions. However, the newest recoverable data is 40 minutes older than the outage. This exceeds the target data window by 25 minutes: 40 − 15 = 25.
The result is a partial success requiring corrective action. The team investigates why the recoverable copy was outdated, determines how missing orders can be reconstructed and repeats the recovery test. Exercise success does not guarantee the same outcome during a real incident, when workloads and available resources may differ. Record assumptions and limitations alongside results so that a limited trial does not become a broad claim of readiness.
Exercises, improvement and certification boundaries
Choose an exercise suited to the risk and current capability: a discussion to test decisions, a simulation to test coordination or a technical recovery test. Define success criteria beforehand and collect timestamps and operational evidence. Attendance alone is insufficient. Assign an owner and deadline to each gap, then verify the effectiveness of the correction in a later test.
Connect exercise results, incidents and changes to internal audit, management review and plan updates. Review apparently small changes too, such as an essential employee leaving or a service provider being replaced. An organization can implement the system without pursuing certification. If certification is chosen, it concerns management-system conformity within a defined scope. It does not guarantee uninterrupted operations or a successful response to every incident. A contract or regulator may also create a certification requirement.
Practical questions before starting
Are backups enough?
They support data recovery but do not, by themselves, provide people, premises, authority or suppliers. Test the recovery of a complete service rather than relying on a successful backup-job notification.
Must every alternative be implemented immediately?
Sequence implementation by priorities and gaps, with a clear management decision on residual risks. Do not describe a planned or untested alternative as an available capability.
First step: test one service from end to end
Select a priority service and bring its owner together with the relevant technology, resource and supplier representatives. Agree recovery time, capacity and data needs. Review dependencies, then run a limited exercise with clear objectives. The difference between target and result will give you specific improvements to fund, track and test again.
