ISO 22301 is the international standard that sets out the requirements for a business continuity management system (BCMS): a managed, repeatable way for an organisation to prepare for disruptions, keep its most important products and services running when something goes wrong, and recover in a controlled way afterwards. Banks, hospitals, logistics firms, cloud and software providers, manufacturers, utilities and public bodies use it, and many obtain an independent certificate that customers and regulators recognise. After this tutorial you will be able to explain how the standard is built, run a business impact analysis, choose continuity strategies, write and exercise plans, and understand what a certification auditor looks for.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current edition is ISO 22301:2019, Security and resilience — Business continuity management systems — Requirements, the second edition, published in October 2019 by ISO technical committee ISO/TC 292 (Security and resilience). It replaced the first edition, ISO 22301:2012. In February 2024 ISO published Amendment 1 (ISO 22301:2019/Amd 1:2024), the "climate action changes" added to many management-system standards at the same time; it asks the organisation to consider whether climate change is a relevant issue for its context. A third edition is in development: the committee draft (ISO/CD 22301) completed its comment ballot on 2026-05-10 and the project had not reached the Draft International Standard stage when this tutorial was checked. The ISO catalogue lists the 2019 edition at stage 90.92 ("to be revised"). Until a new edition is published, certification audits are carried out against ISO 22301:2019 with its 2024 amendment, and that is the edition this tutorial teaches. Verified 2026-10-29 on the ISO catalogue entries for ISO 22301:2019 and ISO/CD 22301 and on national standards-body project listings.

Who this is for: IT operations and site reliability engineers, infrastructure and cloud teams, risk, compliance and security professionals, facilities and operations managers, quality managers, and anyone who has been told "we need to be ISO 22301 certified" or "the customer wants to see our business continuity plan" and wants to understand what that really involves. It is also useful for people who will be interviewed by an auditor or asked to take part in an exercise.

Prerequisites: none. A general idea of how an organisation runs (products, processes, suppliers, IT systems) helps, but every continuity and management-system term is explained when it first appears. Experience with ISO 9001 or ISO/IEC 27001 makes the structure feel familiar but is not needed.

By the end of this tutorial:

  • You will be able to explain what business continuity is, why ISO 22301 exists and how it differs from incident response and IT disaster recovery.
  • You will be able to define the core vocabulary, including disruption, prioritized activity, business impact analysis, recovery time objective and minimum business continuity objective.
  • You will be able to describe the clause 4 to 10 structure of ISO 22301 and the six parts of its operational clause 8.
  • You will be able to carry out the main steps of a BCMS: scoping, business impact analysis, risk assessment, strategy selection, planning and exercising.
  • You will be able to explain how accredited certification works and what evidence an auditor expects to see.
  • You will be able to relate ISO 22301 to its guidance standards, to ISO/IEC 27001, to IT disaster recovery guidance and to professional good practice.
  • You will be able to recognise common mistakes that turn continuity programmes into unused binders, and the practices that avoid them.

Lesson 1 – Origins, purpose and scope

Why business continuity matters

Every organisation depends on things it does not fully control: buildings, power, networks, cloud platforms, suppliers, key people, transport routes and public services. Sooner or later one of them fails. A warehouse floods, a ransomware attack encrypts the order system, a supplier goes bankrupt, a regional power cut lasts two days, or a pandemic keeps a third of the staff at home. The question is not whether disruption will happen but whether the organisation has thought in advance about which of its activities must keep going, how quickly they must come back, and what it will do to make that possible.

Without that thinking, responses are improvised. People argue about priorities while customers wait, the wrong systems are restored first, nobody knows who may authorise spending or speak to the press, and recovery takes far longer than it needed to. Business continuity is the discipline that replaces improvisation with preparation. It does not try to prevent every incident (that is mostly the job of risk management, security and engineering); it accepts that some incidents will get through and focuses on keeping the consequences within limits the organisation can live with.

From BS 25999 to ISO 22301

Business continuity grew out of IT disaster recovery planning in the 1980s and 1990s, when organisations realised that restoring a data centre was useless if the people, premises and processes around it were not ready too. National standards followed. The most influential was the British Standard BS 25999, whose second part (published in 2007) was a certifiable specification for a business continuity management system. ISO used this experience to publish ISO 22301 in 2012 as the first international, certifiable BCMS standard, and the BS 25999 parts were later withdrawn in favour of ISO 22301 and its guidance companion, ISO 22313.

The 2019 revision kept the purpose but rewrote the text. It reduced prescriptive wording, removed several acronyms from the requirements, introduced the idea of business continuity "solutions" alongside strategies, and added an explicit clause on evaluating the continuity documentation and capabilities. Like the 2012 edition, it follows the common clause structure that ISO uses for all management-system standards, which makes it easy to combine with quality, information security or environmental systems.

What the standard covers, and what it does not

In its own scope statement, ISO 22301 sets requirements for putting in place, running and improving a management system that helps an organisation avoid disruptions where it can, make them less likely, get ready for them, handle them when they happen and recover afterwards. The requirements are generic: they apply to any organisation, of any type, size or sector, and the way they are met depends on how complex the organisation and its operating environment are. A ten-person consultancy and a multinational bank can both conform, with very different levels of formality.

The standard tells you what the management system must achieve, not how to achieve it in detail. It does not prescribe recovery times, does not require a second data centre, does not say how many exercises to run each year and does not contain templates. Those decisions follow from the organisation's own analysis. Guidance on how to meet the requirements is in a companion document, ISO 22313, and in further technical specifications on topics such as business impact analysis and supply chain continuity, which Lesson 7 introduces.

The standard can be used in three ways: as a framework to build and improve a continuity programme, as the basis for internal assessment of whether the organisation meets its own continuity needs, and as the criteria for third-party certification. Many organisations use it in the first two ways without ever seeking a certificate.

Lesson 2 – Key concepts and vocabulary

ISO/TC 292 keeps its shared vocabulary in a separate standard, ISO 22300, so that all the security and resilience standards use the same words. The explanations below are paraphrased; they are not the official definitions. Learn them well, because business continuity conversations go wrong surprisingly often when people use the same word for different things.

  • Business continuity – the capability of an organisation to keep delivering its products and services at an acceptable, predefined level and within acceptable time frames while a disruption is going on.
  • Business continuity management system (BCMS) – the slice of an organisation's overall management system that sets up, runs, checks and keeps improving its business continuity arrangements. It includes the policy, people, processes, plans and resources.
  • Disruption – an incident, foreseen or not, that knocks the delivery of products and services off its expected course in an unplanned, harmful way. A flood, a cyber attack and a key supplier's failure are all disruptions.
  • Incident – an event that is, or may grow into, a disruption, a loss, an emergency or a crisis. Not every incident becomes a disruption; good response can stop one from escalating.
  • Prioritized activity – an activity that is put first in the queue after an incident because delaying it would cause the most harm. The business impact analysis identifies these. ("Prioritized" is spelled with a z in the ISO texts.)
  • Business impact analysis (BIA) – the process of analysing how a disruption would affect the organisation over time, so that priorities, time frames and resource needs can be set.
  • Maximum tolerable period of disruption (MTPD) – the time after which the impact of not resuming an activity, or of not delivering a product or service, becomes unacceptable. ISO 22301:2019 describes this idea in plain words rather than using the acronym; the term itself lives in ISO 22300 and in guidance.
  • Recovery time objective (RTO) – the period of time, after a disruption begins, within which an activity or resource must be resumed or recovered. It must be shorter than the MTPD, leaving a safety margin.
  • Minimum business continuity objective (MBCO) – the minimum level of service or production that is acceptable while the organisation is operating in its disrupted state, for example 60 % of normal daily orders.
  • Recovery point objective (RPO) – the point in time to which data must be restored so that an activity can operate again; in practice, how much recent data the organisation can afford to lose. An RPO of fifteen minutes means backups or replication must never lag by more than fifteen minutes.
  • Business continuity strategy and solution – a strategy is the chosen approach for keeping or restoring prioritized activities (for example "work from an alternate site"); a solution is the concrete arrangement that makes the strategy work (a contract for twenty desks at a recovery centre, with tested network access).
  • Business continuity plan (BCP) – the documented instructions the organisation follows when a disruption hits, so that it can respond, get products and services running again and bring them back to normal in line with its continuity objectives.
  • Exercise and test – an exercise is any rehearsal used to train people, practise and assess how well arrangements work and then improve them; a test is a particular kind of exercise with a pass-or-fail expectation, such as whether a system restore succeeds.
  • Interested party – anyone, inside or outside the organisation, who can influence its decisions and activities or who is, or believes they are, affected by them: customers, regulators, staff, owners, suppliers, emergency services, the local community.
  • Resilience – the capacity to withstand shocks and keep adjusting as conditions change. Business continuity is one important contributor to organisational resilience, alongside risk management, security, crisis management and others.

Continuity, incident response and disaster recovery

Three related disciplines are often confused. Incident response deals with the first minutes and hours: detecting what happened, protecting people, containing the damage and making the first decisions. IT disaster recovery restores technology services such as servers, networks, applications and data. Business continuity is the wider umbrella: it decides which business activities matter most, how fast they must come back and at what level, and coordinates people, premises, suppliers, information and technology to make that happen. ISO 22301 requires a response structure and plans that cover all three, but it starts from the business view. An IT recovery plan that restores the wrong system first, however efficiently, is a continuity failure.

Figure 1 – The life of a disruption: response, continuity at a minimum acceptable level within the recovery time objective, then recovery, return to normal and learning.
Figure 1 – The life of a disruption: response, continuity at a minimum acceptable level within the recovery time objective, then recovery, return to normal and learning.

Figure 1 shows how the time-based terms fit together. The MTPD is the outer limit, set by the business impact; the RTO is the target the organisation designs for, comfortably inside that limit; the MBCO says how much output is good enough during the disrupted period. Recovery then rebuilds capacity until normal operations resume, and the experience feeds back into the management system.

Lesson 3 – Structure of the standard

ISO 22301 uses the harmonized structure that all ISO management-system standards share. Clauses 1 to 3 are introductory: scope, normative references and terms and definitions. The requirements are in clauses 4 to 10. If you know ISO 9001 or ISO/IEC 27001, clauses 4, 5, 6, 7, 9 and 10 will look familiar; the continuity-specific heart of the standard is clause 8.

Clauses 4 to 10 at a glance

  • Clause 4 – Context of the organisation. Understand internal and external issues relevant to continuity (including, since the 2024 amendment, whether climate change is relevant), the needs of interested parties, applicable legal and regulatory requirements, and define and document the scope of the BCMS, including any exclusions and the reasons for them.
  • Clause 5 – Leadership. Top management must show leadership and commitment, set a business continuity policy, and assign roles, responsibilities and authorities.
  • Clause 6 – Planning. Address risks and opportunities to the management system itself, set measurable business continuity objectives with plans to achieve them, and plan changes to the BCMS in a controlled way.
  • Clause 7 – Support. Provide resources, ensure competence and awareness (including people's roles before, during and after a disruption), arrange internal and external communication, and control documented information.
  • Clause 8 – Operation. The continuity work itself: operational planning and control, business impact analysis and risk assessment, strategies and solutions, plans and procedures, the exercise programme, and evaluation of continuity documentation and capabilities.
  • Clause 9 – Performance evaluation. Monitor, measure, analyse and evaluate; run internal audits; hold management reviews.
  • Clause 10 – Improvement. Deal with nonconformities through correction and corrective action, and continually improve the BCMS.
Figure 2 – Clauses 4 to 10 of ISO 22301 mapped to Plan-Do-Check-Act: clauses 4 to 7 plan, clause 8 does, clause 9 checks and clause 10 acts.
Figure 2 – Clauses 4 to 10 of ISO 22301 mapped to Plan-Do-Check-Act: clauses 4 to 7 plan, clause 8 does, clause 9 checks and clause 10 acts.

Figure 2 shows the logic behind the order, following the mapping given in the standard's own introduction. Context, leadership, planning and support together form the Plan stage: they set the direction and prepare the ground; operation is where continuity capability is built and used; performance evaluation checks whether it works; improvement closes the loop. The cycle repeats, so a BCMS is never "finished".

Clause 8 in more detail

Clause 8 is where ISO 22301 differs from other management-system standards, so it is worth knowing its six sub-clauses by title.

  • 8.1 Operational planning and control – plan, implement and control the processes needed for continuity, including processes that are outsourced or provided through the supply chain.
  • 8.2 Business impact analysis and risk assessment – run a systematic BIA to understand impacts over time and set priorities, and a systematic risk assessment to understand the risks of disruption to prioritized activities and their resources. Both are reviewed at planned intervals and when significant changes happen.
  • 8.3 Business continuity strategies and solutions – identify options, select the strategies and solutions that meet the BIA's time frames and capacities at acceptable cost, determine the resources needed, and implement and maintain the selected solutions.
  • 8.4 Business continuity plans and procedures – set up a response structure of teams with clear roles, documented procedures for warning and communication, the business continuity plans themselves, and documented processes for recovery and return to normal after the disruption.
  • 8.5 Exercise programme – exercise and test the arrangements regularly, using realistic scenarios, to build teamwork and competence and to validate that strategies and solutions work, and report and act on the results.
  • 8.6 Evaluation of business continuity documentation and capabilities – evaluate whether the BIA, risk assessment, strategies, solutions, plans and procedures remain suitable, adequate and effective, and evaluate the continuity capabilities of partners and suppliers.

Documented information

Like other management-system standards, ISO 22301 uses the term documented information for anything that must be written down and controlled, whether in a document, a wiki, a tool or a database. Examples include the scope, the policy, the objectives, evidence of competence, the BIA and risk assessment results, the plans and procedures, exercise reports, monitoring results, audit programmes and results, management review outputs, and records of nonconformities and corrective actions. Documented information must be identified, reviewed, approved, protected and available where and when it is needed. That last point matters more in continuity than anywhere else: a plan stored only on the file server that has just been encrypted by ransomware is not available when needed.

Lesson 4 – How it works in practice

This lesson walks through a typical implementation in the order most organisations follow. Real programmes iterate: the BIA often reveals a scope problem, and the first exercise usually reveals plan gaps. That is normal and is exactly what the improvement cycle is for.

Step 1 – Secure commitment and define the scope

Start by understanding why the organisation wants a BCMS: customer contracts, regulatory expectations, a recent painful incident, insurance conditions or a board decision. Identify the interested parties and their requirements (a hospital's patients and health regulator, a payment processor's card schemes and banks), the legal and regulatory obligations, and the internal and external issues that affect continuity. Then decide the scope: which products and services, which locations, which parts of the organisation. A narrow first scope, such as one critical service and the sites and teams that deliver it, is often wiser than an organisation-wide programme that never gets past the analysis stage. Exclusions are allowed but must be justified and must not undermine the organisation's ability to deliver continuity within the scope.

Top management then approves a business continuity policy that fits the organisation's purpose, provides a framework for objectives, commits to meeting applicable requirements and to continual improvement, and is communicated and available. A senior owner for the programme and a coordinator with time to do the work are appointed.

Step 2 – Business impact analysis

The BIA is the foundation; everything later traces back to it. It usually proceeds in this order:

  1. Agree the impact types and criteria: financial loss, harm to people, legal and regulatory breaches, contractual penalties, reputation, environmental harm, and so on, each with a scale.
  2. Identify the activities that support the delivery of the products and services in scope.
  3. For each activity, assess how the impacts grow over time if it stops: after one hour, four hours, one day, three days, a week.
  4. Identify the point at which the impact becomes unacceptable (the MTPD idea), then set prioritized time frames for resuming each activity at a specified minimum capacity (the RTO and MBCO ideas).
  5. Identify the dependencies and supporting resources for each prioritized activity: people and skills, information and data, premises, equipment, ICT systems, suppliers and partners.

Interviews and workshops with the people who actually do the work produce better BIAs than questionnaires alone. Results should be validated by management, because the BIA effectively decides how the organisation will spend money on resilience.

Step 3 – Risk assessment

The risk assessment looks at the same prioritized activities and asks what could disrupt them and their resources: loss of a site, loss of systems or data, loss of key people, supplier failure, utility failure, cyber attack, severe weather. Risks are identified, analysed and evaluated, and the organisation decides which ones need treatment. Treatment can reduce likelihood (better physical security, patching, a second supplier) or reduce consequences (backups, alternate sites, cross-training). ISO 22301 does not mandate a risk method; many organisations reuse their ISO 31000-based enterprise risk process. Note the difference from clause 6.1, which deals with risks and opportunities affecting the management system itself, such as losing the programme's only coordinator.

Step 4 – Strategies and solutions

With priorities and risks understood, the organisation identifies options that act before, during and after a disruption: options that make disruption less likely, that shorten it, or that limit its impact. Common strategy families include:

  • alternate premises or remote working for people;
  • redundant or quickly recoverable ICT, such as replication to a second region, tested backups and documented restore procedures;
  • alternate or additional suppliers, safety stock and contractual continuity commitments from critical suppliers;
  • cross-training and documented procedures so that more than one person can perform each critical task;
  • manual workarounds that keep a minimum service running while systems are down;
  • mutual-aid agreements and insurance to fund the recovery.

Options are compared against the BIA's time frames and capacities, the amount and type of risk the organisation is willing to accept, and their costs and benefits. The selected strategies are then turned into concrete solutions, and the resources each one needs are determined: people, information and data, buildings and equipment, consumables, ICT systems, transport and logistics, finance, and partners and suppliers. Finally the solutions are implemented and maintained. A strategy that exists only in a slide deck, without contracts, configurations and trained people behind it, does not count.

Figure 3 – How the parts of clause 8 feed each other: analysis sets priorities, strategies meet them, plans make them usable, exercises and evaluation prove and improve them.
Figure 3 – How the parts of clause 8 feed each other: analysis sets priorities, strategies meet them, plans make them usable, exercises and evaluation prove and improve them.

Step 5 – Response structure and plans

Figure 3 shows that plans come late in the sequence, after the analysis and the strategy decisions. A common structure has three layers. An incident management or crisis team of senior people assesses the situation, decides whether to activate plans, sets priorities, authorises spending and manages communication with interested parties. Business continuity teams for each area carry out the continuity strategies for their prioritized activities. Technical recovery teams restore systems, data and facilities. Each team has named members, alternates, the authority it needs and the competence to act.

The standard expects documented procedures for warning and communication: how the organisation detects and monitors incidents, communicates internally and with external parties such as customers, authorities and the media, receives and responds to warnings, and records what happened and what was decided. Plans themselves typically state their purpose and scope, the criteria and procedure for activating them, the roles involved, the actions to take, the interdependencies, the resources needed and the communication flows. They must be usable and available at the time and place they are needed, which usually means short, action-focused documents stored where they survive the disruption: printed copies, offline devices or a separate hosted service.

Recovery is planned too. After the immediate continuity measures, the organisation needs documented processes for restoring and returning business activities from the temporary arrangements to normal operation. Moving back from a recovery site, resynchronising data entered manually and paying down the backlog are all part of recovery.

Step 6 – Exercising, evaluation and improvement

Plans that have never been exercised are guesses. An exercise programme grows in realism over time: a walkthrough where teams read the plan together; a tabletop exercise where a facilitator presents an unfolding scenario and teams discuss their decisions; functional tests of specific components, such as restoring a database or moving staff to the alternate site; and finally full or live exercises that combine several teams and systems. Each exercise has objectives, a scenario, observers and a post-exercise report with actions. Exercises are not about passing; an exercise that finds a weakness has done its job.

Clause 8.6 then asks the organisation to step back and evaluate the whole capability: are the BIA and risk assessment still current, do the strategies still meet the time frames, do the plans still match the organisation, and can critical suppliers really deliver what they promised? Evaluation happens at planned intervals, after an incident or plan activation, and when significant change occurs. Clause 9 adds monitoring of objectives and indicators, internal audits by people who are objective and impartial, and management reviews where top management looks at the results and decides on changes. Clause 10 turns findings into corrective actions that remove root causes, not just symptoms.

Typical roles and artefacts

Typical roles are a senior sponsor in top management, a BCMS manager or coordinator, BIA and plan owners in each business area, incident management and recovery team members with alternates, an internal auditor and, for ICT, the service owners and engineers who maintain recovery configurations. Typical artefacts are the scope statement, policy, objectives, BIA and risk registers, strategy decisions, plans and contact lists, the exercise programme and reports, training records, audit reports, management review minutes and the corrective action log.

Lesson 5 – Assessment, certification and compliance

Who certifies

ISO writes standards but does not certify anyone. Certification is carried out by independent certification bodies. The most trusted certificates come from bodies accredited by a national accreditation body (for example UKAS in the United Kingdom or ANAB in the United States) that is a signatory to the International Accreditation Forum (IAF) multilateral recognition arrangement. Accredited certification bodies follow ISO/IEC 17021-1, the general requirements for bodies certifying management systems, and the competence requirements for auditing business continuity systems in ISO/IEC TS 17021-6. Certificates from non-accredited bodies exist, but customers and regulators often do not accept them, so check accreditation before choosing a provider.

It is the organisation's BCMS within the stated scope that is certified, not individual people and not products. Individuals can obtain personal qualifications, for example as a lead auditor or lead implementer from a training and personnel-certification provider, or professional credentials from bodies such as the Business Continuity Institute (BCI), but those are separate from organisational certification.

The certification cycle

Figure 4 – The accredited certification lifecycle: a two-stage initial audit, a three-year certificate with surveillance audits, then recertification.
Figure 4 – The accredited certification lifecycle: a two-stage initial audit, a three-year certificate with surveillance audits, then recertification.

As Figure 4 shows, the organisation first implements the BCMS and runs it long enough to produce evidence: at least one BIA cycle, implemented solutions, at least some exercises, an internal audit and a management review. The stage 1 audit reviews the documented system and checks whether the organisation is ready; it often identifies areas of concern to fix before stage 2. The stage 2 audit evaluates whether the BCMS is implemented and effective, through interviews, observation and records across the scope. Auditors raise nonconformities, usually graded by the certification body as major (a requirement not met, or a doubt that the system achieves its intended results) or minor (an isolated lapse). Major nonconformities must be resolved before certification. A certificate is valid for three years, with surveillance audits at least once a year and a recertification audit before expiry.

What auditors look for

Continuity auditors are interested in traceability and evidence of capability. They will pick a prioritized activity and follow it through: where did its RTO come from in the BIA, which strategy and solution meet it, which plan describes how to use the solution, when was it last exercised, what did the exercise report find, and were the actions closed? They will check that plans are available outside the affected systems, that contact lists are current, that teams have alternates, that critical suppliers' continuity has been evaluated, and that top management actually reviewed the results. A beautiful document set with no exercise evidence, or an RTO of four hours supported by a backup that takes two days to restore, is a typical finding.

Certification versus compliance

Certification shows that a management system conforms to ISO 22301; it does not prove that the organisation will survive every disruption, and it does not by itself satisfy specific laws. Several sectors have their own continuity or operational-resilience rules. Financial services are a good example: the European Union's Digital Operational Resilience Act (DORA), which has applied since January 2025, requires covered financial entities to have ICT business continuity and response and recovery arrangements, and other supervisors worldwide set similar expectations. An ISO 22301 BCMS provides much of the machinery such rules require, such as impact analysis, plans, testing and governance, but organisations must map the specific legal requirements and close any gaps themselves. Customers increasingly ask suppliers for an ISO 22301 certificate or evidence of an equivalent programme in contracts and due-diligence questionnaires.

Assessing without certifying

Many organisations use ISO 22301 for self-assessment or second-party assessment only. A customer may audit a critical supplier against selected requirements, or an internal audit team may assess the programme annually. These assessments are valuable and cheaper than certification, but they do not produce a certificate that third parties will recognise.

Lesson 6 – Worked example: Northgate Pharma Distribution

Northgate is a fictional wholesaler that distributes medicines to about 1,200 pharmacies and 15 hospitals from two warehouses. It employs 400 people, runs its warehouse management and ordering systems on a public cloud platform, and depends on a temperature-controlled transport subcontractor. Two large hospital customers have added a contract clause asking for ISO 22301 certification within two years, and the national medicines regulator expects continuity of supply for critical medicines. Here is how Northgate applies the standard step by step.

Context, scope and leadership

The operations director becomes the senior sponsor and appoints a BCMS manager from the quality team, with half her time allocated. The context review lists the internal and external issues: dependence on a single cloud region, a tight labour market for warehouse staff, increasing summer heatwaves (relevant to cold-chain storage, so climate change is recorded as a relevant issue), and a recent industry-wide ransomware wave. Interested parties include pharmacies, hospitals, the regulator, staff, the transport subcontractor and the parent company. Northgate decides on a first scope of "order-to-delivery of medicines to pharmacies and hospitals from both warehouses", excluding the head-office marketing function, and records the reason. The board approves a short policy and three objectives: agreed recovery times met in exercises, all critical suppliers' continuity evaluated within the first year, and plan contact details verified every quarter.

Business impact analysis

Workshops with each department identify around thirty activities. The impact criteria include patient harm, regulatory breach, contractual penalties, financial loss and reputation. The results surprise people. Hospital emergency deliveries cannot stop for more than four hours before patient harm becomes possible, so that activity is given an RTO of two hours and an MBCO of all emergency orders. Routine pharmacy deliveries can tolerate about two days, so they receive an RTO of twenty-four hours at an MBCO of 50 % of normal volume, prioritising critical medicines. Cold-chain storage cannot tolerate more than a few hours outside the required temperature range. Payroll, which everyone assumed was critical, can wait a week thanks to a manual advance-payment option. Each prioritized activity's dependencies are recorded: the warehouse management system, the order portal, pickers with cold-chain training, refrigerated vans, product data, and the cloud platform.

Risk assessment

The risk assessment focuses on threats to those dependencies. The highest risks are ransomware affecting the warehouse system, a total loss of one warehouse through fire or flood, a cloud region outage, failure of the refrigeration plant during a heatwave, and the transport subcontractor being unable to supply vans. Some risks are treated by reducing likelihood: stronger identity controls, maintenance contracts and temperature alarms. Others need continuity strategies because they cannot be made unlikely enough.

Strategies and solutions

For the order and warehouse systems, Northgate replicates to a second cloud region and keeps immutable backups in a separate account. Its RPO for orders is fifteen minutes, so replication lag is monitored. It also designs a manual workaround: printed pick lists generated every hour to an offline device, so emergency hospital orders can still be picked if both systems fail. For the warehouses, each site is configured to serve the other's emergency orders at reduced volume, with stock of critical medicines held at both. For transport, a second refrigerated carrier is contracted on standby terms. For people, pickers are cross-trained on cold-chain handling, and a list of former employees willing to return at short notice is maintained. Northgate considers but rejects a third warehouse: the cost is far above the benefit given the two-site arrangement. Each solution has an owner, a budget and a configuration or contract behind it.

Response structure and plans

Northgate sets up an incident management team of five senior managers with alternates, chaired by the operations director, with clear authority to spend up to an agreed amount without board approval. Each warehouse has a site continuity plan, IT has recovery runbooks for each system, and a communications plan covers pharmacies, hospitals, the regulator and staff, with pre-approved message templates. Plans are short checklists, printed in grab bags at both sites, held on managers' offline tablets and hosted on a separate service outside the main cloud account. Activation criteria are explicit, for example any warehouse system outage longer than thirty minutes or any cold-store temperature alarm not cleared within fifteen minutes.

Exercises and evaluation

The first tabletop exercise simulates ransomware on a Monday morning. It reveals that the communications plan lists a regulator contact who left two years ago and that nobody is sure who can authorise the standby carrier. A functional test of the second cloud region succeeds technically but takes five hours instead of the planned two, because database permissions were missing. Both findings are recorded, actions are assigned, and a retest three weeks later restores service in ninety minutes. Northgate also sends its transport subcontractor a continuity questionnaire and visits its depot; the subcontractor's own plan relies on a single fuel supplier, which Northgate raises in the next contract review.

Audit, review and certification

After nine months of operation, an internal auditor from the parent company audits the BCMS and finds that two departments have not reviewed their BIA since it was first completed. Management review looks at exercise results, objectives, audit findings and supplier evaluations, approves budget for the refrigeration upgrade and extends the scope to include the returns process next year. The certification body's stage 1 audit asks for clearer evidence of how the MBCO for pharmacy deliveries was agreed. At stage 2, the auditor traces hospital emergency deliveries from the BIA through to the retest report and raises one minor nonconformity about uncontrolled copies of an old plan in a warehouse office. Northgate corrects it, finds the root cause (no procedure for retrieving superseded printed copies) and receives its certificate. The following summer a real refrigeration failure during a heatwave is handled within the planned time, and the post-incident review feeds the next improvement cycle.

Lesson 7 – Relationship to other standards and frameworks

ISO 22301 sits inside a family of security and resilience documents from ISO/TC 292, and it overlaps with several other well-known standards and frameworks. Knowing the relationships helps you reuse work and avoid gaps.

Figure 5 – ISO 22301 at the centre of related documents: vocabulary and principles feed it, guidance and technical specifications help implement it.
Figure 5 – ISO 22301 at the centre of related documents: vocabulary and principles feed it, guidance and technical specifications help implement it.

Figure 5 shows the main relationships. ISO 22300 supplies the vocabulary. ISO 22313 is the companion guidance that explains, clause by clause, how the requirements can be met; it contains no extra requirements. ISO/TS 22317 gives detailed guidance on running a business impact analysis, and ISO/TS 22318 on understanding and managing continuity across the supply chain. ISO/IEC 27031 addresses the readiness of information and communication technology to support business continuity. ISO 22316 describes principles and attributes of organisational resilience, a broader idea of which business continuity is one part, and ISO 31000 gives the general risk management principles and process that many organisations use for the clause 8.2 risk assessment.

Standard or frameworkWhat it isRelationship to ISO 22301
ISO 22313Guidance on using ISO 22301 (not certifiable)Explains how to meet each requirement; read alongside ISO 22301 when implementing.
ISO/IEC 27001Certifiable information security management system standardSame clause structure, so the systems integrate easily. Its Annex A includes controls on information security during disruption and ICT readiness for business continuity, but it does not cover the full business view of continuity.
ISO/IEC 27031Guidance on ICT readiness for business continuityHelps IT teams design and test the technology side of the strategies and solutions chosen under ISO 22301.
NIST SP 800-34 Rev. 1US government contingency planning guide for federal information systemsDetailed, free guidance on system-level contingency and recovery planning, including its own business impact analysis approach; complements ISO 22301 at the IT level.
BCI Good Practice Guidelines (Edition 7.0)Professional good-practice guide from the Business Continuity InstituteOrganises continuity work into six professional practices (establishing a BCMS, embracing business continuity, analysis, solutions design, enabling solutions, validation) aligned with ISO 22301; widely used for training practitioners.
ISO 9001 and ISO 14001Quality and environmental management system standardsSame harmonized structure; an integrated management system can share policy governance, document control, internal audit and management review.

Integrating with an existing management system

If an organisation already holds ISO/IEC 27001 or ISO 9001 certification, much of the management-system machinery can be shared: document control, competence records, internal audit, management review and corrective action. What cannot be shared is the continuity-specific content of clause 8. An information security risk assessment is not a business impact analysis, and a list of security controls is not a set of continuity strategies. Many certification bodies offer combined audits for integrated systems, which reduces audit days and effort.

Continuity and resilience

Organisational resilience is the broader goal of being able to anticipate, absorb and adapt. Business continuity contributes the structured analysis, plans and exercises. Crisis management deals with the strategic leadership response to events that threaten the organisation as a whole, emergency management protects people and property, and cyber security and IT service management protect and restore technology. A mature organisation connects these disciplines rather than running them in separate silos, and ISO 22301's response structure is a natural place to connect them.

Common pitfalls and best practices

Pitfalls to avoid

  • Writing plans before the analysis. Teams download a template and fill it in without a BIA, so the plan restores what is easy rather than what matters, with recovery times nobody can justify.
  • Treating continuity as an IT project. Disaster recovery for servers is necessary but not sufficient; people, premises, suppliers, communication and manual workarounds are just as important.
  • Recovery objectives that the solutions cannot meet. An RTO of two hours supported by a restore that has only ever been tested at eight hours is a gap waiting to be discovered by an incident or an auditor.
  • Plans that are unavailable during the disruption. Plans held only on the systems that fail, contact lists out of date, no alternates named.
  • Never exercising, or exercising only to pass. Scripted exercises with known answers build false confidence; findings that are not followed up waste the effort.
  • Ignoring suppliers. Critical outsourced services and suppliers are treated as somebody else's problem, although their failure stops the organisation just as surely.
  • Letting the BCMS go stale. The BIA is done once for certification and never revisited, even after reorganisations, new products or a move to the cloud.

Best practices

  • Start with a focused scope around the products and services that matter most to customers and regulators, prove the approach, then extend it.
  • Make the BIA a business decision. Involve the people who run the activities and have management formally agree the priorities and objectives, because they drive spending.
  • Trace everything. For each prioritized activity, be able to show the line from impact to objective, strategy, solution, plan, exercise and improvement.
  • Keep plans short and action-focused, stored in several places that will survive the likely disruptions, with named alternates for every role.
  • Exercise progressively and honestly: from walkthroughs to tabletop scenarios to live tests, with realistic surprises and tracked actions.
  • Evaluate critical suppliers' continuity through questionnaires, contract clauses, evidence of their exercises and, for the most critical, site visits or joint exercises.
  • Link continuity to change management, so that new systems, sites, suppliers and reorganisations trigger an update of the BIA and plans.
  • Integrate with existing systems for audit, document control and management review rather than building a parallel bureaucracy.

Summary and key takeaways

  • ISO 22301:2019, amended in 2024 for climate considerations, is the current certifiable requirements standard for business continuity management systems; a new edition is in development at committee-draft stage.
  • Business continuity is about continuing to deliver products and services at an acceptable level and within acceptable time frames during a disruption, then recovering in a controlled way.
  • The standard follows the harmonized clause 4 to 10 structure and Plan-Do-Check-Act; its distinctive content is clause 8, from business impact analysis to evaluation of capabilities.
  • The business impact analysis is the foundation: it sets priorities, time frames, minimum capacities and resource needs that every later decision must meet.
  • Strategies are approaches and solutions are the concrete arrangements behind them; both must be implemented, resourced and maintained, not just described.
  • Plans must be usable and available when the disruption happens, and exercises must prove that strategies and solutions really meet the objectives.
  • Accredited certification bodies certify the BCMS through a two-stage audit, yearly surveillance and three-yearly recertification; certification does not replace sector-specific legal requirements.
  • ISO 22301 works best when integrated with risk management, information security, IT recovery and supplier management, and when it is kept current through change management.

Reflection questions

  1. Pick one product or service your organisation delivers. Which activities support it, and after how long would stopping each of them cause unacceptable harm?
  2. Think of a system you work with. What recovery time and data-loss tolerance would the business expect for it, and has a restore ever been tested to prove it can be met?
  3. If your main office or main cloud account were unavailable tomorrow morning, where would you find the plan and the contact details you need?
  4. Which of your organisation's suppliers could stop your most important service, and what evidence do you have about their own continuity arrangements?
  5. Design a first tabletop exercise for your team: what scenario would you choose, what objectives would you set, and what would count as a useful finding?

Further reading and official sources

Original tutorial by xOps School (DevOpsSchool Private Limited), written from public sources about ISO 22301. Not affiliated with or endorsed by the standard's owner; standard names are trademarks of their owners. Buy the official standard from its publisher for the authoritative text.

Last modified: Thursday, 29 October 2026, 10:15 AM