ISO/TS 22317:2015
(Main)Societal security - Business continuity management systems - Guidelines for business impact analysis (BIA)
Societal security - Business continuity management systems - Guidelines for business impact analysis (BIA)
ISO/TS 22317:2015 provides guidance for an organization to establish, implement, and maintain a formal and documented business impact analysis (BIA) process. This Technical Specification does not prescribe a uniform process for performing a BIA, but will assist an organization to design a BIA process that is appropriate to its needs. ISO/TS 22317:2015 is applicable to all organizations regardless of type, size, and nature, whether in the private, public, or not-for-profit sectors. The guidance can be adapted to the needs, objectives, resources, and constraints of the organization. It is intended for use by those responsible for the BIA process.
Sécurité sociétale — Systèmes de management de la continuité d'activité — Lignes directrices pour l'analyse d'impact sur l'activité
L'ISO/TS 22317:2015 fournit des préconisations visant à permettre à une organisation de créer, mettre en ?uvre et tenir à jour un processus formel et documenté d'analyse d'impact sur l'activité (AIA). L'ISO/TS 22317:2015 n'impose pas de processus unique pour l'exécution d'une AIA. Toutefois, elle peut servir de support à une organisation pour la conception d'un processus d'AIA conforme à ses besoins. L'ISO/TS 22317:2015 est applicable à toutes les organisations, quels que soient leur type, leur taille et leur nature, qu'ils appartiennent au secteur privé ou au secteur public et qu'ils soient à but lucratif ou non. Les préconisations qu'elle fournit peuvent être adaptées en fonction des besoins, objectifs, ressources et contraintes de l'organisation. L'ISO/TS 22317:2015 est destinée aux personnes responsables du processus d'AIA.
General Information
Relations
Frequently Asked Questions
ISO/TS 22317:2015 is a technical specification published by the International Organization for Standardization (ISO). Its full title is "Societal security - Business continuity management systems - Guidelines for business impact analysis (BIA)". This standard covers: ISO/TS 22317:2015 provides guidance for an organization to establish, implement, and maintain a formal and documented business impact analysis (BIA) process. This Technical Specification does not prescribe a uniform process for performing a BIA, but will assist an organization to design a BIA process that is appropriate to its needs. ISO/TS 22317:2015 is applicable to all organizations regardless of type, size, and nature, whether in the private, public, or not-for-profit sectors. The guidance can be adapted to the needs, objectives, resources, and constraints of the organization. It is intended for use by those responsible for the BIA process.
ISO/TS 22317:2015 provides guidance for an organization to establish, implement, and maintain a formal and documented business impact analysis (BIA) process. This Technical Specification does not prescribe a uniform process for performing a BIA, but will assist an organization to design a BIA process that is appropriate to its needs. ISO/TS 22317:2015 is applicable to all organizations regardless of type, size, and nature, whether in the private, public, or not-for-profit sectors. The guidance can be adapted to the needs, objectives, resources, and constraints of the organization. It is intended for use by those responsible for the BIA process.
ISO/TS 22317:2015 is classified under the following ICS (International Classification for Standards) categories: 03.100.01 - Company organization and management in general; 03.100.70 - Management systems. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO/TS 22317:2015 has the following relationships with other standards: It is inter standard links to ISO/TS 22317:2021. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
You can purchase ISO/TS 22317:2015 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.
Standards Content (Sample)
TECHNICAL ISO/TS
SPECIFICATION 22317
First edition
2015-09-15
Societal security — Business
continuity management systems
— Guidelines for business impact
analysis (BIA)
Sécurité sociétale — Systèmes de management de la continuité en
affaires — Lignes directrices pour l’analyse d’impact en affaires
Reference number
©
ISO 2015
© ISO 2015, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2015 – All rights reserved
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Prerequisites . 1
4.1 General . 1
4.2 BC programme context and scope . 2
4.2.1 BC programme context . 2
4.2.2 Scope of the BC programme . 2
4.3 BC programme roles. 2
4.3.1 BC programme roles and responsibilities . 2
4.3.2 BIA process-specific roles and competencies . 2
4.4 BC programme commitment . 4
4.5 BC programme resources . 4
5 Performing the business impact analysis . 4
5.1 General . 4
5.2 Project planning and management . 5
5.2.1 General. 5
5.2.2 Initial BIA considerations . 6
5.3 Product and service prioritization . 6
5.3.1 Overview . 6
5.3.2 Inputs . 8
5.3.3 Outcomes . 9
5.4 Process prioritization . 9
5.4.1 General. 9
5.4.2 Inputs . 9
5.4.3 Outcomes . 9
5.5 Activity prioritization .10
5.5.1 Overview .10
5.5.2 Inputs .10
5.5.3 Information collection.11
5.5.4 Outcomes .12
5.6 Analysis and consolidation .12
5.6.1 Overview .12
5.6.2 Inputs .12
5.6.3 Methods .12
5.6.4 Outcomes .13
5.7 Obtain top management endorsement of BIA results .13
5.7.1 General.13
5.7.2 Inputs .13
5.7.3 Methods .13
5.7.4 Outcomes .14
5.8 After the BIA — Business continuity strategy selection .14
6 BIA process monitoring and review .14
Annex A (informative) Business impact analysis within an ISO 22301 business continuity
management system .16
Annex B (informative) Business impact analysis terminology mapping .17
Annex C (informative) Business impact analysis information collecting methods.18
Annex D (informative) Other uses for the business impact analysis process .24
Bibliography .27
iv © ISO 2015 – All rights reserved
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT) see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/TC 292, Security and resilience.
Introduction
This Technical Specification provides detailed guidance for establishing, implementing, and maintaining
a business impact analysis (BIA) process consistent with the requirements in ISO 22301. This Technical
Specification is applicable to the performance of any BIA process, whether part of a business continuity
management system (BCMS) or business continuity programme (BC programme). Hereinafter, BC
programme means either BCMS or BC programme.
Figure 1 notes the relationship of the BIA process to the BC programme as a whole. The organization
should complete a cycle of the BIA process before business continuity strategies are selected.
Figure 1 — Elements of business continuity management
(Source: ISO 22313)
The BIA process analyses the consequences of a disruptive incident on the organization. The outcome is
a statement and justification of business continuity requirements.
The BIA process consists of a number of individual BIAs, each focusing of a sub-set of the BC programme
scope. The BIA process prioritizes products and services, and continues with prioritizing processes and
activities that together cover the entire scope of the BC programme. After a period of time determined
by the organization, individual BIAs are repeated to ensure that the BC requirements remain current.
NOTE In this Technical Specification, business continuity requirements has the same meaning as continuity
and recovery priorities, objectives, and targets (ISO 22301:2012, 8.2.2).
The purposes of this Technical Specification are the following:
— provide a basis for understanding, developing, implementing, reviewing, maintaining, and
continually improving an effective BIA process within an organization;
— provide guidance for planning, conducting, and reporting on a BIA;
— assist the organization with conducting a BIA in a consistent manner that reflects good practices;
— enable proper coordination between the BIA process and the overarching BC programme.
vi © ISO 2015 – All rights reserved
The outcomes of the BIA process include the following:
— endorsement or modification of the organization’s BC programme scope;
— identification of legal, regulatory, and contractual requirements (obligations) and their effect on
business continuity requirements;
— evaluation of impacts on the organization over time, which serves as the justification for business
continuity requirements (time and capability);
— identification and confirmation of product/service delivery requirements following a disruptive
incident, which then sets the prioritized timeframes for activities and resources;
— identification and establishment of the relationships between products/services, processes,
activities, and resources;
— determination of the resources needed to perform prioritized activities (e.g. facilities; people;
equipment; information, communication and technology assets; supplies; and financing);
— understanding of the dependencies on other activities, supply chains, partners, and other
interested parties;
— determination of how up to date the information needs to be.
NOTE For purposes of this Technical Specification, supply chains produce supplies of goods, works, and
services, which are referred to as ‘supplies‘ throughout the remainder of this document.
The following diagram displays the BIA process, together with prerequisites and its relationship
to strategy identification. The clauses referenced in the diagram are subsections of this Technical
Specification.
Figure 2 — Business impact analysis process
TECHNICAL SPECIFICATION ISO/TS 22317:2015(E)
Societal security — Business continuity management
systems — Guidelines for business impact analysis (BIA)
1 Scope
This Technical Specification provides guidance for an organization to establish, implement, and
maintain a formal and documented business impact analysis (BIA) process. This Technical Specification
does not prescribe a uniform process for performing a BIA, but will assist an organization to design a
BIA process that is appropriate to its needs.
This Technical Specification is applicable to all organizations regardless of type, size, and nature,
whether in the private, public, or not-for-profit sectors. The guidance can be adapted to the needs,
objectives, resources, and constraints of the organization.
It is intended for use by those responsible for the BIA process.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ISO 22300, Societal security — Terminology
3 Terms and definitions
For the purposes of this document, the terms and definitions in ISO 22300 apply.
NOTE All terms and definitions contained in ISO 22300 are available on the ISO Online Browsing Platform:
www.iso.org/obp.
4 Prerequisites
4.1 General
As noted in the Introduction, this Technical Specification is consistent with ISO 22301, but it could be
used to develop, implement, review, maintain, and continually improve a BIA process addressing other
standards or regulatory requirements. Whether part of a BCMS or a BC programme, the organization
should consider a number of prerequisites before starting the BIA process. Clause 4 summarizes these
prerequisites, many of which are from ISO 22301.
The organization should take a number of steps within the BC programme before beginning the BIA
process, which include the following:
— define the context and scope (4.2);
— define and communicate roles and responsibilities (4.3);
— obtain leadership commitment (4.4);
— allocate adequate resources (4.5).
NOTE For additional information, see Annex A for a mapping of each step to ISO 22301.
4.2 BC programme context and scope
4.2.1 BC programme context
Successful BIA process outcomes are dependent on the organization understanding the following:
— the external environment in which it operates so that it can achieve its purpose by delivering its
products and services to customers;
— the internal operating environment, inclusive of processes, activities, and resources, as well as the
potential impact caused by disrupting the delivery of products and services; and
— laws and regulations mandating the BIA process and how it is performed.
NOTE In organizations operating within a non-commercial environment, the ‘customer’ can be the public or
an overseeing authority, such as government.
4.2.2 Scope of the BC programme
Before determining the BIA process scope, the organization should define and document the scope of
the BC programme in terms of its products and services.
The BIA process may assist the organization to review the scope of the BC programme.
Following the definition of the BC programme scope, the organization can determine the BIA process
scope which may be conducted as a single BIA to cover the whole scope of the BC programme; or
undertaken in a number of phases that, over time, covers the whole scope of the BC programme.
NOTE If the organization chooses to undertake the BIA process in phases, it should first determine the
prioritization of all products and services (see 5.2) and then continue with the remaining individual BIAs.
4.3 BC programme roles
4.3.1 BC programme roles and responsibilities
Prior to performing the BIA process, top management should ensure that the responsibilities and
authorities for relevant roles are assigned and communicated within the organization.
4.3.2 BIA process-specific roles and competencies
Following the assignment of BC programme roles, top management should provide resources necessary
to perform the BIA process, which may include appointing the following roles:
— the person sponsoring the BIA process;
— BIA steering committee;
— the person leading the BIA process;
— the person managing the BIA project (project manager);
— process owners;
— activity managers.
The person sponsoring the BIA process should
— be an executive representing top management,
— be well respected within the organization by other members of top management,
— have an organization-wide perspective,
2 © ISO 2015 – All rights reserved
— have the authority to commit the organization to action, and
— make final decisions regarding the BIA process.
The BIA steering committee should
— represent top management,
— provide ongoing advice and guidance on the conduct of the BIA process,
— agree on the methods and outcomes,
— make decisions regarding business continuity requirements, and
— assist the person leading the BIA process and project manager in determining the competences
required for BIA process-specific roles and responsibilities and the awareness, knowledge,
understanding, skills, and experience needed to fulfil them.
The person leading the BIA process should
— have an understanding of the organization, in particular products, services, processes, and
activities, and
— have experience in conducting a BIA process.
The person managing the BIA project should
— plan for and manage the BIA process,
— have an understanding of project planning tasks, and
— be familiar with the BIA process.
Process owners should have a relatively detailed understanding of the process they represent in
order to assist the project manager in identifying subject matter experts, organizational units, and
impacts of downtime.
Activity managers should
— have very detailed understanding of the activity in which they represent, including all of the
resources that enable the activity to operate, and
— be aware of alternate processes and resources that could be available in the event of a loss of
primary resources.
NOTE In smaller organizations, these roles can be combined.
The organization should ensure the competence of persons leading or participating in the BIA process.
Competences should include skills and abilities related to the following:
— project/programme planning and management;
— information gathering;
— analysis;
— effective communication and collaboration;
— translating organizational objectives to business continuity requirements and resource needs;
— applying BIA concepts in the specific organization’s context;
— knowledge of the organization, its products and services, processes, activities, and resources.
4.4 BC programme commitment
Top management commitment to the BIA process is necessary to ensure effective participation. To
obtain this support, the organization may consider communicating the BIA process’ value that includes
the following:
— ensuring the appropriate and most cost effective strategies are selected by determining the correct
business continuity requirements;
— providing evidence to management that business continuity requirements align with
organizational objectives;
— ensuring the organization meets its legal, contractual, and customer requirements during a
disruptive incident;
— identifying linkages between products and services and process, activities, and resources;
— providing an overview of the organization that can be used to improve its efficiency or explore new
opportunities (see Annex D).
4.5 BC programme resources
The organization should provide resources to the BIA process that are sufficient to the following:
— achieve its BC policy and objectives;
— make adequate provision for people and people-related resources, including the time to fulfil BIA
process-specific roles and responsibilities, and training and awareness;
— meet the changing requirements of the organization;
— provide for ongoing operation and continual improvement of the BC programme, as well as the BIA
process.
5 Performing the business impact analysis
5.1 General
The BIA process prioritizes the various organizational components so that product and service delivery
can be resumed in a predetermined timeframe following a disruptive incident to the satisfaction of
interested parties. For purposes of this Technical Specification and consistent with ISO 22301, products
and services are created by processes that are made up of activities.
The products and services are prioritized first; this sets the time and service level parameters for
process prioritization. If required by the complexity of the organization, the processes can then be
separated into their constituent activities for prioritization.
Suitable, adequate, and effective outcomes of subsequent phases of the BC programme depend on the
accuracy of the BIA process. Each BIA should be completed consistently, carefully, and thoroughly.
Figure 3 shows how the various elements of the BIA process relate to each other. The diagram illustrates
that there can be overlap between the timing of these constituent phases of the process.
4 © ISO 2015 – All rights reserved
Figure 3 — Business impact analysis relationships
Successful BIA process outcomes may depend on the following:
— identifying customers and other interested parties, and anticipating their reactions to a
disruptive incident;
— engaging all relevant interested parties with an appropriate mandate;
— developing appropriate skills and competencies within the organization or project to conduct the
analysis and present the results;
— gathering generally complete and accurate information (some information may be unavailable,
poorly understood, confidential or withheld, thus identifying areas for further work);
— ensuring that those contributing to the BIA information gathering process have sufficient knowledge
and authority to speak on behalf of the organization, process, or activity;
— ensuring management representatives have sufficient authority to approve BIA results.
5.2 Project planning and management
5.2.1 General
Although BIA is a process, organizations may use project management methods for a phase of the
BIA process. As the BIA process is potentially complex, using project management methods allows
organizations to coordinate resources and timelines.
Project planning tasks may include the following:
— deciding on the scope of this phase of the BIA process;
— communicating expectations to BIA process participants;
— identifying the person sponsoring the BIA process and top management participation;
— establishing BIA process-specific roles and responsibilities (including competencies);
— establishing the project plan;
— allocating resources for the BIA project;
— gaining acceptance of the project approach and plan;
— establishing or sourcing the skills necessary to meet BIA process objectives.
Project management tasks may include the following:
— implementing the BIA process (see 5.2 through 5.6);
— monitoring the implementation of the BIA process (see through 5.6);
— developing periodic reports on the status, noting performance expectations and recommendations
to improve performance in line with top management expectations (see 5.2);
— performing modifications of the BIA process approach and scope to meet top management expectations
and external (regulatory, statutory, customer, contractual) requirements (see Clause 6);
— collecting and reviewing lessons learned (see Clause 6);
— making recommendations regarding BIA process improvement for future implementation (see
Clause 6).
5.2.2 Initial BIA considerations
An organization undertaking a BIA for the first time should plan additional time to
— identify products and services,
— create awareness and ensure education,
— identify a top management representative to sponsor the BIA process and/or BIA steering committee,
— determine impact categories and criteria,
— determine importance of the organization’s business/political environment,
— identify the organization’s structure to an appropriate level of detail,
— identify and select the right information sources for information gathering,
— document the work flow to a process and activity level, and
— complete information gathering through document review, interviews, workshops, and
questionnaires.
During the initial BIA, the organization may use the BIA results to prioritize subsequent business
continuity phases, including strategy selection.
5.3 Product and service prioritization
5.3.1 Overview
As the first step in the BIA process, top management should agree on the priority of products and
services following a disruptive incident which may threaten the achievement of their objectives.
6 © ISO 2015 – All rights reserved
It is top management’s responsibility to make these decisions because they
— set the objectives of the organization,
— have the ultimate responsibility for ensuring the continuity of the organization and the fulfilment
of its objectives,
— have the widest view of the entire organization from which to assess priorities,
— can choose to override contractual and other obligations in setting priorities in exceptional
circumstances, and
— are aware of planned future changes and other factors which may affect the business continuity
requirements.
If an organization has too many products and services to identify individually, the organization may
group together products and services when they have similar priorities. Conversely, it may be necessary
for the organization to identify customers that, despite sharing the same products and services, have
differing delivery timeframe expectations, or their value to the organization differs.
For each group of products and services, the organization should understand the impacts that may
result from a disruptive incident by
— identifying customer expectations and obligations, and the penalties associated with failing to
meet them and
— taking into account the views of other interested parties in assessing impacts.
Other interested parties and their reaction to a disruptive incident may include the following:
— partner organizations: their willingness to continue to cooperate;
— media and society: brand value and public opinion;
— potential customers: loss of current and future market share;
— shareholders: effect on current share price and future investment;
— competitors: who may attempt to take advantage of the situation;
— staff: retention;
— regulators and government: penalties and rule changes.
The organization may use the examples in Table 1 to understand the impacts of a disruptive incident on
the organization over time:
Table 1 — Product and service level impact category examples
Impact categories Examples of impacts
Financial Financial losses due to fines, penalties, lost profits, or diminished market share
Reputational Negative opinion or brand damage
Legal and regulatory Litigation liability and withdrawal of license to trade
Contractual Breach of contracts or obligations between organizations
Business objectives Failure to deliver on objectives or take advantage of opportunities
Impacts almost always increase over time. However, impacts may not increase at the same rate. For
instance, financial impacts can suddenly increase as contract penalties are incurred or as customers
are lost, and reputational damage can occur suddenly at a point during the disruptive incident. See
Figure 4 for an example of how different impact categories increase over time.
Figure 4 — Impact of a disruptive incident on an organization over time
For each group of products and services, the top management should decide and document the following:
— time after which continued failure to deliver them becomes unacceptable to the organization
because the impacts noted above threaten its survival or make its objectives no longer achievable
(see Annex B for related terms);
— reason(s) why this time period has been identified with reference to the growing impacts over time.
The organization may, based on the example timeframe in Figure 4, set a target time for resuming
delivery of products and services at specified minimum levels (see Annex B for related terms).
5.3.2 Inputs
Top management may consider the following information in setting business continuity requirements
for products and services:
— current organizational mission, objectives, and strategic direction;
— current BC programme scope;
— assessment of product and service priorities from a previous top management review;
— list of legal and regulatory requirements to which the organization or specific products and services
are subject (as well as an assessment of the consequences of breaching each requirement);
— contractual requirements, including penalties for failure to deliver;
— assessment of reputational, financial, or other impacts for failure to deliver;
8 © ISO 2015 – All rights reserved
— recent post-incident reports which describe the impact associated with the disruptive incident.
5.3.3 Outcomes
The outcomes of the product and service prioritization process should be
— endorsement or modification of the organization’s BC programme scope,
— identification of legal, regulatory and contractual requirements (obligations),
— evaluation of impacts over time as it relates to a failure to deliver products or services, which serves
as the justification for business continuity requirements,
— confirmation of product and service delivery requirements (that may include time, quality, quantity,
service levels, and capability specifications) following a disruptive incident that then sets the
priorities for activities and resources,
— identification of processes (that deliver the products and services),
— nomination of lead personnel to assist in identifying which processes deliver products and
services, and
— documentation of a list of prioritized products and services (grouped by timeframe or customer).
The organization may retain documentation describing the decisions made during the product and
service prioritization process.
5.4 Process prioritization
5.4.1 General
A process is a set of interrelated or interacting activities which transform inputs into outputs
(ISO 22300). Its priority is determined by the priority of the products and services which are its output.
Depending on its complexity, the organization may choose to omit process prioritization and proceed
directly to activity prioritization. If the organization chooses to perform a process prioritization, the
organization should determine activities that make up those processes.
5.4.2 Inputs
The information required for process prioritization includes the following:
— the scope of this BIA;
— product and service delivery requirements (which may include time, quality, quantity, service levels,
and capability specifications);
— processes and the products and services they deliver;
— impacts over time of a failure to deliver products and services;
— legal, regulatory, and contractual requirements (obligations).
5.4.3 Outcomes
The outcomes of process prioritization should be the following:
— identification of the relationship between product and services, processes, and activities;
— identification of dependencies on other business processes;
— evaluation of impacts over time of a process failure (the impact categories in Table 1 could be used
to confirm the impacts of process disruption);
— priorities of processes;
— interdependency analysis of the processes that deliver products and services to customers;
— interdependency analysis of the activities that deliver processes;
— documented list of prioritized processes that deliver products and services; and
— initial documented list of activities that deliver processes.
5.5 Activity prioritization
5.5.1 Overview
An activity is a set of one or more tasks with a defined output. The priority of the activity is determined
by the priority of the processes of which it forms a part.
The organization should perform activity level prioritization to understand the resources needed to
operate each activity following a disruptive incident, and to confirm the potential impact associated
with a disruptive incident.
Organizations should perform activity level prioritization to obtain a detailed understanding of day-to-
day resource requirements, enabling the organization to identify the quantity and timing of resources
necessary for recovery and to help confirm impact-related conclusions developed at the process level.
Resource-related information includes the following:
— people/skills/roles;
— facilities;
— equipment;
— records;
— financing;
— information and communications technologies (including applications, data, telephony, and networks);
— supplies, supply chains, and partners;
— dependencies on other processes and activities;
— special tools, spare parts, and consumables;
— limitations imposed on resources by logistics or regulations.
In addition to the impacts already considered in Table 1, the organization may consider evaluating
operational impact, such as delays due to backlog of workload or manual workarounds or impacts to
interrelated activities.
5.5.2 Inputs
The inputs required to undertake activity prioritization include the following:
— scope of this BIA;
— process priorities;
— organizational chart;
10 © ISO 2015 – All rights reserved
— constituent activities of processes.
5.5.3 Information collection
The organization needs to collect the following information to perform the activity level BIA, including
activity detail, resource requirements, and interdependencies.
5.5.3.1 Activity detail
The organization may collect the following details during activity prioritization:
— the processes that this activity supports;
— the operational methods of the activity;
— the duration or lead-time of this activity;
— fluctuations in demand or peak operating periods;
— factors not already discovered that may affect the determination of business continuity requirements
(e.g. backlogs or legal and regulatory requirements of this activity).
5.5.3.2 Resource requirements
The resource information to be collected during an activity prioritization may include the following:
— staff and contractors (including minimum acceptable level for required service, and knowledge,
skills or qualifications required);
— workplace requirements;
— IT applications and communications (noting special requirements);
— records (e.g. electronic or hard copy);
— equipment (e.g. information and communications technology (ICT), office equipment,
manufacturing equipment);
— components and raw materials.
5.5.3.3 Interdependencies
The interdependency information required to be collected during an activity prioritization includes
the following:
— reliance on other internal activities and resources, or supply chains;
— reliance on other internal activities on the outputs of this activity.
For the specification of ICT requirements, the following additional information may be collected:
— ICT asset name, location, and configuration (e.g. memory, capacity, processor speed, and disk
drive space);
— dependencies on other ICT assets;
— end user profiles and usage characteristics;
— unique legal or regulatory requirements regarding the use of the ICT asset.
5.5.4 Outcomes
The outcomes of activity prioritization should be the following:
— confirmation of impacts over time, which serves as justification for business continuity requirements
(time and capability);
— resource needs to perform each prioritized activity (including facilities, people, equipment, ICT
assets, supplies, finance and information);
— how up to date the information needs to be (see Annex B for related terms);
— dependencies on other activities, supply chains, partners, and other interested parties;
— analysis of dependencies on the resources needed to deliver each activity;
— documented list of activities and their prioritized timeframes that support processes;
— documented list of resources and their prioritized timeframes that enable activities.
5.6 Analysis and consolidation
5.6.1 Overview
While analysis occurs during the entire BIA process, the organization should perform a final analysis
(or consolidation of analyses). This involves reviewing the outcomes from the prioritization, and
drawing conclusions that lead to business continuity requirements.
The organization should choose the appropriate quantitative and/or qualitative analytic approach(es),
which may be influenced by the type, size, or nature of the organization, as well as resource and skill
constraints. The approach(es) selected will also depend on the type of information gathered.
Regardless of approach, the organization should challenge and check the information to ensure that it is
— correct: accurate and reliable,
— credible: believable and reasonable,
— consistent: clear and repeatable,
— current: up-to-date and available in a timely manner, and
— complete: comprehensive.
5.6.2 Inputs
The organization should obtain validated and approved information gathered from all levels of the BIA
process in order to perform analyses.
5.6.3 Methods
The organization may use a combination of quantitative and qualitative techniques to analyze the
information collected. Table 2 contains examples of analytic techniques.
12 © ISO 2015 – All rights reserved
Table 2 — BIA analysis techniques
Quantitative analytic techniques Qualitative analytic techniques
Common sense and cross checks
Stress testing
Interdependency analysis
Review of post-incident reviews and recommendations
Financial analysis approaches
Supplier-Input-Process-Output-Customer (SIPOC)
Fishbone (Ishikawa) diagrams
5.6.4 Outcomes
The outcomes of applying analysis techniques and consolidating information are the following:
— confirmation of impacts over time;
— review and confirmation of resource dependencies and requirements;
— consolidation of resource requirements (e.g. across processes, organizational structures, or locations);
— review and confirmation of the interdependencies of processes and activities, and their relation to
the delivery of products and services, that serve as the input to business continuity strategy selection.
5.7 Obtain top management endorsement of BIA results
5.7.1 General
The organization should seek management endorsement of results, including product and service,
process, activity, and resource prioritization following one or more individual BIAs.
The organization should compile BIA results to ensure the information collected can be maintained and
updated on a periodic basis before seeking management endorsement. The presentation of BIA results
can be in a variety of media and may contain different levels of detail depending on the audience.
The organization should provide the following key BIA results to top management for their review,
amendment (if necessary), and endorsement before moving on to next steps:
— product and servic
...
SPÉCIFICATION ISO/TS
TECHNIQUE 22317
Première édition
2015-09-15
Sécurité sociétale — Systèmes
de management de la continuité
d’activité — Lignes directrices pour
l’analyse d’impact sur l’activité
Societal security — Business continuity management systems —
Guidelines for business impact analysis (BIA)
Numéro de référence
©
ISO 2015
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2015, Publié en Suisse
Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite ni utilisée
sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie, l’affichage sur
l’internet ou sur un Intranet, sans autorisation écrite préalable. Les demandes d’autorisation peuvent être adressées à l’ISO à
l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2015 – Tous droits réservés
Sommaire Page
Avant-propos .v
Introduction .vi
1 Domaine d’application . 1
2 Références normatives . 1
3 Termes et définitions . 1
4 Conditions préalables . 1
4.1 Généralités . 1
4.2 Contexte et domaine d’application du programme de continuité d’activité . 2
4.2.1 Contexte du programme de continuité d’activité . 2
4.2.2 Domaine d’application du programme de continuité d’activité . 2
4.3 Rôles dans un programme de continuité d’activité . 2
4.3.1 Rôles et responsabilités dans un programme de continuité d’activité . 2
4.3.2 Rôles et compétences propres au processus d’AIA. 2
4.4 Engagement de la direction en faveur du programme de continuité d’activité . 4
4.5 Ressources du programme de continuité d’activité . 4
5 Exécution de l’analyse d’impact sur l’activité . 4
5.1 Généralités . 4
5.2 Planification et gestion de projet . 6
5.2.1 Généralités . 6
5.2.2 Aspects à prendre en compte pour une première AIA . 6
5.3 Hiérarchisation des produits et services . 7
5.3.1 Vue d’ensemble . 7
5.3.2 Données d’entrée . 9
5.3.3 Résultats . 9
5.4 Hiérarchisation des processus .10
5.4.1 Généralités .10
5.4.2 Données d’entrée .10
5.4.3 Résultats .10
5.5 Hiérarchisation des activités .10
5.5.1 Vue d’ensemble .10
5.5.2 Données d’entrée .11
5.5.3 Collecte des informations .11
5.5.4 Résultats .12
5.6 Analyse et consolidation .13
5.6.1 Vue d’ensemble .13
5.6.2 Données d’entrée .13
5.6.3 Méthodes .13
5.6.4 Résultats .13
5.7 Approbation des résultats de l’AIA par la direction .14
5.7.1 Généralités .14
5.7.2 Données d’entrée .14
5.7.3 Méthodes .14
5.7.4 Résultats .15
5.8 À l’issue de l’AIA – Détermination de la stratégie de continuité d’activité .15
6 Supervision et révision du processus d’AIA .15
Annexe A (informative) Analyse d’impact sur l’activité dans le cadre d’un système de
management de la continuité d’activité ISO 22301 .17
Annexe B (informative) Tableau de correspondance de la terminologie relative à l’analyse
d’impact sur l’activité .18
Annexe C (informative) Méthodes de collecte des informations relatives à l’analyse
d’impact sur l’activité .19
Annexe D (informative) Autres utilisations du processus d’analyse d’impact sur l’activité .25
Bibliographie .29
iv © ISO 2015 – Tous droits réservés
Avant-propos
L’ISO (Organisation internationale de normalisation) est une fédération mondiale d’organismes
nationaux de normalisation (comités membres de l’ISO). L’élaboration des Normes internationales est
en général confiée aux comités techniques de l’ISO. Chaque comité membre intéressé par une étude
a le droit de faire partie du comité technique créé à cet effet. Les organisations internationales,
gouvernementales et non gouvernementales, en liaison avec l’ISO participent également aux travaux.
L’ISO collabore étroitement avec la Commission électrotechnique internationale (IEC) en ce qui
concerne la normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient, en particulier de prendre note des différents
critères d’approbation requis pour les différents types de documents ISO. Le présent document a été
rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2 (voir www.
iso.org/directives).
L’attention est appelée sur le fait que certains des éléments du présent document peuvent faire l’objet de
droits de propriété intellectuelle ou de droits analogues. L’ISO ne saurait être tenue pour responsable
de ne pas avoir identifié de tels droits de propriété et averti de leur existence. Les détails concernant
les références aux droits de propriété intellectuelle ou autres droits analogues identifiés lors de
l’élaboration du document sont indiqués dans l’Introduction et/ou dans la liste des déclarations de
brevets reçues par l’ISO (voir www.iso.org/brevets).
Les appellations commerciales éventuellement mentionnées dans le présent document sont données
pour information, par souci de commodité, à l’intention des utilisateurs et ne sauraient constituer un
engagement.
Pour une explication de la signification des termes et expressions spécifiques de l’ISO liés à l’évaluation
de la conformité, ou pour toute information au sujet de l’adhésion de l’ISO aux principes de l’Organisation
mondiale du commerce (OMC) concernant les obstacles techniques au commerce (OTC), voir le lien
suivant: www.iso.org/iso/fr/avant-propos.html
Le comité chargé de l’élaboration du présent document est l’ISO/TC 292, Sécurité et résilience.
Introduction
La présente Spécification technique fournit des préconisations détaillées pour la création, la mise en
1)
œuvre et la tenue à jour d’un processus d’analyse d’impact sur l’activité (AIA) conforme aux exigences
de l’ISO 22301. La présente Spécification technique est applicable à l’exécution de tout processus d’AIA,
qu’il fasse partie d’un système de management de la continuité d’activité (SMCA) ou d’un programme
de continuité d’activité. Ci-après, le terme «programme de continuité d’activité» signifie soit SMCA, soit
programme de continuité d’activité.
La Figure 1 souligne la relation entre le processus d’AIA et le programme de continuité d’activité dans
son ensemble. Il convient que l’organisation suive un cycle complet du processus d’AIA avant de choisir
les stratégies de continuité d’activité.
Figure 1 — Éléments de management de la continuité d’activité
(Source: ISO 22313)
Le processus d’AIA analyse les conséquences d’un incident perturbateur sur l’organisation. Le résultat
est un inventaire des exigences relatives à la continuité d’activité et leur justification.
Le processus d’AIA se compose de plusieurs AIA élémentaires, dont chacune est consacrée à un sous-
ensemble différent du domaine d’application du programme de continuité d’activité. Le processus
d’AIA hiérarchise les produits et les services puis les processus et les activités qui, ensemble, couvrent
la totalité du domaine d’application du programme de continuité d’activité. Au terme d’une période
déterminée par l’organisation, on révise les différentes AIA afin de s’assurer que les exigences relatives
à la continuité d’activité demeurent à jour.
NOTE Dans la présente Spécification technique, l’expression «exigences relatives à la continuité d’activité» a
la même signification que priorités, objectifs et cibles de continuité d’activité et de reprise (ISO 22301:2012, 8.2.2).
Les objectifs de la présente Spécification technique sont les suivants:
— fournir une base pour la compréhension, l’élaboration, la mise en œuvre, la révision, la tenue à jour
et l’amélioration continue d’un processus d’AIA efficace au sein d’une organisation;
1) Analyse d’impact sur l’activité est la traduction française du terme BIA (Business Impact Analysis), communément
employé en français.
vi © ISO 2015 – Tous droits réservés
— fournir des préconisations pour la planification et la réalisation d’une AIA ainsi que pour la rédaction
des comptes rendus qui en résultent;
— aider l’organisation à réaliser une AIA selon une approche cohérente reflétant les bonnes pratiques;
— permettre une bonne coordination entre le processus d’AIA et le programme de continuité
d’activité global.
Les résultats du processus d’AIA comprennent les éléments suivants:
— approbation ou modification du domaine d’application du programme de continuité d’activité de
l’organisation;
— identification des obligations légales, réglementaires et contractuelles et de leur incidence sur les
exigences relatives à la continuité d’activité;
— évaluation des impacts sur l’organisation dans le temps, qui sert de justification aux exigences
relatives à la continuité d’activité (temps et capacité);
— identification et confirmation des exigences en matière de fourniture de produits/prestation de
services à la suite d’un incident perturbateur, qui définit alors un cadre chronologique pour les
activités et les ressources;
— identification et établissement des relations entre les produits/services, les processus, les activités
et les ressources;
— identification des ressources nécessaires à l’exécution des activités prioritaires (par exemple:
installations, personnes, équipements, ressources liées aux technologies de l’information et des
communications, fournitures et financement);
— analyse des dépendances vis-à-vis des autres activités, chaînes d’approvisionnement, partenaires et
autres parties intéressées;
— détermination des contraintes pour l’actualisation des informations.
NOTE Aux fins de la présente Spécification technique, les chaînes d’approvisionnement produisent des
fournitures de biens, de travaux et de services, qui sont désignées par le terme «fournitures» dans le reste du
présent document.
Le schéma ci-dessous représente le processus d’AIA, ainsi que les conditions préalables et la relation
de ce processus avec l’identification des stratégies. Le schéma fait référence à des paragraphes de la
présente Spécification technique.
Figure 2 — Processus d’analyse d’impact sur l’activité
viii © ISO 2015 – Tous droits réservés
SPÉCIFICATION TECHNIQUE ISO/TS 22317:2015(F)
Sécurité sociétale — Systèmes de management de la
continuité d’activité — Lignes directrices pour l’analyse
d’impact sur l’activité
1 Domaine d’application
La présente Spécification technique fournit des préconisations visant à permettre à une organisation
de créer, mettre en œuvre et tenir à jour un processus formel et documenté d’analyse d’impact sur
l’activité (AIA). La présente Spécification technique n’impose pas de processus unique pour l’exécution
d’une AIA. Toutefois, elle peut servir de support à une organisation pour la conception d’un processus
d’AIA conforme à ses besoins.
La présente Spécification technique est applicable à toutes les organisations, quels que soient leur type,
leur taille et leur nature, qu’ils appartiennent au secteur privé ou au secteur public et qu’ils soient à
but lucratif ou non. Les préconisations qu’elle fournit peuvent être adaptées en fonction des besoins,
objectifs, ressources et contraintes de l’organisation.
La présente Spécification technique est destinée aux personnes responsables du processus d’AIA.
2 Références normatives
Les documents ci-après, dans leur intégralité ou non, sont des références normatives indispensables à
l’application du présent document. Pour les références datées, seule l’édition citée s’applique. Pour les
références non datées, la dernière édition du document de référence s’applique (y compris les éventuels
amendements).
ISO 22300, Sécurité sociétale — Terminologie
3 Termes et définitions
Pour les besoins du présent du document, les termes et définitions de l’ISO 22300 s’appliquent.
NOTE Tous les termes et toutes les définitions qui figurent dans l’ISO 22300 sont disponibles sur la
plateforme ISO, à l’adresse www.iso.org/obp.
4 Conditions préalables
4.1 Généralités
Comme l’indique l’introduction, la présente Spécification technique est conforme à l’ISO 22301, mais
elle pourrait être utilisée pour élaborer, mettre en œuvre, réviser, tenir à jour et améliorer de façon
continue un processus d’AIA répondant à d’autres normes ou exigences réglementaires. Il convient
que l’organisation prenne en compte un certain nombre de conditions préalables avant de démarrer
le processus d’AIA, que ce dernier fasse partie d’un SMCA ou d’un programme de continuité d’activité.
L’Article 4 récapitule ces conditions préalables, dont beaucoup sont issues de l’ISO 22301.
Avant de démarrer le processus d’AIA, il convient que l’organisation accomplisse un certain nombre
d’étapes au sein du programme de continuité d’activité, comprenant les éléments suivants:
— définir le contexte et le domaine d’application (4.2);
— définir et communiquer les rôles et les responsabilités (4.3);
— obtenir un engagement de la direction (4.4);
— affecter les ressources adéquates (4.5).
NOTE Pour plus d’informations, voir l’Annexe A, qui propose un tableau de correspondance entre les
différentes étapes et celles de l’ISO 22301.
4.2 Contexte et domaine d’application du programme de continuité d’activité
4.2.1 Contexte du programme de continuité d’activité
La réussite du processus d’AIA dépend de la compréhension, par l’organisation, des aspects suivants:
— l’environnement externe dans lequel elle opère, afin qu’elle puisse remplir sa mission en fournissant
ses produits et services à ses clients,
— l’environnement opérationnel interne, y compris les processus, activités et ressources, ainsi que
l’impact potentiel d’une perturbation de la fourniture de produits et de la prestation de services et
— les lois et réglementations prescrivant le processus d’AIA et la manière dont il est exécuté.
NOTE Dans les organisations opérant dans un environnement non commercial, le «client» peut être le public
ou une autorité de tutelle telle que l’administration.
4.2.2 Domaine d’application du programme de continuité d’activité
Avant de déterminer le domaine d’application du processus d’AIA, il convient que l’organisation
définisse et documente le domaine d’application du programme de continuité d’activité en termes de
produits et de services.
Le processus d’AIA peut aider l’organisation à réviser le domaine d’application du programme de
continuité d’activité.
Après la définition du domaine d’application du programme de continuité d’activité, l’organisation peut
déterminer le domaine d’application du processus d’AIA, qui peut être exécuté sous la forme d’une AIA
unique couvrant la totalité du domaine d’application du programme de continuité d’activité, ou être
effectué en plusieurs phases qui, dans le temps, couvriront l’intégralité du domaine d’application du
programme de continuité d’activité.
NOTE Si l’organisation choisit d’effectuer le processus d’AIA en plusieurs phases, il convient de déterminer
dans un premier temps la priorité associée à tous les produits et services (voir 5.2), puis qu’il poursuive avec les
différentes AIA restantes.
4.3 Rôles dans un programme de continuité d’activité
4.3.1 Rôles et responsabilités dans un programme de continuité d’activité
Avant d’exécuter le processus d’AIA, il convient que la direction s’assure que les rôles, responsabilités
et compétences concernés sont attribués et font l’objet d’une communication au sein de l’organisation.
4.3.2 Rôles et compétences propres au processus d’AIA
Après l’attribution des rôles dans le cadre du programme de continuité d’activité, il convient que la
direction fournisse les ressources nécessaires à l’exécution du processus d’AIA, ce qui peut comprendre
l’attribution des rôles suivants:
— donneur d’ordre du processus d’AIA;
— comité de pilotage de l’AIA;
2 © ISO 2015 – Tous droits réservés
— personne conduisant le processus d’AIA;
— personne gérant le projet d’AIA (chef de projet);
— propriétaires des processus;
— responsables d’activité.
Il convient que le donneur d’ordre du processus d’AIA
— soit un cadre représentant la direction,
— soit respecté par les autres membres de la direction de l’organisation,
— adopte une perspective couvrant l’ensemble de l’organisation,
— soit habilité à engager l’organisation, et
— prenne les décisions finales concernant le processus d’AIA.
Il convient que le comité de pilotage de l’AIA
— représente la direction,
— fournisse en continu des conseils et des orientations concernant l’exécution du processus d’AIA,
— convienne des méthodes et des résultats,
— prenne les décisions concernant les exigences relatives à la continuité d’activité, et
— aide la personne conduisant le processus d’AIA et le chef de projet à déterminer les compétences
requises pour les rôles et responsabilités propres au processus d’AIA, ainsi que la sensibilisation, les
connaissances, la compréhension, le savoir-faire et l’expérience nécessaires pour les assurer.
Il convient que la personne conduisant le processus d’AIA
— ait une bonne compréhension de l’organisation, particulièrement de ses produits, services, processus
et activités, et
— possède de l’expérience en matière d’exécution de processus d’AIA.
Il convient que la personne gérant le projet d’AIA
— planifie et gère le processus d’AIA,
— ait une bonne compréhension des tâches de planification de projet, et
— connaisse bien le processus d’AIA.
Il convient que les propriétaires des processus aient une compréhension suffisamment détaillée de
leur processus pour aider le chef de projet à identifier les experts en la matière, les unités constituant
l’organisation et les impacts des arrêts d’activité.
Il convient que les responsables d’activité
— aient une compréhension très approfondie de leur activité et des ressources qui lui sont nécessaires, et
— aient connaissance des processus et ressources alternatifs aux ressources existantes.
NOTE Dans les petites organisations, ces rôles peuvent être combinés.
Il convient que l’organisation s’assure de la compétence des personnes conduisant le processus d’AIA ou
y prenant part. Il convient que les compétences comprennent des savoir-faire et des aptitudes liés aux
aspects suivants:
— planification et gestion de projet/programme;
— collecte des informations;
— analyse;
— communication et collaboration efficaces;
— déclinaison des objectifs organisationnels en exigences relatives à la continuité d’activité, d’une
part, et en besoins en ressources, d’autre part;
— mise en application des concepts de l’AIA dans le contexte propre à l’organisation;
— connaissance de l’organisation et de ses produits et services, processus, activités et ressources.
4.4 Engagement de la direction en faveur du programme de continuité d’activité
L’engagement de la direction en faveur du processus d’AIA est nécessaire pour garantir une participation
efficace. Pour obtenir ce soutien, l’organisation peut envisager de communiquer sur la dimension
stratégique du processus d’AIA, qui vise notamment à:
— s’assurer que les stratégies retenues sont adéquates et sont les plus économiques possible en
identifiant les exigences appropriées relatives à la continuité d’activité;
— fournir à la direction la preuve que les exigences relatives à la continuité d’activité sont compatibles
avec les objectifs organisationnels;
— s’assurer que l’organisation respecte ses obligations légales et contractuelles et les exigences des
clients lors d’un incident perturbateur;
— identifier les liens entre les produits et services, les processus, les activités et les ressources;
— fournir une vue d’ensemble de l’organisation qui puisse servir à en améliorer l’efficacité ou à étudier
de nouvelles opportunités (voir Annexe D).
4.5 Ressources du programme de continuité d’activité
Il convient que l’organisation mette à disposition des ressources suffisantes pour la réalisation du
processus d’AIA, pour
— mettre en œuvre sa politique de continuité d’activité et atteindre ses objectifs de continuité;
— prendre les dispositions adéquates pour le personnel et les besoins associés, y compris le temps
nécessaire à l’exercice des rôles et responsabilités propres au processus d’AIA, ainsi qu’à la
sensibilisation et à la formation;
— prendre en compte l’évolution des exigences de l’organisation;
— permettre le fonctionnement et l’amélioration continus du programme de continuité d’activité, ainsi
que du processus d’AIA.
5 Exécution de l’analyse d’impact sur l’activité
5.1 Généralités
Le processus d’AIA attribue un niveau de priorité aux différentes composantes organisationnelles,
de sorte que, suite à un incident perturbateur, la fourniture de produits et la prestation de services
4 © ISO 2015 – Tous droits réservés
puissent reprendre dans un délai prédéterminé, de façon satisfaisante pour les parties intéressées.
Aux fins de la présente Spécification technique et conformément à l’ISO 22301, les produits et services
résultent de processus qui sont composés d’activités.
Les produits et services sont hiérarchisés en premier; cela permet d’établir les critères de temps et
de niveau de service pour la hiérarchisation des processus. Si la complexité de l’organisation l’exige, il
est ensuite possible de décomposer les processus afin d’attribuer un niveau de priorité aux différentes
activités qui les constituent.
L’obtention de résultats adéquats, cohérents et utiles pour les phases ultérieures du programme de
continuité d’activité dépend de la précision du processus d’AIA. Il convient que chaque AIA soit effectuée
de la même manière et de façon rigoureuse et exhaustive.
La Figure 3 présente l’articulation entre les différents éléments du processus d’AIA. Le schéma indique
que les phases qui constituent le processus peuvent se superposer dans le temps.
Figure 3 — Relations entre les composantes de l’analyse d’impact sur l’activité
La réussite du processus d’AIA peut dépendre des éléments suivants:
— identification des clients et des autres parties intéressées, et anticipation de leurs réactions face à
un incident perturbateur;
— implication de toutes les parties intéressées concernées dans le cadre d’un mandat approprié;
— développement des savoir-faire et des compétences appropriés au sein de l’organisation ou du projet
afin de réaliser l’analyse et d’en présenter les résultats;
— collecte d’informations globalement complètes et exactes (certaines informations peuvent être
indisponibles, mal comprises, confidentielles ou protégées, ce qui conduit à l’identification de
domaines nécessitant des travaux supplémentaires);
— vérification du fait que les personnes contribuant au processus de collecte d’informations de l’AIA
possèdent les connaissances et les habilitations suffisantes pour s’exprimer au nom de l’organisation,
du processus ou de l’activité;
— vérification de la légitimité des représentants de la direction pour approuver les résultats de l’AIA.
5.2 Planification et gestion de projet
5.2.1 Généralités
Bien que l’AIA soit un processus, les organisations peuvent utiliser des méthodes de gestion de projet
pour une phase donnée du processus d’AIA. Le processus d’AIA étant potentiellement complexe,
l’utilisation de méthodes de gestion de projet permet aux organisations de coordonner les calendriers
et les ressources nécessaires.
Les tâches de planification de projet peuvent comprendre les éléments suivants:
— détermination du domaine d’application de cette phase du processus d’AIA;
— communication des attentes aux personnes participant au processus d’AIA;
— identification du donneur d’ordre du processus d’AIA et des représentants de la direction;
— définition des rôles et responsabilités propres au processus d’AIA (y compris les compétences);
— création du plan de projet;
— affectation des ressources pour le projet d’AIA;
— obtention de l’acceptation de l’approche et du plan du projet;
— développement en interne de l’expertise nécessaire à la réalisation des objectifs du processus d’AIA
ou recours à une expertise externe.
Les tâches de gestion de projet peuvent comprendre les éléments suivants:
— mise en œuvre du processus d’AIA (voir paragraphes 5.2 à 5.6);
— supervision de la mise en œuvre du processus d’AIA (voir paragraphe 5.6);
— élaboration de rapports périodiques sur l’état d’avancement, soulignant les attentes en matière de
performances et les recommandations en matière d’amélioration des performances conformément
aux attentes de la direction (voir 5.2);
— ajustement de la méthode et du domaine d’application du processus d’AIA afin de répondre aux
attentes de la direction ainsi qu’aux contraintes extérieures (obligations réglementaires, légales et
contractuelles, exigences des clients) (voir Article 6);
— exploitation des retours d’expérience (voir Article 6);
— formulation de recommandations relatives à l’amélioration du processus d’AIA en vue de sa
prochaine mise en œuvre (voir Article 6).
5.2.2 Aspects à prendre en compte pour une première AIA
Il convient qu’une organisation effectuant une AIA pour la première fois prévoie du temps
supplémentaire pour
— identifier les produits et services,
— sensibiliser et assurer la formation,
— désigner un représentant de la direction en tant que donneur d’ordre du processus d’AIA et/ou
établir un comité de pilotage de l’AIA,
— déterminer les catégories d’impacts ainsi que les critères,
— déterminer l’importance de l’environnement métier/politique de l’organisation,
6 © ISO 2015 – Tous droits réservés
— décrire la structure de l’organisation avec un niveau de détail approprié,
— identifier et choisir les bonnes sources d’informations pour la collecte d’informations,
— documenter le flux de travail au niveau des processus et des activités, et
— procéder à la collecte des informations au travers d’une revue documentaire, d’entretiens, d’ateliers
et de questionnaires.
Lors de la première AIA, l’organisation peut utiliser les résultats de l’AIA pour hiérarchiser les phases
de continuité d’activité ultérieures, en particulier lors du choix de la stratégie.
5.3 Hiérarchisation des produits et services
5.3.1 Vue d’ensemble
Au démarrage du processus d’AIA, il est recommandé à la direction d’attribuer un niveau de priorité
à chaque produit et service dont la fourniture pourrait être compromise à la suite d’un incident
perturbateur.
Cette décision relève de la responsabilité de la direction pour les raisons suivantes:
— elle définit les objectifs de l’organisation,
— c’est à elle que revient la responsabilité finale de s’assurer de la continuité de l’organisation et de la
réalisation de ses objectifs,
— elle jouit, pour l’évaluation des priorités, du point de vue le plus complet de l’ensemble de
l’organisation,
— elle peut choisir d’ignorer des obligations contractuelles et autres au moment de définir les priorités
dans des cas exceptionnels, et
— elle a connaissance des changements futurs prévus et des autres facteurs qui peuvent avoir une
incidence sur les exigences relatives à la continuité d’activité.
Si le nombre de produits et de services à distinguer est trop important, l’organisation peut regrouper les
produits et services de même niveau de priorité. Il peut être nécessaire pour l’organisation de distinguer
les clients qui ont des exigences différentes en termes de délais de fourniture ou de prestation, pour
des produits et services identiques. Les clients peuvent également être classés en fonction de leur
importance pour l’organisation.
Pour chaque groupe de produits et de services, il convient que l’organisation évalue les impacts pouvant
découler d’un incident perturbateur,
— en identifiant les attentes et obligations des clients ainsi que les pénalités encourues si elles ne sont
pas satisfaites et
— en tenant compte de l’opinion des autres parties intéressées lors de l’évaluation des impacts.
Les réactions des parties intéressées face à un incident perturbateur peuvent être:
— organisations partenaires: volonté de poursuivre la coopération;
— médias et société: variation de l’image de marque et de l’opinion publique;
— clients potentiels: perte de parts de marchés actuelles et futures;
— actionnaires: effets sur le cours actuel de l’action et sur les investissements futurs;
— concurrents: actions opportunistes;
— personnel: démissions;
— pouvoirs publics: sanctions et réformes du cadre juridique.
L’organisation peut utiliser les exemples du Tableau 1 pour comprendre les impacts d’un incident
perturbateur sur une organisation dans le temps:
Tableau 1 — Exemples de catégories d’impacts au niveau des produits et services
Catégories d’impacts Exemples d’impacts
Impact financier Pertes financières dues à des amendes, des pénalités, des pertes de bénéfices ou une
perte de parts de marché
Impact sur la réputation Opinion négative ou atteinte à l’image de marque
Impact légal et régle- Contentieux et retrait de licence d’exploitation
mentaire
Impact contractuel Rupture de contrats ou d’obligations liant des organisations
Impact sur les objectifs Incapacité à atteindre les objectifs ou à tirer parti des opportunités
métier
Les niveaux d’impact augmentent presque toujours dans le temps. Toutefois, les différents impacts
peuvent ne pas tous augmenter au même rythme. Par exemple, les impacts financiers peuvent
augmenter brusquement avec l’application de pénalités ou la perte de clients, et l’atteinte à la réputation
peut survenir soudainement au cours de l’incident perturbateur. Voir la Figure 4, qui fournit un exemple
de la manière dont les différentes catégories d’impacts augmentent dans le temps.
Figure 4 — Impact d’un incident perturbateur sur une organisation dans le temps
Pour chaque groupe de produits et de services, il convient que la direction décide des aspects suivants
et les documente:
— délai au bout duquel l’incapacité continue à fournir les produits et services concernés devient
inacceptable pour l’organisation du fait que les impacts indiqués plus haut menacent sa survie ou
rendent ses objectifs inatteignables (voir l’Annexe B pour les termes associés);
8 © ISO 2015 – Tous droits réservés
— raison(s) pour laquelle(lesquelles) cette période a été identifiée par rapport aux impacts croissants
dans le temps.
L’organisation peut, sur la base de l’exemple de délai de la Figure 4, définir une date cible de reprise
de la fourniture des produits et de la prestation des services aux niveaux minimums spécifiés (voir
l’Annexe B pour les termes associés).
5.3.2 Données d’entrée
La direction peut tenir compte des informations suivantes au moment de déterminer les exigences
relatives à la continuité d’activité applicables aux produits et services:
— mission, objectifs et orientation stratégique actuels de l’organisation;
— domaine d’application du programme de continuité d’activité en cours;
— évaluation des priorités attribuées aux produits et services sur la base d’une revue de direction
antérieure;
— liste des obligations légales et réglementaires auxquelles l’organisation ou des produits et services
spécifiques sont assujettis (ainsi qu’une évaluation des conséquences du non-respect de chaque
exigence);
— exigences contractuelles, y compris les pénalités en cas de non-fourniture ou de non-prestation;
— évaluation des impacts financiers, sur l’image de marque ou autres en cas de non-fourniture ou de
non-prestation;
— rapports post-incident décrivant l’impact associé aux incidents perturbateurs récents.
5.3.3 Résultats
Il convient que le processus de hiérarchisation des produits et services produise les résultats suivants:
— approbation ou modification du domaine d’application du programme de continuité d’activité de
l’organisation,
— identification des obligations légales, réglementaires et contractuelles,
— évaluation des impacts dans le temps relatifs à une incapacité à fournir les produits ou services, qui
sert de justification aux exigences relatives à la continuité d’activité,
— confirmation des exigences en matière de fourniture de produits et de prestation de services
(qui peuvent comprendre les délais, la qualité, la quantité, les niveaux de service et les capacités
de fourniture) à la suite d’un incident perturbateur qui définit ensuite les priorités associées aux
activités et aux ressources,
— identification des processus (qui fournissent les produits et services),
— nomination des personnes compétentes chargées d’aider à identifier les processus qui fournissent
les produits et services et
— documentation d’une liste de produits et services prioritaires (regroupés par délai ou par client).
L’organisation peut conserver la documentation décrivant les décisions prises durant le processus de
hiérarchisation des produits et services.
5.4 Hiérarchisation des processus
5.4.1 Généralités
Un processus est un ensemble d’activités corrélées ou interactives qui transforment des éléments
d’entrée en éléments de sortie (ISO 22300). Son niveau de priorité dépend de celui des produits et
services qui en sont issus.
En fonction de sa complexité, l’organisation peut ne pas donner de priorité aux processus et passer
directement à la hiérarchisation des activités. Si l’organisation choisit de procéder à une hiérarchisation
des processus, il convient qu’il identifie les activités qui composent ces processus.
5.4.2 Données d’entrée
Les informations nécessaires à la hiérarchisation des processus comprennent les éléments suivants:
— le domaine d’application de cette AIA;
— les exigences en matière de fourniture de produits et de prestation de services (qui peuvent
comprendre les délais, la qualité, la quantité, les niveaux de service et les capacités de fourniture);
— les processus ainsi que les produits et services associés;
— les impacts dans le temps d’une incapacité à fournir les produits et services concernés;
— les obligations légales, réglementaires et contractuelles.
5.4.3 Résultats
Il convient que la hiérarchisation des processus produise les résultats suivants:
— identification de la relation entre les produits et services, les processus et les activités;
— identification des dépendances vis-à-vis des autres processus métier;
— évaluation des impacts dans le temps d’une défaillance des processus (les catégories d’impacts
du Tableau 1 pourraient être utilisées pour confirmer les impacts d’une perturbation des processus);
— priorités attribuées aux processus;
— analyse des interdépendances des processus qui fournissent des produits et services aux clients;
— analyse des interdépendances des activités qui constituent les processus;
— liste documentée des processus prioritaires qui fournissent des produits et services et
— liste documentée initiale des activités qui constituent les processus.
5.5 Hiérarchisation des activités
5.5.1 Vue d’ensemble
Une activité est constituée d’une ou plusieurs tâches ayant une finalité définie. La priorité attribuée à
l’activité dépend de la priorité donnée aux processus dont elle fait partie.
Il convient que l’organisation procède à une hiérarchisation des activités afin d’identifier les ressources
nécessaires à l’exécution de chaque activité à la suite d’un incident perturbateur, et de confirmer
l’impact potentiel de cet incident perturbateur.
Il convient que les organisations procèdent à une hiérarchisation des activités pour une compréhension
approfondie des besoins quotidiens en matière de ressources, leur permettant d’identifier la quantité
10 © ISO 2015 – Tous droits réservés
dans le temps des ressources nécessaires au rétablissement. Cette hiérarchisation permet de confirmer
les conclusions établies quant aux impacts identifiés au niveau des processus. Les informations liées
aux ressources comprennent les éléments suivants:
— personnes/savoir-faire/rôles;
— installations;
— équipement;
— enregistrements;
— financement;
— technologies de l’information et des communications (y compris les applications, les données, la
téléphonie et les réseaux);
— fournitures, chaînes d’approvisionnement et partenaires;
— dépendances vis-à-vis d’autres processus et activités;
— outils spéciaux, pièces détachées et consommables;
— limitation des ressources pour des raisons de logistique ou du fait de contraintes réglementaires.
Outre les impacts déjà pris en compte dans le Tableau 1, l’organisation peut envisager d’évaluer l’impact
opérationnel, tel que les retards dus aux
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...