ISO 22301 in 2026 - a business continuity management system without procedure theatre

What ISO 22301 is and who it applies to

ISO 22301:2019 ^[1] - full title: Security and resilience - Business continuity management systems - Requirements - is the second edition of the standard, replacing the 2012 version. It is adopted in Poland as PN-EN ISO 22301 and is the only document in the 223xx family that contains requirements, and therefore the only certifiable one. The rest of the family are guidance documents:

• ISO 22313 ^[2] - guidance on applying ISO 22301, clause by clause.
• ISO/TS 22317 ^[3] - guidance on business impact analysis (BIA).
• ISO/TS 22318 - continuity across the supply chain.
• ISO 22331 - selecting a business continuity strategy.
• ISO 22398 - exercise and testing programmes.

Status of the standard as at August 2026. The 2019 edition is in force together with the amendment ISO 22301:2019/Amd 1:2024, the so-called climate amendment that ISO introduced in February 2024 across several dozen management system standards at once. It adds to clauses 4.1 and 4.2 a requirement to consider whether climate change is relevant to the organisation's context and whether interested parties expect it to be. For a BCMS this sits more naturally than for other systems, because flooding, heat and power outages are textbook disruption scenarios. The standard itself carries the status International Standard to be revised (stage 90.92) in the ISO catalogue, meaning a decision has been taken to prepare a further edition - but until it is published, the 2019 version applies.^[1]

Who it applies to in practice

The standard is sector-neutral, but real demand comes from three groups:

1. Entities covered by the Polish KSC act and NIS2 - business continuity, backup management, disaster recovery and crisis management are named explicitly among the risk management measures in article 21 of the NIS2 directive ^[5]. See the article on the KSC act and the article on NIS2.
2. The financial sector under DORA ^[6] - the regulation requires an ICT business continuity policy together with response and recovery plans, and periodic testing of both.
3. Critical service providers - an ISO 22301 certificate is increasingly a tender requirement or a contractual condition imposed by a customer who is themselves subject to NIS2 and has to manage supply chain risk.

Entities performing public tasks covered by KRI ^[8] (Journal of Laws 2024 item 773) are obliged to run an ISMS, and § 19(3) of the regulation gives them a presumption of conformity if they base it on PN-ISO/IEC 27001 together with the related standards. Business continuity is part of such a system, so ISO 22301 is a natural extension here rather than additional bureaucracy.

Structure of the standard - clauses 4 to 10

ISO 22301 uses the harmonised structure common to management system standards (Annex SL), the same one as ISO 27001 ^[4], ISO 9001 or ISO 14001. This is not a formal curiosity - it means an organisation with an ISMS already in place can integrate a BCMS without building a second, parallel management system.

• Clause 4 - Context of the organisation. BCMS scope, interested parties, legal and regulatory requirements. This is where it is decided which processes enter the system at all.
• Clause 5 - Leadership. Business continuity policy, roles and responsibilities, top management commitment. Without a board decision on acceptable downtime, everything else is guesswork.
• Clause 6 - Planning. Risks and opportunities, continuity objectives, planning of changes.
• Clause 7 - Support. Resources, competence, awareness, communication, documented information.
• Clause 8 - Operation. The core of the standard: BIA, risk assessment, continuity strategies and solutions, plans, response structure, exercise programme.
• Clause 9 - Performance evaluation. Monitoring and measurement, internal audit, management review.
• Clause 10 - Improvement. Nonconformities, corrective actions, continual improvement.

The practical conclusion: clause 8 is roughly 70 per cent of the implementation work, and clauses 4 to 7 are the condition for that work to make any sense. Organisations that start by writing plans and finish with context usually end up writing plans for processes that turn out not to matter.

BIA and the four parameters that determine everything

Business impact analysis (BIA) ^[3] establishes how fast the consequences of interrupting each process grow and what resources it needs in order to resume. The output of a BIA is not a report but four numbers per process.

MTPD - maximum tolerable period of disruption

The point beyond which the effects of a disruption become unacceptable to the organisation - loss of liquidity, contractual penalties, loss of licence, irreversible reputational damage. MTPD is set by the business, not by IT.

RTO - recovery time objective

The time within which a process or system is to be restored. It must be shorter than MTPD - the difference is the safety margin. An RTO equal to MTPD is a plan with no slack, and it will not survive the first delay.

RPO - recovery point objective

The maximum acceptable data loss expressed in time. In practice RPO is the required backup frequency: an RPO of 15 minutes with a nightly backup is not a policy, it is a contradiction.

MBCO - minimum business continuity objective

The level at which the organisation must operate during a disruption. Usually far below normal - and that is the point. MBCO makes it possible to design a cheaper fallback solution, because it does not have to reproduce full production capacity.

The most common mistake: RTO and RPO set by the IT department on the basis of what the current infrastructure can deliver. That reverses the order - the parameters should follow from the tolerance of the business, and the gap between requirement and capability is precisely what the BIA exists to expose and escalate to an investment decision.

Continuity strategies and plans

Once the parameters are known, the standard requires the selection of a strategy that will meet them, and then its capture in plans. A convergent contingency planning methodology is described in NIST SP 800-34 ^[7]. The typical options:

• Redundancy - a second site, a cluster, synchronous replication. The most expensive, and the shortest RTO.
• Restore from backup - a 3-2-1 backup scheme with an offline or immutable copy that is resistant to ransomware. See Hardening.
• Workaround or manual operation - the process is run by hand until the system is restored. Cheap, time-limited, and it has to be rehearsed.
• Transfer to a provider - outsourcing the process for the duration of the disruption. This needs a contract concluded before the event, not during it.
• Acceptance - a conscious decision that a given process will not be restored quickly. Perfectly legitimate, provided it is documented and approved by management.

Continuity plans have to be executable by someone who took no part in writing them, at three in the morning, with no access to the intranet. Hence the requirements of the standard: clear activation criteria, assigned roles, contact details, internal and external communication procedures, and a copy of the plan available outside the environment being recovered.

Exercises, tests and internal audit

Clause 8 requires an exercise and testing programme. The standard imposes no fixed interval - frequency is meant to follow from the criticality of the process and the results of the risk assessment. The practice we apply with clients:

1. Tabletop exercise - at least once a year for every critical process. The team walks through a scenario around a table, without touching production systems.
2. Technical restore test - quarterly. Restoring a randomly selected backup into an isolated environment and verifying that the data is complete.
3. Full exercise or failover - every 12 to 24 months, for organisations with a short RTO requirement.

Every exercise ends with a report and findings, and entries in the corrective action plan. An exercise that succeeded and produced not a single finding usually means the scenario was too gentle.

Internal audit (clause 9) checks the system's conformity with the standard and its effectiveness. It should be carried out by someone independent of the area being audited - in smaller organisations, usually externally. See IT security audit.

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

ISO 22301 and ISO 27001

ISO 27001 ^[4] protects information - its confidentiality, integrity and availability. ISO 22301 protects the organisation's ability to operate - including when the problem is not information but the absence of people, a building or a supplier. The point of contact is explicit: the 2022 version of ISO 27001 includes in Annex A the controls A.5.29 (information security during disruption) and A.5.30 (ICT readiness for business continuity). The controls themselves are described in ISO 27002.

An organisation with a working ISMS can implement a BCMS incrementally: context, policy, competence, internal audit and management review are shared; what gets added is the BIA, strategies, plans and exercises.

ISO 22301 and the KSC act and NIS2

The amended Polish KSC act, in force since 3 April 2026, transposes into national law the risk management measures from article 21 of NIS2 ^[5] - including business continuity, backups, disaster recovery and crisis management. An ISO 22301 certificate does not release anyone from a statutory obligation, but it substantially simplifies demonstrating conformity during the article 15 audit.

ISO 22301 and DORA

DORA ^[6] has applied to the financial sector since 17 January 2025 and requires an ICT business continuity policy, response and recovery plans, and periodic testing of them. ISO 22301 supplies a ready methodology, but it does not cover the whole of DORA - the register of information on ICT providers, incident reporting to the supervisory authority and TLPT testing all fall outside it.

ISO 22301 and KRI

The KRI regulation (Journal of Laws 2024 item 773) requires entities performing public tasks to run an ISMS (§ 19(1)) and to carry out an annual internal information security audit (§ 19(2)(14)). Basing the system on PN-ISO/IEC 27001 is not mandated - it grants a presumption of conformity (§ 19(3)). Business continuity is part of that system, most often taking the form of recovery plans for line-of-business systems and public registers in local government. See KRI compliance audit.

Certification - how it runs and what it costs

The certificate is issued by an accredited certification body, not by the consultant who implemented the system - the same independence principle that applies to the KSC audit. The sequence:

1. Stage 1 - documentation and readiness review. Verification of scope, policy, BIA, plans and evidence from the internal audit.
2. Stage 2 - audit of implementation on site. Interviews with process owners, review of evidence from exercises, verification of effectiveness.
3. Decision and issue of the certificate - valid for 3 years.
4. Surveillance audits - annually, narrower in scope.
5. Recertification - in the third year, full scope.

A realistic implementation timeline for a mid-sized organisation is 6 to 12 months. The single largest cost is not the audit but the technical solution forced by the RTO and RPO - which is why the BIA is worth doing before the decision to certify, not after it.

The most common mistakes

1. A continuity plan written by IT for IT. The result is a document about restoring servers that says nothing about how the customer service team is supposed to work for three days without a system.
2. RTO and RPO taken from what the infrastructure can do. The order is reversed - the parameters are supposed to be a requirement, not a description of the current state.
3. Backups with no restore test. The classic that returns in every audit: copies are being made, nobody has ever restored one. See IT security audit.
4. A plan available only in the system that has just gone down. A copy of the plan has to exist outside the environment being recovered - on paper as well.
5. Suppliers left out. Business continuity stops at the organisation's boundary only on paper. A critical supplier with no plan of their own is a single point of failure.
6. Exercises designed to confirm a conclusion. A scenario chosen so as to look good in front of the board. An exercise is there to find weak points, not to confirm there are none.
7. The certificate as the goal. A system that exists purely for the audit turns out, after the first real disruption, to be unknown to the people who were supposed to execute it.

Frequently asked questions

How does ISO 22301 differ from ISO 27001?

ISO 27001 builds an information security management system - it protects the confidentiality, integrity and availability of information. ISO 22301 builds a business continuity management system - it is about the survival of the whole organisation: its people, sites, suppliers and processes.

Both standards share the same clause 4-10 structure, so integration is natural. The point of contact is controls A.5.29 and A.5.30 in Annex A to ISO 27001:2022.

What do MTPD, RTO, RPO and MBCO mean?

MTPD - the maximum tolerable period of disruption, after which the consequences become unacceptable. RTO - the recovery time objective for a process or system, always shorter than MTPD. RPO - the maximum acceptable data loss expressed in time, which in practice sets the required backup frequency. MBCO - the minimum level of service maintained during a disruption.

All four come out of the BIA, and the decision is approved by management - not by the IT department.

Is ISO 22301 mandatory?

The standard is not - certification is voluntary. Business continuity itself is mandatory: NIS2 lists it alongside backups, disaster recovery and crisis management among the article 21 measures, and DORA obliges financial entities to have an ICT business continuity policy.

ISO 22301 is the most widely used way of documenting that those obligations are met.

How long do implementation and certification take?

For a mid-sized organisation, 6 to 12 months: context and BIA, strategy selection, plans, first exercises, internal audit, management review.

Certification runs in two stages (Stage 1 for documentation, Stage 2 for implementation). An accredited body issues the certificate for 3 years, with annual surveillance audits and recertification in the third year.

How often should continuity plans be tested?

The standard requires an exercise programme but imposes no interval - frequency should follow from risk analysis and the criticality of the process.

Common market practice: a tabletop exercise at least once a year for every critical process and a technical restore test every quarter. A backup that has never been restored is not evidence of continuity - it is an assumption.