CyphrQ
Menu

ISO 22301 Business Continuity Explained: BIA, Recovery, Certification

ISO 22301 explained: what the business continuity standard covers, how a BIA and recovery objectives work, and how certification goes.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

10 min read

ISO 22301 is the international standard for a business continuity management system: the plans, roles and routines that keep your critical services running, or bring them back in an agreed time, when something disrupts you. It is certifiable, meaning an independent auditor can check your system against it. It does not say how to defend against any one threat. It asks whether you can keep delivering when a threat succeeds.

Updated 25 October 2026.

What is ISO 22301 and who publishes it?

ISO 22301 is published by the International Organization for Standardization (ISO). Its full title is "Security and resilience: Business continuity management systems: Requirements". The edition in force is ISO 22301:2019, and it has one amendment, ISO 22301:2019/Amd 1:2024, titled "Climate action changes". The official page is iso.org/standard/75106.

I could not open the ISO page from my research tooling (it returned a 403 error), so I took edition details from national standards bodies instead. The Swedish Institute for Standards lists the amendment as valid, with an approval date of 23 February 2024. The Estonian standards body lists the European adoption of the 2019 edition as valid from 2 December 2019 and the consolidated 2019 plus amendment text from 16 December 2024. Check the ISO page for the current status before you cite either edition in a contract.

The standard's technical committee, ISO/TC 292, also lists the supporting documents in the family. They are covered below.

What does ISO 22301 cover?

In the Estonian body's summary of the scope, it describes a management system to prevent, reduce the likelihood of, prepare for, respond to and recover from disruptions. It applies to organisations of any type or size. Its stated purpose includes helping an organisation keep delivering products and services at an acceptable, predefined level during a disruption.

A management system is the set of rules, responsibilities and routines an organisation uses to handle something consistently. For continuity, that works out to five questions:

  1. What must keep working? You identify the products and services that matter most.
  2. How long can each one be down? You set recovery targets.
  3. What does each one depend on? People, buildings, systems, data, suppliers.
  4. What is the plan, and who runs it? Strategies, response plans and named roles.
  5. Have we tried it? Exercises, reviews and corrective actions.

The standard is deliberately threat-neutral. A fire, a flood, a failed supplier, a bad software update and ransomware all land in the same place: something critical is unavailable. That is why continuity sits well beside security rather than inside it.

What is a business impact analysis in ISO 22301?

A business impact analysis (BIA) is the step that turns "everything is important" into a ranked list. For each product or service, you work out what damage grows as the outage gets longer, and which activities and resources it needs to run.

The output is usually a set of recovery objectives per activity. Terms vary between organisations, so define yours in writing. Common ones:

Term Plain meaning
Maximum tolerable period of disruption (MTPD) How long an outage can last before the organisation can no longer accept the damage
Recovery time objective (RTO) How quickly you aim to restore the activity or system
Recovery point objective (RPO) How much data loss, measured in time, you can accept
Minimum service level The reduced level of service that is acceptable while you recover

The distinction people miss is that an RTO is a target, not a measurement. A target only means something if an exercise has shown you can meet it. ISO publishes separate guidance for the BIA step, ISO/TS 22317:2021, "Guidelines for business impact analysis", which the committee's published-documents page lists.

Who uses ISO 22301, and can you be certified against it?

Yes, you can be certified. ISO 22301 is a requirements standard, so an accredited certification body can audit you against it and issue a certificate for a stated scope. DNV, one such body, offers a managers' training course built on ISO 22301 and says the material draws on its own database of audit findings.

Who tends to pursue it:

  • Service providers whose customers need to know their service will survive a disruption.
  • Regulated firms that must show operational resilience to a supervisor. The EU's financial-sector rules are one example; see DORA: ICT risk rules for financial firms.
  • Organisations with a single point of failure, such as one data centre, one plant or one critical supplier.
  • Smaller organisations often do not need a certificate. A written BIA, a tested recovery plan and a call tree cover much of the value without the audit.

The certificate shows that a system exists and is run. It does not guarantee that you will recover from any given event. As with other ISO certificates, the scope matters: ask which services, sites and teams it covers.

How does ISO 22301 relate to other standards?

  • ISO/IEC 27001 is the information security management system standard. The two share a management-system skeleton, so one audit programme can often serve both. The SOC 2 vs ISO 27001 comparison explains the security side.
  • ISO/IEC 27031 covers ICT readiness for business continuity: how the technology side supports a continuity plan. Its page is at iso.org/standard/27031; I could not open it, so check the current edition there.
  • ISO 22313 is guidance on using ISO 22301, and ISO 22398 is guidance on exercises. The committee page lists them as ISO 22313:2020 and ISO 22398:2013.
  • ISO/IEC 42001 is the management system standard for AI. It follows the same family idea but covers a different subject. See ISO/IEC 42001 explained.

More standards in this area are collected on the ISO standards subtopic page.

How does ISO 22301 connect to cyber resilience?

Cyber resilience is the ability to keep operating through, and recover from, a cyber incident. ISO 22301 supplies the business side of it: which services come first, how long they can be down, and who decides.

In practice, here is the division of labour:

  • Security tries to stop the incident and detect it fast.
  • Continuity decides what happens to the business while the incident is under way.
  • Recovery objectives from the BIA tell your technical team what to restore first.

In practice: the CrowdStrike outage. On 19 July 2024, CISA's alert said the widespread Windows outage was caused by a security vendor's content update, not by malicious activity. It reported Microsoft's estimate that 8.5 million Windows devices were affected, less than one percent of all Windows machines. Microsoft's own post says the figure was published on 20 July and describes the recovery work: manual remediation documentation and scripts, and a recovery tool that boots from USB.

The lesson for continuity is that no attacker was involved and the disruption was severe anyway. An organisation with a BIA knew which machines to fix first. One without it was deciding that under pressure.

The ransomware version of the same question is covered in How ransomware attacks unfold, and the controls that work. Its backup and restore-testing advice is the technical half of an ISO 22301 recovery objective.

How does an ISO 22301 audit or adoption work in practice?

Certification follows the common pattern for ISO management systems. Your certification body will confirm its own stages and timings.

  1. Set the scope. Name the services, sites and teams in and out.
  2. Get leadership in. Top management owns the policy and the objectives.
  3. Run the BIA and a risk assessment. Rank services, set recovery objectives, find dependencies and single points of failure.
  4. Choose continuity strategies. Decide how each service is kept up: alternative site, spare capacity, manual workaround, second supplier.
  5. Write the plans. Incident response, continuity and recovery plans with named roles and contact details.
  6. Exercise and review. Run exercises, record results, fix what broke, hold an internal audit and a management review.
  7. Audit. An accredited body assesses the system, you close any findings, and you receive a certificate for the scope.
  8. Keep going. Expect follow-up audits. The cycle length is set by your certification body.

Going deeper: for security and IT teams

Start from the dependency map, not the plan. For each critical service from the BIA, record the systems, data stores, identities, network paths, third parties and people it needs. Then mark the single points of failure. Typical findings are one identity provider, one DNS provider, one backup administrator and one cloud region. An RTO that ignores a dependency's own recovery time is fiction. If the service needs the identity provider to start, the provider's RTO is a floor on yours.

Test the number, not the document. For each RTO and RPO, run a restore into an isolated environment and record the elapsed time and the data age. Keep the timed result as evidence. If you cannot meet the target, either invest or change the target and get the owner of the business risk to sign the change. A signed gap is acceptable to an auditor; an unmeasured target is not.

Use more than one exercise type. ISO publishes guidance on exercises in ISO 22398. A sensible programme moves up in realism: a tabletop discussion of a scenario, a walkthrough of a plan with the people who would run it, a technical recovery test of one system, then a larger simulation. Cover a scenario with no attacker (a bad update, as in the CrowdStrike outage) and one with an attacker who has administrator access, so that you check backups, identity recovery and out-of-band communication.

Plan communications you can use when systems are down. Keep contact lists, the plan itself and key runbooks somewhere that does not depend on the systems being recovered. Record who may declare an incident and who may authorise a switch to a workaround.

Evidence an auditor asks for.

  • Signed continuity policy, scope statement and named roles.
  • The BIA with dates, owners, approvals and the recovery objectives it produced.
  • Risk assessment and the strategies chosen for each critical service.
  • Current plans with version history.
  • Exercise schedule, scenarios, attendee lists, results and the corrective actions that followed.
  • Internal audit report, management review minutes and a corrective action log.
  • Supplier assessments for dependencies that you cannot control.

Common nonconformities, described generally.

  • A BIA done once and never updated after a system, supplier or site changed.
  • Recovery objectives that no exercise has ever tested.
  • Plans that exist but have no named owner or are out of date.
  • Exercises held, but no record of what failed or who fixed it.
  • Management review that does not look at continuity results.
  • Critical suppliers with no continuity expectations written into the contract.

Map to your security controls. ISO/IEC 27001's Annex A includes controls on information security during disruption and on ICT readiness for business continuity; confirm the numbering in your edition of the standard. Practical mappings: backup and restore procedures to RPO, disaster recovery runbooks to RTO, incident response to the activation criteria in the continuity plan, supplier management to dependency risk.

Ask your team or provider.

  • Which services have a signed MTPD and RTO, and when did we last meet them in a test?
  • Which dependency has no alternative?
  • If our identity provider were down, how would the recovery team log in?
  • Which supplier's outage would stop a critical service, and what does the contract say?
  • Does the certificate we hold or have been shown name the services that matter?

Learn more

Key takeaways

  • ISO 22301 is the certifiable standard for a business continuity management system; the edition in force is ISO 22301:2019 with Amendment 1:2024 (climate action changes).
  • Its core is the business impact analysis: rank services, set recovery objectives, map dependencies.
  • A recovery objective is a target until an exercise proves it.
  • The standard is threat-neutral, which makes it the business half of cyber resilience.
  • A certificate covers a stated scope; ask what it includes.
  • Many smaller organisations get most of the value from a BIA, a tested recovery plan and an exercise, without certification.

Sources