How to Implement ISO 22301 in Your Company in Practice

A business continuity plan, on its own, does not prove that an organization is prepared to manage a disruption. It may be comprehensive on paper but prove ineffective when a production shutdown, a cyberattack, a supplier outage, or a physical incident affects multiple functions simultaneously. Understanding how to implement ISO 22301 in a business context therefore means building a management system that makes business continuity manageable, verifiable, and capable of continuous improvement over time.

ISO 22301 is neither a mere documentation exercise nor a project confined to IT. It is the international standard for the Business Continuity Management System, or BCMS: it defines requirements for designing, implementing, maintaining, and improving a system capable of protecting priority products and services during a crisis. The expected outcome is not the absence of incidents, but the ability to make decisions, respond, and recover within parameters consistent with contractual, regulatory, and operational obligations.

Where to Start When Implementing ISO 22301 in Your Company

The first step is to precisely define the scope of the BCMS. A scope that is too broad, defined without priorities, slows down the program and wastes resources; a scope that is too narrow, on the other hand, risks excluding essential dependencies. The decision must take into account locations, companies, processes, products, services, technological infrastructure, third parties, and applicable requirements.

In an industrial group, for example, it may be appropriate to begin implementation with the processes that support production, the supply chain, quality, and order management, including the essential IT and OT infrastructure. In a financial or insurance company, the scope may be driven by regulated services, data protection, and customer availability expectations. There is no one-size-fits-all sequence for every organization: what matters is the balance between impact, risk exposure, and the criticality of the service provided.

This phase also requires an analysis of the internal and external context, as well as the needs of stakeholders. Management, strategic customers, regulatory authorities, insurers, employees, critical suppliers, and technology partners may have different expectations. Translating these into measurable requirements ensures that business continuity is not managed based on implicit assumptions.

Governance and Sponsorship: Continuity Is a Management Responsibility

ISO 22301 assigns a specific role to leadership. Management must ensure that the business continuity policy is consistent with the company’s objectives, assign responsibilities, provide resources, and periodically evaluate the system’s performance. Delegating this responsibility entirely to a business continuity manager, a security manager, or the IT department often creates a weak point: the decisions required during a crisis have commercial, legal, reputational, and financial implications that require a cross-functional mandate.

Effective governance identifies, at a minimum, the owner of the BCMS, the process owners, the crisis management team, the support functions, and their alternates. It must also establish escalation procedures, decision-making authorities, and criteria for declaring an incident, activating the response, or transitioning to crisis management.

Objectives must be formulated in operational terms. It is not enough to simply state the general goal of maintaining continuity. It is more useful to define, for example, coverage of critical activities through approved strategies, a minimum percentage of completed drills, timeframes for completing corrective actions, and mandatory updates following significant changes.

BIA and Risk Assessment: Distinguishing Between Critical Issues, Impacts, and Causes

Business Impact Analysis, or BIA, is the core of the decision-making process for implementation. It is used to determine which activities are priorities, what consequences their unavailability would cause, and how long it would take for those consequences to become unacceptable. The BIA is not the same as a risk assessment: the former evaluates the impact of an outage, while the latter analyzes scenarios, threats, vulnerabilities, and existing controls.

For each priority process, reliable data must be collected on financial, operational, legal, contractual, reputational, and health and safety impacts. Next, recovery time objectives, the minimum resources required, and dependencies on key personnel, sites, facilities, data, applications, suppliers, and utilities must be identified.

The most critical point is to avoid unfounded figures. A Recovery Time Objective (RTO) of just a few hours implies genuine recovery capabilities: redundancy, procedures, trained personnel, emergency contracts, and technical availability must be consistent with that requirement. If the organization is unable to bear the costs and complexity involved, the target must be reassessed or a different strategy devised. The BIA must lead to sustainable decisions, not to promises that are difficult to keep during audits or emergencies.

Developing strategies tailored to specific scenarios

Continuity strategies are derived from the combination of BIA and risk assessment. They may involve people, facilities, technology, information, suppliers, logistics, and communications. In a manufacturing environment, a strategy may include alternative capacity at another facility, the availability of critical spare parts, agreements with qualified subcontractors, and procedures for product re-qualification. For digital services, it may include immutable backups, recovery environments, segmentation, emergency access, and periodic verification of data recoverability.

Not every risk requires a complete duplication of resources. Geographic redundancy, inventory, multi-sourcing, and alternative sites offer different levels of protection, with varying costs and timeframes. In some cases, it makes more sense to accept a limited disruption and establish transparent communication with the customer; in others, the risk of downtime necessitates immediate business continuity capabilities. The decision must be documented, approved by management, and reviewed whenever processes, volumes, technologies, or supply chains change.

Operational Plans, Crisis Management, and Communication

Once the strategies have been approved, the organization must translate them into plans that can be implemented under pressure. An effective plan is not a collection of general information. It must specify who does what, with what priorities, through which channels, and according to what escalation criteria.

The incident response plan addresses initial containment measures and the protection of people, assets, and information. The business continuity plan organizes the continuation or restoration of priority operations. The crisis management plan supports executive decision-making and communications with internal and external stakeholders. These three dimensions are interconnected but not interchangeable.

Procedures must be accessible even if regular systems are unavailable. Contact information, roles, alternative locations, operating instructions, and communication templates must be kept up to date and made available through secure channels. It is essential to coordinate the BCMS with cyber incident response, IT disaster recovery, emergency plans, and physical security: excellent but incompatible documents cause delays precisely when time is of the essence.

Training, drills, and assessments: the proof is in the execution

The competence of the people involved determines the quality of the response. Process managers must be familiar with their dependencies and recovery activities; the crisis team must be prepared to make decisions based on incomplete information; and operators must know how to initiate procedures without waiting for unanticipated instructions. Training must therefore be tailored to each role, integrated into the onboarding process, and updated following significant revisions.

Exercises should not be limited to verifying contact information. Tabletop exercises, crisis simulations, technical recovery tests, operational handover drills, and tests with suppliers allow for the verification of scenarios and real-time timelines. A cyber scenario that disrupts production planning, for example, must assess not only the restoration of the application but also the ability to operate in degraded mode, manage orders, communicate with customers, and maintain traceability.

Every test must yield evidence, identify discrepancies, propose corrective actions, assign responsibility, and set deadlines. Without this cycle, the exercise risks becoming a mere formality rather than a tool for improvement.

Measuring and Maintaining the BCMS Over Time

The implementation process is rounded out by internal audits, management reviews, nonconformity management, and continuous improvement. Audits should not merely verify the presence of documents, but should assess the consistency between requirements, strategic decisions, competencies, test evidence, and actual response capabilities.

The management review must take into account the results of drills, accident trends, organizational changes, supplier performance, audit findings, and the adequacy of resources. This is where the BCMS proves its value: it becomes a system capable of adapting, not a project that ends with the issuance of a policy.

For organizations seeking certification, an independent gap assessment prior to the third-party audit helps identify gaps in evidence, inconsistencies in the scope, or weaknesses in the decision-making chain. Even without certification, the systematic adoption of the ISO 22301 requirements provides a concrete framework for demonstrating reliability to customers, insurers, and stakeholders.

The key question, at the end of the process, is not whether the company has a plan. It is whether, when faced with a credible disruption, the right people have decisions already in place, resources that are truly available, and instructions they can carry out without ambiguity.

This post is also available in: