ISO 22301: business continuity management system in practice

What ISO 22301 is and who it applies to

ISO 22301:2019, Security and resilience - Business continuity management systems - Requirements, is the second edition and replaced the 2012 version. It has been adopted in Poland as PN-EN ISO 22301. It is the requirements standard in the ISO 223xx family and can therefore be used as a basis for management-system certification. Related publications provide guidance:^[1]

• ISO 22313 - clause-by-clause guidance on the use of ISO 22301;^[2]
• ISO/TS 22317 - guidance on business impact analysis (BIA);^[3]
• ISO/TS 22318 - business continuity and supply-chain issues;
• ISO 22331 - business continuity strategy;
• ISO 22398 - exercise and testing programs.

Status in August 2026. The applicable edition remains ISO 22301:2019 together with ISO 22301:2019/Amd 1:2024, the climate-action amendment issued in February 2024 across many management-system standards. It adds to clauses 4.1 and 4.2 the need to consider whether climate change is a relevant issue and whether relevant interested parties have related requirements. For continuity management the issue is tangible: floods, heat, power shortages and other environmental events can directly affect disruption scenarios. ISO currently marks the standard as due for revision, but until publication the 2019 edition with the 2024 amendment remains the applicable standard.^[1]

Who uses it in practice

The standard is sector-neutral. Demand often comes from four types of organizations:

• Entities subject to KSC/NIS2. Business continuity, backup management, disaster recovery and crisis management are explicitly among the risk-management measures of Article 21 NIS2.^[5]
• Financial entities under DORA, which are required to maintain ICT business-continuity policies, response and recovery plans, and testing.^[6]
• Providers of critical services whose customers require evidence of continuity and supply-chain resilience, sometimes contractually including ISO 22301 certification.
• Public-sector entities subject to the Polish KRI. KRI requires an information security management system; ISO 22301 can supplement an ISMS where continuity requirements justify it, but it is not itself made mandatory by KRI.^[8]

Structure of the standard - clauses 4-10

ISO 22301 uses the harmonized management-system structure also found in ISO/IEC 27001, ISO 9001 and other management-system standards. This allows an organization with an existing ISMS to integrate BCMS governance rather than create an entirely parallel management system.

• Clause 4 - Context of the organization. Scope of the BCMS, interested parties, and legal and regulatory requirements.
• Clause 5 - Leadership. Business continuity policy, roles, responsibilities, and management commitment.
• Clause 6 - Planning. Risks and opportunities, continuity objectives, and planning of changes.
• Clause 7 - Support. Resources, competence, awareness, communication, and documented information.
• Clause 8 - Operation. The operational core: BIA, risk assessment, continuity strategies and solutions, plans, response structure, exercises and testing.
• Clause 9 - Performance evaluation. Monitoring, measurement, internal audit and management review.
• Clause 10 - Improvement. Nonconformities, corrective actions and continual improvement.

The practical point is that clause 8 concentrates the operational elements of the BCMS, but they depend on earlier decisions about context, ownership, resources and objectives. Writing plans before performing BIA and agreeing acceptable disruption levels risks producing procedures for the wrong priorities.

BIA and the four parameters that shape the system

Business impact analysis establishes how the consequences of disruption evolve over time for each activity and which resources are required for recovery. Its value is not the report itself but the decisions it supports.^[3]

MTPD - maximum tolerable period of disruption

The point beyond which the impact of disruption becomes unacceptable to the organization, for example because of financial, legal, contractual, safety or service consequences. MTPD is a business decision, not an IT setting.

RTO - recovery time objective

The target time within which a process, service or system should be restored. It should be set in relation to the maximum tolerable disruption and must reflect the organization's actual priorities.

RPO - recovery point objective

The maximum tolerable amount of data loss expressed in time. RPO should be consistent with backup, replication and data-protection architecture. A fifteen-minute RPO combined with a nightly backup is not a continuity strategy; it is an unresolved design gap.

MBCO - minimum business continuity objective

The minimum acceptable level of products or services during disruption. It may be substantially lower than normal production capacity. This allows the organization to design a temporary solution that preserves critical outcomes without replicating the entire normal environment.

A common mistake is to let IT define RTO and RPO from what the existing infrastructure can already achieve. The order should be reversed: business tolerance should drive requirements, and the difference between those requirements and current capability should become an explicit risk and investment decision.

Strategies and business continuity plans

Once recovery objectives are known, the organization selects strategies capable of meeting them and records them in executable plans. NIST SP 800-34 provides complementary contingency-planning guidance.^[7] Typical approaches include:

• Redundancy - secondary sites, clustering or replication. It can reduce recovery time but increases cost and complexity.
• Recovery from backup - including offline or immutable copies where ransomware risk justifies them.
• Manual or alternative operation - performing the process in a reduced mode until systems are restored.
• Transfer to another provider - using a prearranged alternative, not trying to negotiate one during the crisis.
• Acceptance - a documented management decision that a process will not be restored within a short period.

A continuity plan should be executable by someone who did not write it, under pressure, and potentially without access to the failed environment. It therefore needs clear activation criteria, assigned roles, contact information, communication procedures and a copy available outside the environment being recovered.

Exercises, testing and internal audit

Clause 8 requires an exercise and testing program. ISO 22301 does not prescribe one universal interval. Frequency and type should reflect process criticality, organizational change, risk assessment and lessons from previous tests. A program may combine tabletop exercises, technical restoration tests and fuller failover exercises; the schedule should be justified in the organization's context.

Every exercise should produce evidence and lessons. A test that merely confirms the expected result without exploring assumptions has limited value. Findings should be linked to corrective actions and plan updates.

Internal audit under clause 9 evaluates conformity and whether the management system is functioning as intended. Auditors should be sufficiently objective with respect to the area being assessed. Smaller organizations often use external support where internal separation of duties is difficult.

Relationship with ISO 27001, KSC/NIS2, DORA and KRI

ISO 22301 and ISO/IEC 27001

ISO/IEC 27001 focuses on information security - confidentiality, integrity and availability. ISO 22301 focuses on the organization's ability to continue delivering prioritized activities and services, including disruption caused by loss of staff, facilities, suppliers or technology. The standards overlap: ISO/IEC 27001:2022 Annex A includes controls A.5.29, Information security during disruption, and A.5.30, ICT readiness for business continuity.^[4]

An organization with an operating ISMS can integrate BCMS elements incrementally. Context, leadership, competence, internal audit and management review are structurally similar; BIA, continuity strategies, plans and exercises add the continuity-specific layer.

ISO 22301 and KSC/NIS2

The Polish KSC amended in 2026 implements NIS2 risk-management requirements including business continuity, backup management, disaster recovery and crisis management. ISO 22301 certification does not exempt an entity from statutory obligations, but a well-operated BCMS can provide evidence relevant to audits and supervisory review.^[5]

ISO 22301 and DORA

DORA applies to the financial sector and requires ICT business-continuity policies, response and recovery plans and their testing. ISO 22301 offers a useful management-system structure, but it does not cover all DORA-specific duties, such as the register of ICT contractual arrangements, regulatory incident reporting or TLPT.^[6]

ISO 22301 and KRI

The Polish KRI requires public bodies within its scope to maintain an information security management system and to conduct an internal information-security audit at least annually. Building the ISMS on PN-ISO/IEC 27001 is a route to the presumption described in KRI, not a mandatory certification requirement. Continuity is one element of that broader management system and ISO 22301 can deepen it where justified.^[8]

Certification

Certification is issued by a competent certification body, not by the consultant who designed the system. A typical certification process includes:

1. Stage 1 - review of system documentation and readiness, including scope, policy, BIA, plans and evidence that internal evaluation has taken place.
2. Stage 2 - assessment of implementation and operation through interviews, records and evidence from exercises.
3. Certification decision and issuance of the certificate.
4. Surveillance activities during the certification cycle.
5. Recertification at the end of the cycle.

There is no credible universal implementation duration. It depends on BCMS scope, number of processes and locations, quality of existing plans, technical changes required and the availability of business owners. BIA should precede major investment decisions because RTO and RPO should justify the recovery architecture, not be reverse-engineered from it.

Common mistakes

• A continuity plan written by IT only for IT. It restores servers but says nothing about how the service is delivered while systems are unavailable.
• RTO and RPO copied from existing infrastructure capabilities instead of business tolerances.
• Backups that are never restored. Backup execution alone does not demonstrate recoverability.
• A plan available only inside the environment that has failed.
• Ignoring suppliers and other external dependencies.
• Exercises designed to look successful rather than expose weaknesses.
• Treating the certificate as the goal instead of operational resilience.