ISO 22301 checklist: business continuity requirements explained

What ISO 22301 is and who uses it

ISO 22301:2019 specifies requirements for a business continuity management system (BCMS). It follows the common ISO management system structure, so clauses 4 to 10 contain the auditable requirements and it integrates easily with ISO 9001 or ISO/IEC 27001. In 2024 ISO published an amendment adding climate change considerations to the context clauses. It does not change the core requirements, but check how your certification body applies it.

The standard is used by organisations that must show customers or regulators that disruption will not stop critical services: financial services, IT and cloud providers, logistics, healthcare, utilities and manufacturers in tight supply chains. Certification is voluntary. Many companies implement the standard without certifying, using it as a structured way to meet contractual or regulatory continuity requirements. ISO 22313 provides guidance on applying ISO 22301.

Clauses 4 to 10: the requirements checklist

Use the list below as a first pass. For each item, ask whether it exists, whether it is documented where required, and whether you have evidence that it works.

• Clause 4, Context: internal and external issues, interested parties and their requirements, applicable legal and regulatory obligations, and a defined BCMS scope covering products, services and locations.
• Clause 5, Leadership: top management commitment, a business continuity policy, and assigned roles, responsibilities and authorities.
• Clause 6, Planning: actions to address risks and opportunities for the BCMS itself, measurable business continuity objectives, and planned changes.
• Clause 7, Support: resources, competence, awareness, internal and external communication, and control of documented information.
• Clause 8, Operation: business impact analysis and risk assessment, business continuity strategies and solutions, business continuity plans and procedures, the exercise programme, and evaluation of documentation and capabilities.
• Clause 9, Performance evaluation: monitoring and measurement, internal audit, and management review.
• Clause 10, Improvement: nonconformity and corrective action, and continual improvement.

Business impact analysis: the core of the standard

Clause 8.2 requires a documented process for business impact analysis (BIA) and risk assessment. The BIA identifies the activities that support your products and services and assesses the impact of disrupting them over time. The output drives everything else in the system, so an auditor will read it closely.

A useful BIA is short and specific. It lists prioritised activities, the impact of disruption over defined time frames (financial, contractual, regulatory, reputational, safety), and the resources each activity depends on: people, sites, IT systems, data, suppliers and equipment.

• Define impact categories and time frames before interviewing process owners, so results are comparable.
• Set a maximum tolerable period of disruption for each prioritised activity, then a recovery time objective shorter than that.
• Set a recovery point objective for data where loss matters.
• Record the minimum resources needed to run each activity at an acceptable reduced level.
• Identify dependencies on suppliers and partners, including single points of failure.
• Have management approve the prioritisation, because it drives investment decisions.

Risk assessment and continuity strategies

The risk assessment in clause 8.2.3 looks at the risks of disruption to prioritised activities and their resources. Keep it focused on disruption scenarios rather than duplicating a general enterprise risk register. Typical scenarios include loss of a site, loss of key IT systems or a cloud region, a cyber attack such as ransomware, failure of a critical supplier, and loss of key staff.

Clause 8.3 then requires you to select business continuity strategies and solutions. The standard expects options that protect prioritised activities, stabilise and resume them within agreed timeframes, and mitigate or respond to impacts. You need to consider the resource requirements of each option and implement what you choose.

Strategies are usually built per resource type: alternative work locations or remote work for people and sites, redundancy and backups for IT, alternative or dual suppliers for critical inputs, and cross-training or documented procedures for key staff. Decisions should be traceable back to the recovery objectives in the BIA.

Business continuity plans and incident response

Clause 8.4 covers the response structure and plans. You need a defined structure of teams with the authority and competence to respond, procedures to detect and assess incidents, a warning and communication process, and documented plans that guide recovery.

Plans should be usable under stress. A good plan fits the people who will use it, lists roles and contact details, states the conditions for activation, and gives step-by-step actions to restore each prioritised activity within its recovery time objective. It also covers communication with employees, customers, regulators and the media, and the path back to normal operations.

• Incident management or crisis team with named members and deputies.
• Activation criteria and escalation route.
• Recovery procedures per prioritised activity, linked to the BIA.
• Internal and external communication templates and contact lists.
• Access to plans when primary systems are down, for example offline or printed copies.
• Stand-down and return to business as usual.

Exercising and testing: proving it works

Clause 8.5 requires a programme of exercises and tests that validates continuity strategies and plans over time. Exercises must be consistent with your objectives, based on realistic scenarios, carefully planned to minimise the risk of disruption, and followed by formal post-exercise reports with improvement actions. Clause 8.6 then requires you to evaluate the suitability, adequacy and effectiveness of your business impact analysis, risk assessment, strategies, solutions, plans and procedures.

Start small and build maturity. A tabletop walkthrough of a plan with the crisis team is a reasonable first exercise. Move on to technical recovery tests of backups and failover, then combined exercises that involve suppliers or simulate loss of a site. Auditors look for a documented programme, evidence that exercises actually took place, and proof that findings were fed back into the plans.

How ISO 22301 relates to DORA and NIS2

DORA, Regulation (EU) 2022/2554, applies from 17 January 2025 to EU financial entities. It requires an ICT business continuity policy, response and recovery plans, backup and restoration procedures, and regular testing of those plans, alongside ICT risk management, incident reporting and third-party risk management. An ISO 22301 system gives a strong structure for the continuity parts, but DORA is more prescriptive on ICT and adds specific reporting and testing obligations.

NIS2, Directive (EU) 2022/2555, had a transposition deadline of 17 October 2024. Its cybersecurity risk management measures explicitly include business continuity, such as backup management, disaster recovery and crisis management. National laws implementing NIS2 differ, so check the exact obligations with your national authority. ISO 22301 does not give automatic compliance with either law, but the BIA, plans and test evidence it produces are exactly the kind of documentation supervisors ask to see.

Typical gaps and how to prepare for audit

Most gaps found in first audits are not missing documents but missing links between them. The BIA exists, but strategies do not reference it. Plans exist, but nobody has exercised them. Objectives exist, but nobody measures them.

A free self-assessment on baltum.ai shows your readiness against ISO 22301 clause by clause and lists the gaps to close first.

• Scope is vague or excludes the services customers actually care about.
• BIA done once by the IT team without business owners, or never reviewed.
• Recovery objectives set without checking what the current IT setup can deliver.
• Critical suppliers not assessed for their own continuity capability.
• Plans too long or stored only on systems that would be unavailable during an incident.
• No exercise programme, or exercises without post-exercise reports and actions.
• Internal audit and management review missing or not covering the BCMS.

This article is for general information and is not legal advice. baltum.ai is independent software, not a certification body.