ISO/TS 22317: ISO/TS 22317 – Tutorial (about 60 minutes)

ISO/TS 22317 is the international guidance document on business impact analysis (BIA): the structured way an organization works out which of its products, services and activities matter most, how quickly the damage grows when they stop, and what it needs to get them running again. Business continuity managers, risk and resilience teams, IT disaster recovery planners, auditors and operational managers use it to plan, run, report and maintain a BIA that top management can trust. After this tutorial you will be able to explain what the guidance covers, run a BIA from planning to endorsement, set sensible recovery timeframes and use the results to drive continuity strategy.

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

Course overview

Edition and status: The current edition is ISO/TS 22317:2021, Security and resilience — Business continuity management systems — Guidelines for business impact analysis, the second edition, published in November 2021 by ISO technical committee ISO/TC 292 (Security and resilience). It is a Technical Specification (TS), not a full International Standard, and it replaced the first edition, ISO/TS 22317:2015, which has been withdrawn. National standards catalogues list the 2021 edition as published and current, and no newer edition or draft was listed when this tutorial was checked. This tutorial teaches the 2021 edition. Verified 2026-10-29 on the Standards Norway catalogue entry for ISO/TS 22317:2021 (the ISO catalogue entry is linked under Further reading).

Who this is for: business continuity and resilience practitioners who are starting out; IT service, infrastructure and site reliability engineers who must set or meet recovery objectives; risk, compliance, quality and information security professionals who meet the BIA in ISO 22301 or ISO/IEC 27001 work; internal auditors who review continuity programmes; and department heads who are asked to "fill in the BIA questionnaire" and want to know why and how.

Prerequisites: none. A basic picture of how an organization delivers products and services to customers through processes, people, technology and suppliers is helpful. Every continuity term is explained the first time it appears, and Lesson 2 collects the vocabulary in one place.

By the end of this tutorial:

You will be able to explain what a business impact analysis is, why organizations need one and where it sits in a business continuity management system.
You will be able to define the core vocabulary, including impact criteria, prioritized activity, MTPD, RTO, RPO, MBCO and dependency.
You will be able to describe how ISO/TS 22317:2021 is organised: its prerequisites, the BIA process from planning to endorsement, and monitoring and review.
You will be able to carry out a BIA top-down, from products and services through processes and activities to the resources and dependencies behind them.
You will be able to explain why there is no certification against ISO/TS 22317 and how a BIA is assessed in ISO 22301 audits and internal reviews.
You will be able to relate ISO/TS 22317 to ISO 22301, ISO 22313, ISO/TS 22331, ISO 31000 and other neighbouring documents.

Lesson 1 – Origins, purpose and scope

The question every continuity programme must answer first

Imagine you are asked to "make the company ready for a disruption". A fire, a ransomware attack, a supplier going bankrupt, a flood at the main warehouse or a regional power cut could each stop parts of the business. You cannot protect everything equally: money, people and time are limited, and protection has a cost. Before you can choose backup sites, spare stock, second suppliers or recovery plans, you need to know three things. What does the organization deliver that really matters? How long can each of those things stop before the damage becomes unacceptable? And what does each of them depend on? Answering these questions in a structured, evidence-based way is what a business impact analysis does.

Without a BIA, continuity work tends to go wrong in predictable ways. The IT department protects the systems it knows best rather than the ones the business needs first. Recovery targets are copied from a template ("everything in four hours") and are either impossible to meet or wastefully expensive. Critical suppliers are missed because nobody asked who provides the cold storage or the payroll service. And top management never really agrees to the priorities, so in a real crisis people argue about what to restore first while the damage grows.

Why a dedicated guidance document was written

ISO 22301, the international requirements standard for business continuity management systems (BCMS), requires an organization to carry out a BIA and a risk assessment as part of its operation clause (clause 8). The requirement says what the BIA must achieve: define the types of impact and criteria, identify the activities that support products and services, assess impacts over time, set prioritized timeframes, and identify resources and dependencies. It deliberately does not say how to do that. Practitioners around the world used very different methods, of very different quality. Some interviewed every manager for hours; others sent a spreadsheet and accepted whatever came back. Some started from IT systems; others started from the organization chart.

ISO therefore produced a guidance document focused only on the BIA. The first edition appeared in 2015 under the "Societal security" title then used for this family of documents. Today the document belongs to ISO/TC 292, the ISO committee for security and resilience. The second edition, published in 2021 by that committee, revised the guidance after ISO 22301 itself had been revised in 2019 and its guidance companion ISO 22313 in 2020, and adopted the newer "Security and resilience" title.

What "Technical Specification" means

ISO publishes several types of document. An International Standard (IS) goes through the full consensus process, including a public enquiry draft and a final draft vote. A Technical Specification is approved through a shorter route by the members of the responsible committee. It is often used when a subject is still developing, or when the committee wants to publish practical guidance faster. A TS is reviewed within a few years to decide whether to confirm it, revise it, turn it into a full International Standard or withdraw it. For a user, the practical point is simple: ISO/TS 22317 is authoritative international guidance, but it is guidance, written with "should" statements rather than "shall" requirements.

Scope

In its own scope statement, the TS gives guidelines for an organization to establish, implement and maintain a formal, documented BIA process. It does not prescribe one uniform method: an organization adapts the guidance to its needs, objectives, resources and constraints. It applies to all organizations, whatever their type, size or nature, in the private, public and not-for-profit sectors. Although it is written to support a BCMS based on ISO 22301, you can use it whenever you need a defensible BIA, for example to set recovery objectives for an IT disaster recovery programme or to answer a regulator's operational resilience questions.

It is just as important to know what the TS does not cover. It does not tell you how to choose continuity strategies (that is the subject of ISO/TS 22331), how to write plans and procedures (ISO/TS 22332), or how to assess risk in general (ISO 31000 and the risk assessment part of ISO 22301). It does not provide forms, questionnaires or software. It gives you the logic and the sequence; you design the tools.

Lesson 2 – Key concepts and vocabulary

The vocabulary for the whole ISO security and resilience family lives in ISO 22300. ISO/TS 22317 uses those terms, so learning them once helps across the family. The explanations below are paraphrases, not the official definitions.

Business impact analysis (BIA) – the process of analysing how the effects of a disruption on the organization grow over time, used to set priorities and recovery objectives.
Disruption – an incident, expected or unexpected, that causes an unplanned negative departure from the normal delivery of products and services.
Impact – the consequence of a disruption on the organization's objectives, such as lost revenue, harm to people, fines or loss of trust.
Impact category – a type of impact the organization chooses to measure, for example financial, legal and regulatory, contractual, reputational, operational, customer, health and safety, or environmental.
Impact criteria – the agreed scale used to rate impacts in each category (for example "minor", "significant", "severe", "catastrophic" with defined thresholds), approved by top management so that every area is judged the same way.
Product and service – an output the organization provides to customers or other interested parties; in a BIA this is the starting point, because impacts are felt when outputs stop.
Process – a set of related activities that turns inputs into a product or service, such as order fulfilment or payroll.
Activity – a set of one or more tasks within a process, owned by a team, such as picking goods or authorising payments.
Prioritized activity – an activity to which the organization gives priority after an incident because stopping it leads quickly to unacceptable impacts.
Resource – anything an activity needs to operate: people and skills, information and data, technology and applications, premises and equipment, supplies, finance and partners.
Dependency – a reliance of one activity on another activity, a resource or an external party; an interdependency is a two-way or chained reliance.
Maximum tolerable period of disruption (MTPD) – the time after which the impacts of not resuming a product, service or activity become unacceptable to the organization.
Recovery time objective (RTO) – the target period after an incident within which an activity must be resumed, or a resource recovered, at an agreed minimum level; it is always set shorter than the MTPD.
Recovery point objective (RPO) – the point in time to which data used by an activity must be restored so that the activity can operate again; it expresses how much data loss is tolerable.
Minimum business continuity objective (MBCO) – the minimum level of service or output that is acceptable during a disruption, for example "60 % of normal order volume".
Top management – the person or group who directs and controls the organization at the highest level, and who must approve the impact criteria and the BIA results.
Interested party – a person or organization that can affect, be affected by or believe itself affected by a decision or activity, such as customers, regulators, staff, shareholders and suppliers.

BIA and risk assessment are different tools

Beginners often mix up these two. A risk assessment asks "what could happen, how likely is it and how bad would it be?" It starts from threats such as floods or cyber attacks. A BIA asks "if this stopped, for whatever reason, how bad would it get and how fast?" It starts from the outputs and is deliberately independent of the cause. The two are complementary: the BIA tells you what to protect and how quickly to recover it; the risk assessment tells you which threats are most likely to cause a disruption, so you can reduce them. ISO 22301 requires both.

The time-based nature of impact

The most important idea in a BIA is that impact grows with time. A one-hour outage of an online shop may cost a few sales; a one-day outage may break promises to customers; a one-week outage may cause regulatory action and permanent loss of market share. By rating impacts at several points in time (for example 4 hours, 1 day, 3 days, 1 week, 1 month), the BIA reveals the moment when the curve crosses the line of "unacceptable". That moment is the MTPD. The recovery target (RTO) is then set comfortably inside it, leaving room for detection, decision and recovery.

Figure 1 – How RPO, RTO, MBCO and MTPD relate to one another along the timeline of a disruption.

Figure 1 shows the relationships. The RPO looks backwards from the start of the disruption: it limits how old the restored data can be. The RTO and MTPD look forwards: the activity must be running again, at least at its minimum level (MBCO), before the RTO, and the RTO must fall before the MTPD. If the planned recovery takes longer than the MTPD, the organization has a gap it must close with a different strategy.

Lesson 3 – Structure of the guidance

ISO/TS 22317:2021 follows the usual ISO opening: clause 1 gives the scope, clause 2 lists normative references (the vocabulary of ISO 22300) and clause 3 covers terms and definitions. The guidance itself is then organised in three groups: prerequisites (clause 4), the BIA process (clause 5) and review of the BIA (clause 6), followed by informative annexes on topics such as ways of collecting information, other uses of the BIA process and example BIAs. The description below paraphrases the structure as it is summarised in public descriptions of the document; public summaries differ slightly in how they name and number the individual steps, so read the TS itself for its exact wording.

Group 1 – Prerequisites (clause 4)

Before any data is collected, the TS asks the organization to put foundations in place. These cover:

the context and scope of the BIA: which parts of the organization, which products and services, which locations, and how the BIA links to the BCMS scope and objectives;
roles and responsibilities: who sponsors the BIA, who manages it as a project, who provides information (process and activity owners), who analyses and consolidates the results, and who approves them;
commitment: the active support of top management, which gives the project authority, provides resources and, crucially, decides the impact criteria and the priority of products and services.

Group 2 – The BIA process (clause 5)

This is the heart of the guidance. It describes a sequence that moves from the top of the organization downwards:

Planning the BIA as a project: objectives, method (workshops, interviews, questionnaires or a mix), schedule, team, data to collect and how it will be validated.
Prioritizing products and services with top management: which outputs matter most, which impact categories and criteria apply, and how long each output can be unavailable before the impact becomes unacceptable.
Prioritizing processes that deliver those products and services, inheriting the time sensitivity from the outputs they support.
Prioritizing activities within those processes, with owners rating impacts over time and proposing timeframes such as RTO, RPO and minimum levels.
Identifying resources and dependencies that the prioritized activities need: people, information, technology, premises, equipment, supplies, suppliers and partners, and other internal activities.
Analysing and consolidating the results: checking consistency between levels, resolving conflicts, identifying gaps and producing a BIA report.
Obtaining top management endorsement of the results, so that they become the agreed basis for strategy and planning.

Group 3 – Review of the BIA (clause 6)

The final part covers keeping the BIA alive: reviewing both the BIA results and the BIA process and method, at planned intervals and whenever there is a significant change (new products, reorganisations, mergers, new suppliers, new systems, lessons from incidents and exercises), and feeding results into the selection of continuity strategies and solutions.

Figure 2 – The overall flow of ISO/TS 22317: foundations first, then a top-down BIA process, then a review loop.

The top-down "levels" idea

A key design choice in the guidance is that the BIA works through levels of the organization in order. You start with the outputs that customers and other interested parties experience, then look at the processes that create them, then at the activities inside those processes, and finally at the resources behind each activity. Each level inherits its time sensitivity from the level above. If the home delivery service can be unavailable for at most 48 hours, then no activity that home delivery cannot run without can have a recovery target of a week.

Why top-down rather than bottom-up? A bottom-up BIA, where every department rates its own importance, almost always produces inflated results: every manager believes their work is critical. Starting with top management's view of products and services anchors everything to what the organization actually exists to deliver, and gives a reference point for challenging inflated claims lower down.

Figure 3 – The four levels a BIA works through and who sets the main values at each level.

Lesson 4 – How it works in practice

Step 1: set up the project

Treat the first BIA as a project with a sponsor from top management, a project lead (often the business continuity manager) and a small core team that understands both the business and the method. Agree the objectives: for a first BIA, the aim is usually to identify prioritized activities and their resource needs across the BCMS scope. Decide the data collection method. Workshops bring people together and expose dependencies between teams; interviews give depth; questionnaires reach many people quickly but produce shallow, inconsistent answers unless someone reviews them. Many organizations use a questionnaire to prepare and a facilitated workshop or interview to validate.

Prepare the tools before you meet anyone: an impact rating table, a list of time intervals, a template for activities, resources and dependencies, and short guidance for participants. Pilot the template with one friendly department and fix it before rolling it out. Plan time for analysis: collecting data is only half the work.

Step 2: agree impact categories and criteria with top management

This is the step most often skipped, and the one that makes the rest defensible. In a short session with top management, agree which categories of impact matter (financial, legal and regulatory, contractual, reputational, customer, health and safety, environmental, staff) and what each rating level means in concrete terms for this organization. A "severe" financial impact might be a loss above a certain share of monthly revenue; a "severe" regulatory impact might be a formal enforcement notice. Concrete thresholds stop people rating the same impact differently. Also agree the time intervals to assess, for example 2 hours, 8 hours, 24 hours, 3 days, 1 week, 2 weeks and 1 month.

Step 3: prioritize products and services

Still with top management, list the products and services in scope and rate the impact of their unavailability over time using the agreed criteria. For each one, identify the point at which the impact becomes unacceptable (the MTPD) and the minimum level that would be acceptable during a disruption (the MBCO). Consider obligations to interested parties: contracts with service levels, legal duties, regulatory expectations and commitments to vulnerable customers. The outcome is a ranked list of products and services with time sensitivity.

Step 4: analyse processes and activities

For each prioritized product or service, map the processes that deliver it, then the activities inside each process. Meet the activity owners. For each activity, ask what happens over time if it stops, whether any work can be delayed and caught up later (backlog), what minimum level would be enough, when it must be resumed (RTO), how much data loss it can tolerate (RPO), and whether there are peak periods (month-end, holiday season, tax deadlines) when its sensitivity changes. Check that the activity's targets are consistent with the product or service it supports: an activity cannot have a longer RTO than the MTPD of the output that depends on it.

Step 5: identify resources and dependencies

For each prioritized activity, record what it needs to run at its minimum level, and when it needs it. Typical resource types are:

people: how many, which skills, which named experts, and whether they can work remotely;
information and data: records, paper files, databases and the RPO for each;
technology: applications, infrastructure, networks, end-user devices and communications;
premises and equipment: offices, warehouses, laboratories, vehicles, specialised machines;
supplies: raw materials, spare parts, consumables;
external parties: suppliers, outsourcers, cloud providers, utilities, partners;
other internal activities: for example, the warehouse cannot ship without the order system and the transport planning team.

Dependencies on external parties deserve special attention. Ask whether the supplier has its own continuity arrangements, whether the contract states recovery commitments, and whether there is an alternative. Dependencies are often hidden several layers deep: your payment provider relies on a data centre, which relies on a power supplier.

Step 6: analyse and consolidate

Once data is collected, the core team looks across it. Typical checks include: Are ratings consistent with the agreed criteria? Do activity RTOs fit the MTPDs of the products they support? Where several activities depend on the same resource, which is the shortest RTO, because that one drives the resource's recovery target? Do IT recovery capabilities actually meet the required RTOs and RPOs? Are any single points of failure visible, such as one expert or one supplier? The result is a consolidated list of prioritized activities, resource requirements over time and identified gaps, written up in a concise report.

Step 7: obtain endorsement and use the results

Present the consolidated results to top management. The goal is not a formal signature for its own sake: it is a conscious decision that these are the organization's priorities and timeframes, and that the gaps will be addressed or accepted. Endorsed BIA results then feed the next steps of the BCMS: selecting strategies and solutions, writing plans, and designing exercises.

Roles and artefacts

Role	Typical contribution	Typical artefact
Top management	Sponsors the BIA, sets criteria and product priorities, endorses results	Approved impact criteria; endorsement record
BIA project lead	Plans the project, designs tools, facilitates, consolidates	BIA plan, templates, consolidated report
Process and activity owners	Provide and validate information about their work	Completed activity records
IT and facilities teams	Compare required recovery targets with current capability	Capability and gap list
Procurement and supplier managers	Confirm supplier dependencies and their arrangements	Critical supplier list
Internal audit	Independently checks that the method was followed and results are traceable	Audit report

How often and how deep?

The TS stresses proportionality. A small organization with one site may complete a useful BIA in a few workshops; a multinational bank may run a rolling programme with many process owners and specialist tools. The BIA should be reviewed at planned intervals (many organizations choose annually) and when significant change occurs. Depth can also vary: you may analyse resources in detail only for the activities with the shortest timeframes.

Lesson 5 – Assessment, certification and compliance

No certification against ISO/TS 22317

ISO/TS 22317 contains guidance, not requirements, so there is nothing to certify against. No accredited certification body issues "ISO/TS 22317 certificates" to organizations, and claims of "compliance with ISO/TS 22317" mean only that an organization followed the guidance. That said, the TS is very useful in assessments, because it describes what a good BIA looks like.

Where the BIA is assessed: ISO 22301 certification

Organizations that seek certification of their BCMS are audited against ISO 22301 by certification bodies, usually accredited by a national accreditation body. The BIA is a mandatory element of ISO 22301 (clause 8, Operation, under the BIA and risk assessment requirements in 8.2), so auditors will examine it closely. They typically look for evidence that:

impact types and criteria were defined and approved, not invented by each department;
the activities that support products and services were identified;
impacts were assessed over time and timeframes for resuming prioritized activities were set within the point of unacceptable impact;
resources and dependencies, including suppliers and partners, were identified for prioritized activities;
the BIA is reviewed at planned intervals and when significant changes happen;
BIA results actually drove the choice of strategies, the content of plans and the scenarios of exercises.

An auditor will often trace a single product from the BIA through to the strategy, the plan and the latest exercise report. If the BIA says payments must be restored within four hours but the IT recovery plan targets 24 hours and nobody noticed, that is a finding. ISO/TS 22317 gives both the auditee and the auditor a shared reference for what "good" means.

Internal assessment and quality checks

Even without certification, an organization should check the quality of its BIA. Useful questions include:

Completeness: are all products and services in scope covered, and all prioritized activities analysed down to resources?
Consistency: were the same criteria and time intervals used everywhere, and do RTOs at lower levels fit the MTPDs above?
Validation: were figures challenged by someone other than the owner, and checked against real incident data or exercise results?
Traceability: can every recovery target be traced back to an impact rating and an approved criterion?
Currency: when was each part last reviewed, and have recent changes been reflected?
Use: are strategies, plans and exercises based on the BIA, or does the BIA sit on a shelf?

Internal audit, a second-line risk function or an external reviewer can run these checks. Some organizations use maturity models to rate their continuity programme, but these are not defined by ISO/TS 22317 itself.

Regulation and contracts

Many regulators expect organizations to understand the impact of disruptions to their important services, and many large customers ask suppliers for evidence of business continuity, including a BIA. Specific rules vary by sector and country, so check the rules that apply to you. ISO/TS 22317 does not replace those rules, but a BIA built along its lines is usually a strong foundation for meeting them. Professional bodies such as the Business Continuity Institute and DRI International also publish practice guidance that covers the BIA and that fits well with the TS.

Lesson 6 – Worked example

The organization

"FreshCart" is a fictional regional online grocery retailer with 900 staff, one main distribution centre with chilled and frozen storage, a fleet of 120 delivery vans and a website and mobile app hosted with a cloud provider. Card payments are processed by an external payment provider. FreshCart is pursuing ISO 22301 certification and uses ISO/TS 22317 to plan its first proper BIA. Its previous "BIA" was a spreadsheet in which every department had rated itself "critical".

Prerequisites

The chief operating officer agrees to sponsor the BIA and chairs a one-hour kick-off with the executive team. The scope matches the BCMS scope: home delivery, click-and-collect and supply to business customers (cafés and offices), all run from the main distribution centre and head office. The business continuity manager is appointed project lead, with two analysts. Process owners for ordering, warehouse, transport, customer service, payments, purchasing and IT are named as information providers. The executive team agrees to review and endorse the results in eight weeks.

Impact criteria and time intervals

In a two-hour workshop, the executive team agrees six impact categories: financial, customer, contractual, regulatory (including food safety), reputational and health and safety. For each, four levels are defined with concrete thresholds. For example, "severe" financial impact means a loss greater than one week's gross margin; "severe" food safety impact means any risk that unsafe chilled food reaches customers. The time intervals are 4 hours, 12 hours, 24 hours, 48 hours, 1 week and 2 weeks.

Products and services

The executive team rates the three services:

Service	Impact becomes unacceptable at	Minimum acceptable level	Notes
Home delivery	48 hours (MTPD)	50 % of normal orders	Customers switch to competitors quickly; peak before public holidays
Click-and-collect	1 week	Main stores' pick-up points only	Smaller share of revenue
Supply to business customers	24 hours	Top 40 contracted customers	Contracts include penalties for missed next-day deliveries

The surprise is that business supply, a small share of revenue, has the shortest MTPD because of contract penalties and the risk of losing whole accounts. This would have been invisible in a revenue-only ranking.

Processes and activities

The team maps order fulfilment into activities: online order taking, payment authorisation, stock allocation, picking and packing, chilled storage, route planning, delivery and customer contact. Owners rate impacts over time in short workshops. The results include:

Chilled and frozen storage: RTO 2 hours, because stock spoils and food safety rules apply after a short time without refrigeration.
Online order taking: RTO 8 hours at a minimum of 50 % capacity; RPO 15 minutes, because lost orders cannot easily be recreated.
Route planning: RTO 12 hours; the team can fall back to manual planning for a reduced number of routes.
Customer contact: RTO 24 hours; backlog can be cleared later.

The warehouse manager initially claims picking needs an RTO of one hour. The analyst asks what would actually happen in the first four hours: orders would queue and could be picked later in the day without missing delivery slots. Using the agreed criteria, the impact stays "minor" for 8 hours, so the RTO is set at 8 hours. This is the challenge that a top-down, criteria-based BIA makes possible.

Resources and dependencies

For each prioritized activity, the team records resources and dependencies. Picking needs 60 trained pickers per shift (minimum 30), handheld scanners, the warehouse management system and the chilled store. Order taking depends on the cloud-hosted web platform and the payment provider. Chilled storage depends on the refrigeration plant, a maintenance contractor and grid power, with a backup generator that has fuel for 12 hours. Route planning depends on a software-as-a-service tool and one specialist planner who knows the manual method.

Analysis and consolidation

Consolidation reveals four gaps:

The IT disaster recovery plan restores the warehouse management system in 48 hours, but picking needs it within 8 hours.
The generator fuel contract guarantees delivery in 24 hours, but the generator runs for only 12 hours.
The manual route-planning method depends on one person: a single point of failure.
The payment provider's contract contains no recovery commitment at all.

The team also notices that several activities share the warehouse management system; the shortest requirement (8 hours) becomes the target for that resource.

Endorsement and next steps

The BIA report, twelve pages with a one-page summary, goes to the executive team. They endorse the priorities and timeframes, accept a temporary risk on the payment provider while procurement renegotiates, and approve funding to improve the warehouse system's recovery. The endorsed results now feed strategy selection: a warm standby for the warehouse system, a second fuel supplier, cross-training two more planners. The BIA is scheduled for annual review and immediate update when a second distribution centre opens next year.

The example shows the main lessons of ISO/TS 22317 in action: commitment and criteria first, a top-down sequence, challenge based on agreed criteria, attention to resources and suppliers, consolidation that exposes gaps, and endorsement that turns analysis into decisions.

Lesson 7 – Relationship to other standards and frameworks

ISO/TS 22317 belongs to a family of documents produced by ISO/TC 292. Each has a specific job, and the BIA is the hinge between understanding the organization and choosing how to protect it.

Figure 4 – Where ISO/TS 22317 sits among the ISO security and resilience documents and their neighbours.

Document	Type	What it covers	Relationship to ISO/TS 22317
ISO 22301:2019	Requirements (certifiable)	The BCMS, including the requirement to perform a BIA and a risk assessment	Sets what the BIA must achieve; ISO/TS 22317 explains how to do it well
ISO 22313:2020	Guidance	How to apply all of ISO 22301	Gives an overview of the BIA; ISO/TS 22317 goes into much more depth
ISO/TS 22331:2018	Guidance	Determining business continuity strategies and solutions	Uses BIA results (priorities, timeframes, resources) as its main input
ISO/TS 22332:2021	Guidance	Developing business continuity plans and procedures	Plans implement the recovery order and timeframes set in the BIA
ISO 31000:2018	Guidance	General principles and process for risk management	Risk assessment complements the BIA: likelihood of causes versus consequence over time
ISO 22316:2017	Guidance	Principles and attributes of organizational resilience	Places continuity, and therefore the BIA, inside the wider resilience picture
ISO/IEC 27031	Guidance	ICT readiness for business continuity	ICT recovery objectives should be derived from BIA requirements
NIST SP 800-34 Rev. 1	US government guide	Contingency planning for information systems, including a system-level BIA	Similar ideas at the information system level; useful where US federal practice applies

ISO/IEC 27001 and IT service management

Information security management systems based on ISO/IEC 27001 include controls about information security during disruption and ICT readiness for business continuity. Their recovery requirements should come from a BIA rather than from the IT department's assumptions, so organizations running both systems should share one BIA. In IT service management (for example ITIL or ISO/IEC 20000-1 practices), service continuity and availability targets should likewise trace back to business impact.

Professional practice frameworks

The Business Continuity Institute's Good Practice Guidelines and DRI International's Professional Practices are widely used by practitioners and include the BIA as a central practice. They are not ISO documents, but they are consistent with the ISO approach and add practical tips, training and professional credentials for individuals. When people say they are "certified" in business continuity, they usually mean a personal credential from one of these bodies, not an organizational certification against ISO/TS 22317.

Common pitfalls and best practices

Common pitfalls

Skipping top management – the continuity team sets the criteria and priorities alone, so results lack authority and are ignored when decisions are needed.
Self-rating without challenge – every department rates itself as critical, the list of prioritized activities becomes the whole organization, and the BIA loses its value for decision-making.
Starting from IT systems – the analysis lists applications and their owners' preferred recovery times instead of starting from products and services, so business dependencies on people, sites and suppliers are missed.
Vague criteria – words like "high" and "low" without thresholds lead to inconsistent ratings that cannot be compared.
Ignoring time – rating a single "impact score" instead of impact over several intervals hides the point at which damage becomes unacceptable.
Treating the BIA as a one-off – the report is filed and never updated, while products, suppliers and systems change.
Collecting but not consolidating – data is gathered from every team but nobody checks consistency, shared resources or capability gaps.

Best practices

Agree criteria first – get top management to approve concrete, quantified impact categories and levels before collecting data.
Work top-down – begin with products and services and let each lower level inherit its time sensitivity from the level above.
Validate with evidence – test owners' estimates against incident history, contract terms, regulatory deadlines and exercise results.
Map external dependencies – include suppliers, outsourcers, cloud providers and utilities, and check their own recovery commitments.
Compare requirement with capability – put required RTOs and RPOs side by side with what IT and facilities can actually deliver, and report the gaps.
Keep it proportionate – use simple tools for simple organizations and go deeper only where timeframes are short.
Close the loop – make sure strategies, plans and exercises are traceably based on the endorsed BIA, and update it after significant change.

Summary and key takeaways

ISO/TS 22317:2021 is ISO's guidance on how to establish, run and maintain a documented business impact analysis; it is a Technical Specification and does not impose one method.
A BIA analyses how the impacts of a disruption grow over time and uses that analysis to set priorities and recovery timeframes, independent of the cause of the disruption.
Top management's commitment, approved impact criteria and a clear scope are prerequisites, not optional extras.
The BIA works top-down: products and services, then processes, then activities, then the resources and dependencies they need.
MTPD marks when impacts become unacceptable; RTO is set inside it; RPO limits data loss; MBCO defines the minimum acceptable output during disruption.
Analysis and consolidation turn raw data into decisions by checking consistency, finding shared resources and exposing capability gaps.
There is no certification against ISO/TS 22317, but the BIA is a mandatory element audited in ISO 22301 certification.
The BIA is the bridge between understanding the organization and choosing continuity strategies (ISO/TS 22331) and plans (ISO/TS 22332).

Reflection questions

Think of one product or service your organization delivers. At what point in time would an interruption become unacceptable, and what evidence would you use to convince top management?
Which impact categories would matter most in your organization, and how would you define a "severe" level for two of them in concrete, measurable terms?
Choose one important activity in your area. List its resources and dependencies, including at least one external party, and identify any single point of failure.
Where could a department's estimate of its own recovery needs be inflated or underestimated, and how would you challenge it fairly using agreed criteria?
If your BIA showed that a key system takes three times longer to recover than the business can tolerate, what options would you present to top management and how would you decide between them?