ISO 22301 Guide: Building and Certifying a BCMS

Most organisations have business continuity plans, but few can show that those plans are driven by a current impact analysis, tested against realistic scenarios and improved after every exercise. ISO 22301 is the international requirements standard for a business continuity management system (BCMS): the management layer that keeps plans alive, owned and evidenced. This guide explains what the standard requires clause by clause, how to build a BCMS that survives a certification audit, where identity and non-human identities (service accounts, API keys, certificates) create hidden continuity dependencies, and how ISO 22301 maps to ISO/IEC 27001, NIST and the financial sector resilience rules. It is written for continuity managers, security and IT leads who own recovery, and executives sponsoring certification.

Key takeaways

ISO 22301 is a management system standard, not a plan template. It requires a policy, objectives, a business impact analysis, risk assessment, strategies, plans, exercises, internal audit and management review, all documented and repeated.
Clause 8 is where certification is won or lost. Auditors trace a line from the business impact analysis to recovery time objectives, to chosen solutions, to plans, to exercise results; a break in that chain is a nonconformity.
The 2019 edition is current but under revision. ISO lists ISO 22301:2019 as "to be revised" with ISO/CD 22301 in development, and Amendment 1:2024 adds climate action considerations to the context clauses.
Identity is a recovery prerequisite. If the identity provider, privileged access tooling, secrets vault or signing keys are unavailable, nothing else in the recovery plan can run, so they belong in the BIA as dependencies with their own recovery objectives.
Exercise evidence is the strongest proof. A small number of well-documented exercises with tracked corrective actions convinces an auditor more than a thick binder of untested plans.

What it is and who it applies to

ISO 22301:2019, Security and resilience: Business continuity management systems: Requirements, is the second edition of the standard, published in October 2019 by ISO technical committee ISO/TC 292. According to its ISO catalogue page, it reached stage 90.92 ("International Standard to be revised") in December 2025, and a successor (ISO/CD 22301) is under development, so the 2019 text remains the one to certify against until the new edition is published. ISO 22301:2019/Amd 1:2024, Climate action changes, was published in February 2024 and is read together with the base standard.

The standard is generic: it applies to any organisation, public or private, of any size, that wants to protect against, reduce the likelihood of, prepare for, respond to and recover from disruptions. It is voluntary, but it is commonly requested in procurement, outsourcing due diligence and by regulators who expect a structured approach to operational resilience.

Document	Status (per ISO catalogue)	Use it for
ISO 22301:2019	Published, edition 2; to be revised	The certifiable requirements ("shall" statements)
ISO 22301:2019/Amd 1:2024	Published February 2024	Climate action additions to the context of the organisation
ISO 22313:2020	Published, edition 2; to be revised (ISO/AWI 22313 in development)	Guidance on how to apply each ISO 22301 requirement
ISO/TS 22317:2021	Published, confirmed in 2025	Guidelines for running a business impact analysis
BCI Good Practice Guidelines 7.0	Current BCI edition	Practitioner method organised as six Professional Practices (PP1 to PP6)

Who typically certifies: outsourcers and managed service providers whose customers require it in contracts, data centre and cloud operators, financial market infrastructure suppliers, public bodies and utilities. Organisations that do not certify still use ISO 22301 as the reference model for a BCM programme, often alongside ISO/IEC 27001. ISO 22313:2012, the first edition of the guidance, was withdrawn in February 2020; make sure internal procedures cite the 2020 edition.

Structure and key requirements

ISO 22301 follows the common ISO management system structure (clauses 4 to 10), which makes it straightforward to integrate with ISO/IEC 27001 and ISO 9001. The table summarises what each clause asks for and the evidence an auditor expects.

Clause	Requirement in practice	Typical evidence
4 Context of the organisation	Internal and external issues, interested parties and their requirements (including legal and regulatory), BCMS scope and exclusions	Context register, legal and regulatory register, scope statement naming sites, products and services
5 Leadership	Top management commitment, business continuity policy, roles and authorities	Signed policy, RACI, management minutes
6 Planning	Actions to address risks and opportunities to the BCMS itself, business continuity objectives and plans to achieve them, planning of changes	Objectives with owners, measures and dates
7 Support	Resources, competence, awareness, communication, documented information control	Training records, communication plan, document control procedure
8 Operation	8.1 operational planning and control; 8.2 business impact analysis and risk assessment; 8.3 business continuity strategies and solutions; 8.4 business continuity plans and procedures; 8.5 exercise programme; 8.6 evaluation of business continuity documentation and capabilities	BIA, risk assessment, strategy paper, plans, exercise reports, capability evaluations
9 Performance evaluation	Monitoring and measurement, internal audit programme, management review	KPI reports, audit reports, management review minutes
10 Improvement	Nonconformity and corrective action, continual improvement	Corrective action log with root cause and closure evidence

The clause 8 chain

Business impact analysis: identify the products and services in scope, the activities that deliver them, the impact of disruption over time, and set a prioritised timeframe for resuming each activity at a specified minimum acceptable capacity. Recovery time objectives (RTO) must sit inside the point at which impacts become unacceptable. Identify dependencies, including suppliers, partners, people, information and technology. ISO/TS 22317 gives method guidance, and the Business Impact Analysis Template gives a working format.
Risk assessment: identify, analyse and evaluate risks of disruption to the prioritised activities and their resources, and decide which need treatment. Many organisations reuse the ISO/IEC 27005 or enterprise risk method here rather than inventing a new one.
Strategies and solutions: choose options for before, during and after disruption (protect, stabilise, continue, resume, recover), covering people, information and data, buildings and facilities, technology, supplies and partners. Record why a solution was selected, its cost and whether it meets the RTO.
Plans and procedures: a response structure with named teams, warning and communication procedures, and business continuity plans that cover activation, roles, actions, and the steps to return from temporary measures. See the Business Continuity Plan Template.
Exercise programme: exercises consistent with the objectives, based on appropriate scenarios, producing formalised post-exercise reports with outcomes and recommendations, run at planned intervals and when significant change occurs.
Evaluation: assess the suitability, adequacy and effectiveness of BIA, risk assessment, strategies, plans and procedures, including those of partners and suppliers, and update them.

What Amendment 1:2024 adds

The 2024 climate action amendments were issued across ISO management system standards. For ISO 22301 the change sits in the context clauses: the organisation determines whether climate change is a relevant issue, and relevant interested parties can have requirements related to climate change. In practice, record the decision and its reasoning in the context register, and if climate change is relevant, reflect it in scenarios such as flooding, heat affecting data centres or supply chain disruption. Certification bodies audit the amended text, so a context register silent on climate is an easy finding.

Identity and NHI requirements

ISO 22301 does not mention identity, but clause 8.2 requires dependencies and supporting resources to be identified, and clause 8.3 requires solutions for technology and information. In most recoveries the first technology dependency is identity: people must authenticate to recovery tooling, and automated systems must authenticate to each other. Treat the following as resources in the BIA, each with its own RTO and recovery point objective (RPO).

Identity dependency	Continuity risk	Solution to evidence under clause 8.3
Directory and identity provider (AD, Entra ID, IdP)	Compromise or outage blocks every sign-in, including to backups and cloud consoles	Tested directory recovery runbook, isolated backups. See the Identity Recovery Guide.
Break-glass accounts	Emergency access fails exactly when MFA or federation is down	Documented, monitored emergency accounts tested in exercises. See the Break-Glass Account Guide.
Service accounts, API keys and tokens	Restored systems cannot reconnect because credentials were rotated, lost or held only in the failed environment	Inventory of machine credentials per prioritised activity, recoverable secrets store
Secrets vault and key management	Encrypted backups are useless without keys; vault unseal material unavailable	Replicated vault, documented unseal and key custody procedure. See the Secrets Management Guide.
Certificates and PKI	Expired or unrecoverable certificates stop services after restore	CA backup and recovery, certificate inventory, renewal automation
Third-party and SaaS integrations	OAuth grants and connected apps cannot be reissued quickly	Documented reconnection steps and owners

Two practical rules help. First, make identity recovery the first scenario in the exercise programme, because it gates every other recovery. Second, credential rotation after a cyber incident is itself a continuity activity: rotating hundreds of non-human credentials can take longer than restoring the servers, so it needs an owner, a runbook and a time estimate in the plan. See the Human vs Non-Human Identity overview for the inventory model.

Implementation steps

Time to first certification depends mostly on scope and on how much of the programme already exists, because the standard expects evidence of at least one full cycle of exercises, internal audit and management review. Narrow initial scope (one site, one product line or the critical services) is the most common way to get there sooner and extend later.

Secure sponsorship and set scope. Agree with top management which products and services, sites and legal entities are in scope, and why anything is excluded. Write the business continuity policy and assign a BCMS owner.
Build the context and legal register. Record issues (including the climate decision required by Amd 1:2024), interested parties, and laws and regulations that set continuity expectations, such as DORA or sector rules. See the DORA Guide where applicable.
Run the business impact analysis. Interview activity owners, quantify impact over time (financial, regulatory, customer, safety), set prioritised timeframes and minimum capacities, and map dependencies down to systems, suppliers and identities. Validate results with senior management, since they own the risk appetite.
Assess risk and select strategies. For each prioritised activity, compare options (alternate site, work area recovery, hot or warm standby, manual workaround, supplier diversification) against RTO and cost, and document the decision.
Write the response structure and plans. Separate incident or crisis management (strategic), business continuity (activity level) and IT disaster recovery (technical) plans, with clear activation criteria and handoffs. Keep plans short and action led. See the Crisis Management Guide.
Exercise in rising difficulty. Start with walkthroughs and tabletop exercises, then component tests (restore a database, fail over a site), then integrated exercises. Pilot with one business area before running organisation-wide. See the Tabletop Exercise Guide.
Measure, audit and review. Run a full internal audit against every clause, hold a management review covering the inputs the standard lists, and close corrective actions with evidence.
Certify. Select an accredited certification body. Typical certification follows a stage 1 audit (documentation and readiness) and a stage 2 audit (implementation and effectiveness), then annual surveillance audits and recertification on a three-year cycle.

Rolling back or adjusting: if stage 1 finds major gaps, postpone stage 2 rather than carrying nonconformities into certification. If a new strategy (for example moving a service to a second cloud region) fails its first test, keep the previous solution documented and in force until the replacement passes an exercise.

Small versus large organisations

Small organisations: one BIA workshop per service, a single combined plan, tabletop exercises twice a year, and a part-time BCMS owner can satisfy the standard. Reuse supplier certifications as evidence for dependencies.
Large organisations: federated BIA with a central method, tiered plans per business unit, a dedicated exercise calendar, integration with the enterprise risk and ISMS audit programmes, and tooling for plan maintenance.

Evidence and assessment

Auditors sample. They pick a prioritised activity and follow it end to end, so evidence has to be connected rather than merely present.

Audit question	Evidence that answers it	Common weakness
How were RTOs set?	BIA records showing impact over time and management sign-off	RTOs set by IT capability, not business impact
Does the chosen solution meet the RTO?	Strategy rationale plus test results showing achieved recovery time	No measured recovery times
Are suppliers covered?	Supplier continuity assessments, contract clauses, evaluation under 8.6	Critical cloud or SaaS providers absent from BIA
Are plans exercised?	Exercise programme, post-exercise reports, corrective actions	Exercises run but no report or follow up
Is the BCMS improving?	Management review minutes, KPI trends, closed corrective actions	Same findings repeat across years

Metrics that show it is working

BIA currency: percentage of in-scope activities with a BIA reviewed in the last 12 months (target 100 percent).
Exercise coverage: percentage of prioritised activities exercised in the cycle, and the share exercised against a cyber or identity-loss scenario.
Achieved versus target RTO: measured recovery time in tests divided by RTO, per activity.
Corrective action closure: median days to close post-exercise and audit actions.
Dependency coverage: percentage of critical suppliers and identity dependencies with an assessed continuity arrangement.

Mapping to other frameworks

Only mappings confirmed against the cited catalogues are listed. NIST identifiers were verified against the official datasets.

ISO 22301 area	ISO/IEC 27001:2022 Annex A	NIST CSF 2.0	NIST SP 800-53 Rev. 5
4 Context, dependencies	A.5.9 Inventory of information and other associated assets	GV.OC-04, GV.OC-05	PM-11 Mission and Business Process Definition
8.2 BIA and risk assessment	A.5.30 ICT readiness for business continuity	GV.RM-03	RA-9 Criticality Analysis, CP-2(8) Identify Critical Assets
8.3 Strategies and solutions	A.5.30, A.8.13 Information backup, A.8.14 Redundancy of information processing facilities	PR.IR-03, PR.IR-04	CP-7 Alternate Processing Site, CP-8 Telecommunications Services, CP-9 System Backup
8.4 Plans and procedures	A.5.29 Information security during disruption	ID.IM-04, RC.RP-01	CP-2 Contingency Plan, CP-10 System Recovery and Reconstitution
8.5 Exercise programme	A.5.30	ID.IM-04	CP-3 Contingency Training, CP-4 Contingency Plan Testing
Supplier dependencies	A.5.19 to A.5.22 supplier relationships	GV.SC-04, GV.SC-07	SA-9 External System Services, SR-6 Supplier Assessments and Reviews

Regulatory overlap: EU financial entities under DORA, operators under NIS2 and UK firms under PRA and FCA operational resilience rules face continuity expectations that ISO 22301 does not satisfy on its own, notably impact tolerances, regulator incident reporting and ICT third-party exit strategies. An ISO 22301 BCMS is a strong foundation for those obligations but not a substitute. See the NIS2 Directive Guide, the MAS Technology Risk Management Guide and the Cloud Concentration Risk and Exit Strategy Guide for the third-party angle.

Common pitfalls

IT disaster recovery presented as a BCMS. A DR plan for data centres without a BIA, policy, objectives, audit and review does not meet ISO 22301; auditors look for the management system around the plans.
RTOs nobody can achieve. Business owners ask for one-hour recovery, the solution delivers a day, and nobody records the gap. Either fund the solution or have management formally accept the residual risk.
Cyber scenarios missing. Exercises cover fire and pandemic but not ransomware or identity provider compromise, where backups, directories and credentials may all be untrustworthy at once. See the Ransomware Response and Recovery Guide.
Cloud and SaaS treated as resilient by default. Clause 8.6 requires evaluating suppliers' continuity capability; a provider's marketing availability figure is not evidence. See the Third-Party Concentration Risk Guide.
Plans that depend on credentials held in the failed system. Recovery runbooks stored only on the corporate intranet, or passwords only in a vault that sits in the affected environment, stall recovery at step one.
Scope creep before first certification. Trying to certify every site in year one usually delays certification; start narrow and extend at surveillance or recertification.

Practitioner checklist

Confirm you are working to ISO 22301:2019 plus Amd 1:2024 and ISO 22313:2020, and watch for the revised editions in development.
Write a scope statement naming products, services, sites and exclusions, approved by top management.
Record a climate change relevance decision in the context register.
Complete a BIA for every in-scope activity with impact over time, prioritised timeframes, minimum capacity and dependencies including identity and secrets.
Document a strategy decision for each prioritised activity showing how the chosen solution meets the RTO.
Give the identity provider, break-glass accounts, vault and PKI their own RTO and RPO and a tested recovery runbook.
Run an exercise programme with written post-exercise reports and tracked corrective actions, including at least one cyber and one identity-loss scenario a year.
Assess continuity arrangements of critical suppliers, especially cloud and SaaS, under clause 8.6.
Complete a full internal audit and management review before booking the stage 1 audit.

ISO 22301 Business Continuity Guide: Building and Certifying a BCMS