ISO/IEC 27005:2018

SLOVENSKI STANDARD
01-januar-2019
1DGRPHãþD
SIST ISO/IEC 27005:2011
Informacijska tehnologija - Varnostne tehnike - Obvladovanje informacijskih
varnostnih tveganj
Information technology -- Security techniques -- Information security risk management
Technologies de l'information -- Techniques de sécurité -- Gestion des risques liés à la
sécurité de l'information
Ta slovenski standard je istoveten z: ISO/IEC 27005:2018
ICS:
03.100.70 Sistemi vodenja Management systems
35.030 Informacijska varnost IT Security
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

INTERNATIONAL ISO/IEC
STANDARD 27005
Third edition
2018-07
Information technology — Security
techniques — Information security
risk management
Technologies de l'information — Techniques de sécurité — Gestion
des risques liés à la sécurité de l'information
Reference number
©
ISO/IEC 2018
© ISO/IEC 2018
All rights reserved. Unless otherwise specified, or required in the context of its implementation, 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
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2018 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Structure of this document . 1
5 Background . 2
6 Overview of the information security risk management process .3
7 Context establishment . 5
7.1 General considerations . 5
7.2 Basic criteria . 6
7.2.1 Risk management approach . 6
7.2.2 Risk evaluation criteria . 6
7.2.3 Impact criteria . 6
7.2.4 Risk acceptance criteria . 7
7.3 Scope and boundaries . 7
7.4 Organization for information security risk management . 8
8 Information security risk assessment . 8
8.1 General description of information security risk assessment . 8
8.2 Risk identification . 9
8.2.1 Introduction to risk identification . 9
8.2.2 Identification of assets . 9
8.2.3 Identification of threats .10
8.2.4 Identification of existing controls .10
8.2.5 Identification of vulnerabilities.11
8.2.6 Identification of consequences .12
8.3 Risk analysis .12
8.3.1 Risk analysis methodologies.12
8.3.2 Assessment of consequences .13
8.3.3 Assessment of incident likelihood .14
8.3.4 Level of risk determination .15
8.4 Risk evaluation .15
9 Information security risk treatment .16
9.1 General description of risk treatment .16
9.2 Risk modification .18
9.3 Risk retention .19
9.4 Risk avoidance .19
9.5 Risk sharing .19
10 Information security risk acceptance .20
11 Information security risk communication and consultation .20
12 Information security risk monitoring and review .21
12.1 Monitoring and review of risk factors .21
12.2 Risk management monitoring, review and improvement .22
Annex A (informative) Defining the scope and boundaries of the information security risk
management process .24
Annex B (informative) Identification and valuation of assets and impact assessment .28
Annex C (informative) Examples of typical threats .37
© ISO/IEC 2018 – All rights reserved iii

Annex D (informative) Vulnerabilities and methods for vulnerability assessment.41
Annex E (informative) Information security risk assessment approaches .45
Annex F (informative) Constraints for risk modification .51
Bibliography .53
iv © ISO/IEC 2018 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
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 document 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 and IEC 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 voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see the following
URL: www .iso .org/iso/foreword .html.
This document was prepared by Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, IT Security techniques.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/members .html.
This third edition cancels and replaces the second edition (ISO/IEC 27005:2011) which has been
technically revised. The main changes from the previous edition are as follows:
— all direct references to the ISO/IEC 27001:2005 have been removed;
— clear information has been added that this document does not contain direct guidance on the
implementation of the ISMS requirements specified in ISO/IEC 27001 (see Introduction);
— ISO/IEC 27001:2005 has been removed from Clause 2;
— ISO/IEC 27001 has been added to the Bibliography;
— Annex G and all references to it have been removed;
— editorial changes have been made accordingly.
© ISO/IEC 2018 – All rights reserved v

Introduction
This document provides guidelines for information security risk management in an organization.
However, this document does not provide any specific method for information security risk management.
It is up to the organization to define their approach to risk management, depending for example on
the scope of an information security management system (ISMS), context of risk management, or
industry sector. A number of existing methodologies can be used under the framework described in
this document to implement the requirements of an ISMS. This document is based on the asset, threat
and vulnerability risk identification method that is no longer required by ISO/IEC 27001. There are
some other approaches that can be used.
This document does not contain direct guidance on the implementation of the ISMS requirements given
in ISO/IEC 27001.
This document is relevant to managers and staff concerned with information security risk management
within an organization and, where appropriate, external parties supporting such activities.
vi © ISO/IEC 2018 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 27005:2018(E)
Information technology — Security techniques —
Information security risk management
1 Scope
This document provides guidelines for information security risk management.
This document supports the general concepts specified in ISO/IEC 27001 and is designed to assist the
satisfactory implementation of information security based on a risk management approach.
Knowledge of the concepts, models, processes and terminologies described in ISO/IEC 27001 and ISO/
IEC 27002 is important for a complete understanding of this document.
This document is applicable to all types of organizations (e.g. commercial enterprises, government
agencies, non-profit organizations) which intend to manage risks that can compromise the organization’s
information security.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 27000, Information technology — Security techniques — Information security management
systems — Overview and vocabulary
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 27000 and the
following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https: //www .iso .org/obp
— IEC Electropedia: available at http: //www .electropedia .org/
4 Structure of this document
This document contains the description of the information security risk management process and its
activities.
The background information is provided in Clause 5.
A general overview of the information security risk management process is given in Clause 6.
All information security risk management activities as presented in Clause 6 are subsequently
described in the following clauses:
— context establishment in Clause 7;
— risk assessment in Clause 8;
— risk treatment in Clause 9;
© ISO/IEC 2018 – All rights reserved 1

— risk acceptance in Clause 10;
— risk communication in Clause 11;
— risk monitoring and review in Clause 12.
Additional information for information security risk management activities is presented in the
annexes. The context establishment is supported by Annex A (Defining the scope and boundaries of
the information security risk management process). Identification and valuation of assets and impact
assessments are discussed in Annex B. Annex C gives examples of typical threats and Annex D discusses
vulnerabilities and methods for vulnerability assessment. Examples of information security risk
assessment approaches are presented in Annex E.
Constraints for risk modification are presented in Annex F.
All risk management activities as presented from Clause 7 to Clause 12 are structured as follows:
Input: Identifies any required information to perform the activity.
Action: Describes the activity.
Implementation guidance: Provides guidance on performing the action. Some of this guidance may not
be suitable in all cases and so other ways of performing the action may be more appropriate.
Output: Identifies any information derived after performing the activity.
5 Background
A systematic approach to information security risk management is necessary to identify organizational
needs regarding information security requirements and to create an effective information security
management system (ISMS). This approach should be suitable for the organization’s environment
and, in particular, should be aligned with overall enterprise risk management. Security efforts should
address risks in an effective and timely manner where and when they are needed. Information security
risk management should be an integral part of all information security management activities and
should be applied both to the implementation and the ongoing operation of an ISMS.
Information security risk management should be a continual process. The process should establish
the external and internal context, assess the risks and treat the risks using a risk treatment plan to
implement the recommendations and decisions. Risk management analyses what can happen and what
the possible consequences can be, before deciding what should be done and when, to reduce the risk to
an acceptable level.
Information security risk management should contribute to the following:
— risks being identified;
— risks being assessed in terms of their consequences to the business and the likelihood of their
occurrence;
— the likelihood and consequences of these risks being communicated and understood;
— priority order for risk treatment being established;
— priority for actions to reduce risks occurring;
— stakeholders being involved when risk management decisions are made and kept informed of the
risk management status;
— effectiveness of risk treatment monitoring;
— risks and the risk management process being monitored and reviewed regularly;
2 © ISO/IEC 2018 – All rights reserved

— information being captured to improve the risk management approach;
— managers and staff being educated about the risks and the actions taken to mitigate them.
The information security risk management process can be applied to the organization as a whole, any
discrete part of the organization (e.g. a department, a physical location, a service), any information
system, existing or planned or particular aspects of control (e.g. business continuity planning).
6 Overview of the information security risk management process
A high level view of the risk management process is specified in ISO 31000 and shown in Figure 1.
Figure 1 — The risk management process
Figure 2 shows how this document applies this risk management process.
The information security risk management process consists of context establishment (Clause 7), risk
assessment (Clause 8), risk treatment (Clause 9), risk acceptance (Clause 10), risk communication and
consultation (Clause 11), and risk monitoring and review (Clause 12).
© ISO/IEC 2018 – All rights reserved 3

Figure 2 — Illustration of an information security risk management process
As Figure 2 illustrates, the information security risk management process can be iterative for risk
assessment and/or risk treatment activities. An iterative approach to conducting risk assessment can
increase depth and detail of the assessment at each iteration. The iterative approach provides a good
balance between minimizing the time and effort spent in identifying controls, while still ensuring that
high risks are appropriately assessed.
The context is established first. Then, a risk assessment is conducted. If this provides sufficient
information to effectively determine the actions required to modify the risks to an acceptable level,
then the task is complete and the risk treatment follows. If the information is insufficient, another
iteration of the risk assessment with revised context (e.g. risk evaluation criteria, risk acceptance
criteria or impact criteria) is conducted, possibly on limited parts of the total scope (see Figure 2, Risk
Decision Point 1).
The effectiveness of the risk treatment depends on the results of the risk assessment.
Note that risk treatment involves a cyclical process of:
— assessing a risk treatment;
4 © ISO/IEC 2018 – All rights reserved

— deciding whether residual risk levels are acceptable;
— generating a new risk treatment if risk levels are not acceptable; and
— assessing the effectiveness of that treatment.
It is possible that the risk treatment does not immediately lead to an acceptable level of residual risk.
In this situation, another iteration of the risk assessment with changed context parameters (e.g. risk
assessment, risk acceptance or impact criteria), if necessary, can be required, followed by further risk
treatment (see Figure 2, Risk Decision Point 2).
The risk acceptance activity has to ensure residual risks are explicitly accepted by the managers of
the organization. This is especially important in a situation where the implementation of controls is
omitted or postponed, e.g. due to cost.
During the whole information security risk management process, it is important that risks and their
treatment are communicated to the appropriate managers and operational staff. Even before the
treatment of the risks, information about identified risks can be very valuable to manage incidents and
can help to reduce potential damage. Awareness by managers and staff of the risks, the nature of the
controls in place to mitigate the risks and the areas of concern to the organization assist in dealing with
incidents and unexpected events in the most effective manner. The detailed results of every activity
of the information security risk management process and from the two risk decision points should be
documented.
ISO/IEC 27001 specifies that the controls implemented within the scope, boundaries and context of
the ISMS need to be risk-based. The application of an information security risk management process
can satisfy this requirement. There are many approaches by which controls can be determined to
implement the risk treatment options chosen.
The organization should establish, implement and maintain a procedure to identify the legal
requirements applicable to:
— the selection of criteria for risk evaluation (7.2.2), risk impact (7.2.3) and risk acceptance (7.2.4);
— the definition of the scope and boundaries of information security risk management (7.3 and A.2);
— risk evaluation (8.4);
— risk treatment of (9.1) and the implementation of risk reduction plans (9.2 and Annex F);
— the monitoring, review and improvement of risk management (12.2);
— asset identification (B.1.3) and asset valuation (B.2.3); and
— risk estimation (see examples in E.2.1).
7 Context establishment
7.1 General considerations
Input: All information about the organization relevant to the information security risk management
context establishment.
Action: The external and internal context for information security risk management should be
established, which involves setting the basic criteria necessary for information security risk
management (7.2), defining the scope and boundaries (7.3), and establishing an appropriate
organization operating the information security risk management (7.4).
Implementation guidance:
© ISO/IEC 2018 – All rights reserved 5

It is essential to determine the purpose of the information security risk management as this affects the
overall process and the context establishment in particular. This purpose can be:
— supporting an ISMS;
— legal compliance and evidence of due diligence;
— preparation of a business continuity plan;
— preparation of an incident response plan; and
— description of the information security requirements for a product, a service or a mechanism.
Implementation guidance for context establishment elements needed to support an ISMS is further
discussed in 7.2, 7.3 and 7.4 below.
Output: The specification of basic criteria, the scope and boundaries, and the organization for the
information security risk management process.
7.2 Basic criteria
7.2.1 Risk management approach
Depending on the scope and objectives of the risk management, different approaches can be applied.
The approach can also be different for each iteration.
An appropriate risk management approach should be selected or developed that addresses basic criteria
such as: risk evaluation criteria, impact criteria, risk acceptance criteria.
Additionally, the organization should assess whether necessary resources are available to:
— perform risk assessment and establish a risk treatment plan;
— define and implement policies and procedures, including implementation of the controls selected;
— monitor controls; and
— monitor the information security risk management process.
7.2.2 Risk evaluation criteria
Risk evaluation criteria should be developed for evaluating the organization's information security risk
considering the following:
— the strategic value of the business information process;
— the criticality of the information assets involved;
— operational and business importance of availability, confidentiality and integrity;
— stakeholders’ expectations and perceptions, and negative consequences for goodwill and reputation;
Additionally, risk evaluation criteria can be used to specify priorities for risk treatment.
7.2.3 Impact criteria
NOTE ISO 31000 uses a concept of “consequence criteria” instead of “impact criteria”.
Impact criteria should be developed and specified in terms of the degree of damage or costs to the
organization caused by an information security event considering the following:
— level of classification of the impacted information asset;
6 © ISO/IEC 2018 – All rights reserved

— breaches of information security (e.g. loss of confidentiality, integrity and availability);
— impaired operations (internal or third parties);
— loss of business and financial value;
— disruption of plans and deadlines;
— damage of reputation;
7.2.4 Risk acceptance criteria
Risk acceptance criteria should be developed and specified. Risk acceptance criteria often depend on
the organization's policies, goals, objectives and the interests of stakeholders.
An organization should define its own scales for levels of risk acceptance. The following should be
considered during development:
— risk acceptance criteria can include multiple thresholds, with a desired target level of risk, but
provision for senior managers to accept risks above this level under defined circumstances;
— risk acceptance criteria can be expressed as the ratio of estimated profit (or other business benefit)
to the estimated risk;
— different risk acceptance criteria can apply to different classes of risk;
— risk acceptance criteria can include requirements for future additional treatment, e.g. a risk can
be accepted if there is approval and commitment to take action to reduce it to an acceptable level
within a defined time period.
Risk acceptance criteria can differ according to how long the risk is expected to exist, e.g. the risk
can be associated with a temporary or short-term activity. Risk acceptance criteria should be set up
considering the following:
— business criteria;
— operations;
— technology;
— finance;
— social and humanitarian factors.
More information can be found in Annex A.
7.3 Scope and boundaries
The organization should define the scope and boundaries of information security risk management.
The scope of the information security risk management process needs to be defined to ensure that all
relevant assets are taken into account in the risk assessment. In addition, the boundaries need to be
identified to address those risks that can arise through these boundaries.
Information about the organization should be collected to determine the environment it operates in
and its relevance to the information security risk management process.
When defining the scope and boundaries, the organization should consider the following information:
— the organization's strategic business objectives, strategies and policies;
— business processes;
© ISO/IEC 2018 – All rights reserved 7

— the organization’s functions and structure;
— the organization's information security policy;
— the organization’s overall approach to risk management;
— information assets;
— locations of the organization and their geographical characteristics;
— constraints affecting the organization;
— expectation of stakeholders;
— socio-cultural environment;
— interfaces (i.e. information exchange with the environment).
Additionally, the organization should provide justification for any exclusion from the scope.
Examples of the risk management scope may be an IT application, IT infrastructure, a business process,
or a defined part of an organization.
Further information can be found in Annex A.
7.4 Organization for information security risk management
The organization and responsibilities for the information security risk management process should be
set up and maintained. The following are the main roles and responsibilities of this organization:
— development of the information security risk management process suitable for the organization;
— identification and analysis of the stakeholders;
— definition of roles and responsibilities of all parties both internal and external to the organization;
— establishment of the required relationships between the organization and stakeholders, as well
as interfaces to the organization's high-level risk management functions (e.g. operational risk
management), as well as interfaces to other relevant projects or activities;
— definition of decision escalation paths;
— specification of records to be kept.
This organization should be approved by the appropriate managers of the organization.
8 Information security risk assessment
8.1 General description of information security risk assessment
Input: Basic criteria, the scope and boundaries, and the organization for the information security risk
management process being established.
Action: Risks should be identified, quantified or qualitatively described, and prioritized against risk
evaluation criteria and objectives relevant to the organization.
Implementation guidance:
A risk is a combination of the consequences that would follow from the occurrence of an unwanted
event and the likelihood of the occurrence of the event. Risk assessment quantifies or qualitatively
describes the risk and enables managers to prioritize risks according to their perceived seriousness or
other established criteria.
8 © ISO/IEC 2018 – All rights reserved

Risk assessment consists of the following activities:
— risk identification (8.2);
— risk analysis (8.3);
— risk evaluation (8.4).
Risk assessment determines the value of the information assets, identifies the applicable threats and
vulnerabilities that exist (or can exist), identifies the existing controls and their effect on the risk
identified, determines the potential consequences and, finally, prioritizes the derived risks and ranks
them against the risk evaluation criteria set in the context establishment.
Risk assessment is often conducted in two (or more) iterations. First, a high level assessment is carried
out to identify potentially high risks that warrant further assessment. The next iteration can involve
further in-depth consideration of potentially high risks revealed in the initial iteration. Where this
provides insufficient information to assess the risk, then further detailed analyses are conducted,
probably on parts of the total scope, and possibly using a different method.
It is up to the organization to select its own approach to risk assessment based on the objectives and the
aim of the risk assessment.
Discussion on information security risk assessment approaches can be found in Annex E.
Output: A list of assessed risks prioritized according to risk evaluation criteria.
8.2 Risk identification
8.2.1 Introduction to risk identification
The purpose of risk identification is to determine what can happen to cause a potential loss, and to gain
insight into how, where and why the loss can happen. The steps described in the following subclauses
should collect input data for the risk analysis activity.
Risk identification should include risks whether or not their source is under the control of the
organization, even though the risk source or cause is perhaps not evident.
NOTE Activities described in subsequent subclauses can be conducted in a different order depending on the
methodology applied.
8.2.2 Identification of assets
Input: Scope and boundaries for the risk assessment to be conducted, list of constituents with owners,
location, function, etc.
Action: The assets within the established scope should be identified.
Implementation guidance:
An asset is anything that has value to the organization and which, therefore, requires protection. For
the identification of assets, it should be borne in mind that an information system consists of more than
hardware and software.
Asset identification should be performed at a suitable level of detail that provides sufficient information
for the risk assessment. The level of detail used on the asset identification influences the overall amount
of information collected during the risk assessment. The level can be refined in further iterations of the
risk assessment.
An asset owner should be identified for each asset, to provide responsibility and accountability for the
asset. The asset owner perhaps does not have property rights to the asset, but has responsibility for its
© ISO/IEC 2018 – All rights reserved 9

production, development, maintenance, use and security as appropriate. The asset owner is often the
most suitable person to determine the asset’s value to the organization (see 8.3.2 for asset valuation).
The review boundary is the perimeter of assets of the organization defined to be managed by the
information security risk management process.
More information on the identification and valuation of assets as related to information security can be
found in Annex B.
Output: A list of assets to be risk-managed, and a list of business processes related to assets and their
relevance.
8.2.3 Identification of threats
Input: Information on threats obtained from incident reviewing, asset owners, users and other sources,
including external threat catalogues.
Action: Threats and their sources should be identified.
Implementation guidance:
A threat has the potential to harm assets such as information, processes and systems and, therefore,
organizations. Threats can be of natural or human origin, and can be accidental or deliberate. Both
accidental and deliberate threat sources should be identified. A threat can arise from within or from
outside the organization. Threats should be identified generically and by type (e.g. unauthorized
actions, physical damage, technical failures); then, where appropriate, individual threats within the
generic class identified. This means no threat is overlooked, including the unexpected, but the volume
of work required is limited.
Some threats can affect more than one asset. In such cases, they can cause different impacts depending
on which assets are affected.
Input to the threat identification and estimation of the likelihood of occurrence (see 8.3.3) can be
obtained from the asset owners or users, from human resources staff, from facility management
and information security specialists, physical security experts, legal department and other relevant
organizations including legal bodies, weather authorities, insurance companies and government
authorities. Aspects of environment and culture should also be considered when addressing threats.
Internal experience from incidents and past threat assessments should be considered in the current
assessment. It can be worthwhile to consult other threat catalogues (maybe specific to an organization
or business) to complete the list of generic threats, where relevant. Threat catalogues and statistics are
available from industry bodies, governments, legal bodies, insurance companies, etc.
When using threat catalogues, or the results of earlier threat assessments, one should be aware that
there is continual change of relevant threats, especially if the business environment or information
systems change.
More information on threat types can be found in Annex C.
Output: A list of threats with the identification of threat type and source.
8.2.4 Identification of existing controls
Input: Documentation of controls, risk treatment implementation plans.
Action: Existing and planned controls should be identified.
Implementation guidance:
Identification of existing controls should be made to avoid unnecessary work or cost, e.g. in the
duplication of controls. In addition, while identifying the existing controls, a check should be made to
10 © ISO/IEC 2018 – All rights reserved

ensure that the controls are working correctly — a reference to already existing ISMS audit reports
should limit the time expended in this task. If a control does not work as expected, this can cause
vulnerabilities. Consideration should be given to the situation where a selected control (or strategy)
fails in operation and, therefore, complementary controls are required to address the identified risk
effectively.
Controls that are planned to be implemented according to the risk treatment implementation plans
should be considered in the same way like those already implemented.
An existing or planned control can be identified as ineffective, or not sufficient, or not justified. If not
justified or not sufficient, the control should be checked to determine whether it should be removed,
replaced by another, more suitable control, or whether it should stay in place, for example, for cost
reasons.
For the identification of existing or planned controls, the following activities can be helpful:
— reviewing documents containing information about the controls (for example, risk treatment
implementation plans) if the processes of information security management are well documented
all existing or planned controls and the status of their implementation should be available;
— checking with the people responsible for information security (e.g. information security officer and
information system security officer, building manager or operations manager) and the users as to
which controls are really implemented for the information process or information system under
consideration;
— conducting an on-site review of the physical controls, comparing those implemented with the list
of what controls should be there, and checking those implemented as to whether they are working
correctly and effectively;
— reviewing results of audits.
Output: A list of all existing and planned controls, their implementation and usage status.
8.2.5 Identification of vulnerabilities
Input: A list of known threats, lists of assets and existing controls.
Action: Vulnerabilities that can be exploited by threats to cause harm to assets or to the organization
should be identified.
Implementation guidance:
Vulnerabilities can be identified in following areas:
— organization;
— processes and procedures;
— management routines;
— personnel;
— physical environment;
— information system configuration;
— hardware, software or communications equipment;
— dependence on external parties.
The presence of a vulnerability does not cause harm in itself, as there needs to be a threat present to
exploit it. A vulnerability that has no corresponding threat may not require the implementation of a
control, but should be recognized and monitored for changes. It should be noted that an incorrectly
© ISO/IEC 2018 – All rights reserved 11

implemented or malfunctioning control or control being used incorrectly can itself be a vulnerability. A
control can be effective or ineffective depending on the environment in which it operates. Conversely, a
threat that does not have a corresponding vulnerability may not result in a risk.
Vulnerabilities can be related to properties of the asset that can be used in a way, or for a purpose,
other than that intended when the asset was purchased or made. Vulnerabilities arising from different
sources need to be considered, for example, those intrinsic or extrinsic to the asset.
Examples of vulnerabilities and methods for vulnerability assessment can be found in Annex D.
Output: A list of vulnerabilities in relation to assets, threats and controls; a list of vulnerabilities that do
not relate to any identified threat for review.
8.2.6 Identification of consequences
Input: A list of assets, a list of business processes, and a list of threats and
...

INTERNATIONAL ISO/IEC
STANDARD 27005
Redline version
compares Third edition to
Second edition
Information technology — Security
techniques — Information security
risk management
Technologies de l'information — Techniques de sécurité — Gestion
des risques liés à la sécurité de l'information
Reference number
ISO/IEC 27005:redline:2018(E)
©
ISO/IEC 2018
ISO/IEC 27005:redline:2018(E)
IMPORTANT — PLEASE NOTE
This is a mark-up copy and uses the following colour coding:
Text example 1 — indicates added text (in green)
Text example 2 — indicates removed text (in red)
— indicates added graphic figure
— indicates removed graphic figure
1.x . — Heading numbers containg modifications are highlighted in yellow in
the Table of Contents
DISCLAIMER
This Redline version provides you with a quick and easy way to compare the main changes
between this edition of the standard and its previous edition. It doesn’t capture all single
changes such as punctuation but highlights the modifications providing customers with
the most valuable information. Therefore it is important to note that this Redline version is
not the official ISO standard and that the users must consult with the clean version of the
standard, which is the official standard, for implementation purposes.
© ISO/IEC 2018
All rights reserved. Unless otherwise specified, or required in the context of its implementation, 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
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2018 – All rights reserved

ISO/IEC 27005:redline:2018(E)
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Structure of this International Standard document . 5
5 Background . 6
6 Overview of the information security risk management process .7
7 Context establishment .11
7.1 General considerations .11
7.2 Basic criteria .11
7.2.1 Risk management approach .11
7.2.2 Risk evaluation criteria .12
7.2.3 Impact criteria .12
7.2.4 Risk acceptance criteria .12
7.3 Scope and boundaries .13
7.4 Organization for information security risk management .14
8 Information security risk assessment .14
8.1 General description of information security risk assessment .14
8.2 Risk identification .15
8.2.1 Introduction to risk identification .15
8.2.2 Identification of assets .15
8.2.3 Identification of threats .16
8.2.4 Identification of existing controls .16
8.2.5 Identification of vulnerabilities.17
8.2.6 Identification of consequences .18
8.3 Risk analysis .18
8.3.1 Risk analysis methodologies.18
8.3.2 Assessment of consequences .20
8.3.3 Assessment of incident likelihood .21
8.3.4 Level of risk determination .21
8.4 Risk evaluation .22
9 Information security risk treatment .23
9.1 General description of risk treatment .23
9.2 Risk modification .25
9.3 Risk retention .26
9.4 Risk avoidance .26
9.5 Risk sharing .26
10 Information security risk acceptance .27
11 Information security risk communication and consultation .27
12 Information security risk monitoring and review .28
12.1 Monitoring and review of risk factors .28
12.2 Risk management monitoring, review and improvement .29
Annex A (informative) Defining the scope and boundaries of the information security risk
management process .31
Annex B (informative) Identification and valuation of assets and impact assessment .37
Annex C (informative) Examples of typical threats .53
© ISO/IEC 2018 – All rights reserved iii

ISO/IEC 27005:redline:2018(E)
Annex D (informative) Vulnerabilities and methods for vulnerability assessment.58
Annex E (informative) Information security risk assessment approaches .64
Annex F (informative) Constraints for risk modification .71
Annex G (informative) Differences in definitions between ISO/IEC 27005:2008 and ISO/
IEC 27005:2011 .75
Bibliography .84
iv © ISO/IEC 2018 – All rights reserved

ISO/IEC 27005:redline:2018(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
International Standards areThe 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 document should be noted. This document was
drafted in accordance with the rules given ineditorial rules of the ISO/IEC Directives, Part 2 (see www
.iso .org/directives).
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the national bodies
casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC 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 voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see the following
URL: www .iso .org/iso/foreword .html.
ISO/IEC 27005This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information
technology, Subcommittee SC 27, IT Security techniques.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/members .html.
This secondthird edition cancels and replaces the firstsecond edition (ISO/IEC 27005:20082011) which
has been technically revised. The main changes from the previous edition are as follows:
— all direct references to the ISO/IEC 27001:2005 have been removed;
— clear information has been added that this document does not contain direct guidance on the
implementation of the ISMS requirements specified in ISO/IEC 27001 (see Introduction);
— ISO/IEC 27001:2005 has been removed from Clause 2;
— ISO/IEC 27001 has been added to the Bibliography;
— Annex G and all references to it have been removed;
— editorial changes have been made accordingly.
© ISO/IEC 2018 – All rights reserved v

ISO/IEC 27005:redline:2018(E)
Introduction
This International Standarddocument provides guidelines for information security risk management
in an organization, supporting in particular the requirements of an information security management
(ISMS) according to ISO/IEC 27001. However, this International Standarddocument does not provide
any specific method for information security risk management. It is up to the organization to define their
approach to risk management, depending for example on the scope of the ISMSan information security
management system (ISMS), context of risk management, or industry sector. A number of existing
methodologies can be used under the framework described in this International Standarddocument to
implement the requirements of an ISMS. This document is based on the asset, threat and vulnerability
risk identification method that is no longer required by ISO/IEC 27001. There are some other approaches
that can be used.
This document does not contain direct guidance on the implementation of the ISMS requirements given
in ISO/IEC 27001.
This International Standarddocument is relevant to managers and staff concerned with information
security risk management within an organization and, where appropriate, external parties supporting
such activities.
vi © ISO/IEC 2018 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 27005:redline:2018(E)
Information technology — Security techniques —
Information security risk management
1 Scope
This International Standarddocument provides guidelines for information security risk management.
This International Standarddocument supports the general concepts specified in ISO/IEC 27001 and is
designed to assist the satisfactory implementation of information security based on a risk management
approach.
Knowledge of the concepts, models, processes and terminologies described in ISO/IEC 27001 and ISO/
IEC 27002 is important for a complete understanding of this International Standarddocument.
This International Standarddocument is applicable to all types of organizations (e.g. commercial
enterprises, government agencies, non-profit organizations) which intend to manage risks that couldcan
compromise the organization’s information security.
2 Normative references
The following referenced documents are indispensable for the application ofreferred to in the text
in such a way that some or all of their content constitutes requirements of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO/IEC 27000, Information technology — Security techniques — Information security management
systems — Overview and vocabulary
ISO/IEC 27001:2005, Information technology — Security techniques — Information security management
systems — Requirements
ISO/IEC 27000, Information technology — Security techniques — Information security management
systems — Overview and vocabulary
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 27000 and the
following apply.
NOTE Differences in definitions between ISO/IEC 27005:2008 and this International Standard are shown in
Annex G.
3.1
consequence
outcome of an event (3.3) affecting objectives
[SOURCE: ISO Guide 73:2009]
Note 1 to entry: An event can lead to a range of consequences.
Note 2 to entry: A consequence can be certain or uncertain and in the context of information security is usually
negative.
Note 3 to entry: Consequences can be expressed qualitatively or quantitatively.
Note 4 to entry: Initial consequences can escalate through knock-on effects.
© ISO/IEC 2018 – All rights reserved 1

ISO/IEC 27005:redline:2018(E)
3.2
control
measure that is modifying risk (3.9)
[SOURCE: ISO Guide 73:2009]
Note 1 to entry: Controls for information security include any process, policy, procedure, guideline, practice or
organizational structure, which can be administrative, technical, management, or legal in nature which modify
information security risk.
Note 2 to entry: Controls may not always exert the intended or assumed modifying effect.
Note 3 to entry: Control is also used as a synonym for safeguard or countermeasure.
3.3
event
occurrence or change of a particular set of circumstances
[SOURCE: ISO Guide 73:2009]
Note 1 to entry: An event can be one or more occurrences, and can have several causes.
Note 2 to entry: An event can consist of something not happening.
Note 3 to entry: An event can sometimes be referred to as an “incident” or “accident”.
3.4
external context
external environment in which the organization seeks to achieve its objectives
[SOURCE: ISO Guide 73:2009]
Note 1 to entry: External context can include:
— the cultural, social, political, legal, regulatory, financial, technological, economic, natural and competitive
environment, whether international, national, regional or local;
— key drivers and trends having impact on the objectives of the organization; and
— relationships with, and perceptions and values of, external stakeholders.
3.5
internal context
internal environment in which the organization seeks to achieve its objectives
[SOURCE: ISO Guide 73:2009]
Note 1 to entry: Internal context can include:
— governance, organizational structure, roles and accountabilities;
— policies, objectives, and the strategies that are in place to achieve them;
— the capabilities, understood in terms of resources and knowledge (e.g. capital, time, people, processes,
systems and technologies);
— information systems, information flows and decision-making processes (both formal and informal);
— relationships with, and perceptions and values of, internal stakeholders;
— the organization's culture;
— standards, guidelines and models adopted by the organization; and
— form and extent of contractual relationships.
2 © ISO/IEC 2018 – All rights reserved

ISO/IEC 27005:redline:2018(E)
3.6
level of risk
magnitude of a risk (3.9), expressed in terms of the combination of consequences (3.1) and their
likelihood (3.7)
[SOURCE: ISO Guide 73:2009]
3.7
likelihood
chance of something happening
[SOURCE: ISO Guide 73:2009]
Note 1 to entry: In risk management terminology, the word “likelihood” is used to refer to the chance of something
happening, whether defined, measured or determined objectively or subjectively, qualitatively or quantitatively,
and described using general terms or mathematically (such as a probability or a frequency over a given time
period).
Note 2 to entry: The English term “likelihood” does not have a direct equivalent in some languages; instead, the
equivalent of the term “probability” is often used. However, in English, “probability” is often narrowly interpreted
as a mathematical term. Therefore, in risk management terminology, “likelihood” is used with the intent that it
should have the same broad interpretation as the term “probability” has in many languages other than English.
3.8
residual risk
risk (3.9) remaining after risk treatment (3.17)
[SOURCE: ISO Guide 73:2009]
Note 1 to entry: Residual risk can contain unidentified risk.
Note 2 to entry: Residual risk can also be known as “retained risk”.
3.9
risk
effect of uncertainty on objectives
[SOURCE: ISO Guide 73:2009]
Note 1 to entry: An effect is a deviation from the expected — positive and/or negative.
Note 2 to entry: Objectives can have different aspects (such as financial, health and safety, information security,
and environmental goals) and can apply at different levels (such as strategic, organization-wide, project, product
and process).
Note 3 to entry: Risk is often characterized by reference to potential events (3.3) and consequences (3.1), or a
combination of these.
Note 4 to entry: Information security risk is often expressed in terms of a combination of the consequences of an
information security event and the associated likelihood (3.9) of occurrence.
Note 5 to entry: Uncertainty is the state, even partial, of deficiency of information related to, understanding or
knowledge of, an event, its consequence, or likelihood.
Note 6 to entry: Information security risk is associated with the potential that threats will exploit vulnerabilities
of an information asset or group of information assets and thereby cause harm to an organization.
3.10
risk analysis
process to comprehend the nature of risk and to determine the level of risk (3.6)
[SOURCE: ISO Guide 73:2009]
Note 1 to entry: Risk analysis provides the basis for risk evaluation and decisions about risk treatment.
© ISO/IEC 2018 – All rights reserved 3

ISO/IEC 27005:redline:2018(E)
Note 2 to entry: Risk analysis includes risk estimation.
3.11
risk assessment
overall process of risk identification (3.15), risk analysis (3.10) and risk evaluation (3.14)
[SOURCE: ISO Guide 73:2009]
3.12
risk communication and consultation
continual and iterative processes that an organization conducts to provide, share or obtain information,
and to engage in dialogue with stakeholders (3.18) regarding the management of risk (3.9)
[SOURCE: ISO Guide 73:2009]
Note 1 to entry: The information can relate to the existence, nature, form, likelihood, significance, evaluation,
acceptability and treatment of risk.
Note 2 to entry: Consultation is a two-way process of informed communication between an organization and its
stakeholders on an issue prior to making a decision or determining a direction on that issue. Consultation is:
— a process which impacts on a decision through influence rather than power; and
— an input to decision making, not joint decision making.
3.13
risk criteria
terms of reference against which the significance of a risk (3.9) is evaluated
[SOURCE: ISO Guide 73:2009]
Note 1 to entry: Risk criteria are based on organizational objectives, and external and internal context.
Note 2 to entry: Risk criteria can be derived from standards, laws, policies and other requirements.
3.14
risk evaluation
process of comparing the results of risk analysis (3.10) with risk criteria (3.13) to determine whether
the risk and/or its magnitude is acceptable or tolerable
[SOURCE: ISO Guide 73:2009]
Note 1 to entry: Risk evaluation assists in the decision about risk treatment.
3.15
risk identification
process of finding, recognizing and describing risks
[SOURCE: ISO Guide 73:2009]
Note 1 to entry: Risk identification involves the identification of risk sources, events, their causes and their
potential consequences.
Note 2 to entry: Risk identification can involve historical data, theoretical analysis, informed and expert opinions,
and stakeholders’ needs.
3.16
risk management
coordinated activities to direct and control an organization with regard to risk
[SOURCE: ISO Guide 73:2009]
Note 1 to entry: This International Standard uses the term ‘process’ to describe risk management overall. The
elements within the risk management process are termed ‘activities’
4 © ISO/IEC 2018 – All rights reserved

ISO/IEC 27005:redline:2018(E)
3.17
risk treatment
process to modify risk
[SOURCE: ISO Guide 73:2009]
Note 1 to entry: Risk treatment can involve:
— avoiding the risk by deciding not to start or continue with the activity that gives rise to the risk;
— taking or increasing risk in order to pursue an opportunity;
— removing the risk source;
— changing the likelihood;
— changing the consequences;
— sharing the risk with another party or parties (including contracts and risk financing); and
— retaining the risk by informed choice.
Note 2 to entry: Risk treatments that deal with negative consequences are sometimes referred to as “risk
mitigation”, “risk elimination”, “risk prevention” and “risk reduction”.
Note 3 to entry: Risk treatment can create new risks or modify existing risks.
3.18
stakeholder
person or organization that can affect, be affected by, or perceive themselves to be affected by a decision
or activity
[SOURCE: ISO Guide 73:2009]
Note 1 to entry: decision maker can be a stakeholder.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https: //www .iso .org/obp
— IEC Electropedia: available at http: //www .electropedia .org/
4 Structure of this International Standard document
This International Standarddocument contains the description of the information security risk
management process and its activities.
The background information is provided in Clause 5.
A general overview of the information security risk management process is given in Clause 6.
All information security risk management activities as presented in Clause 6 are subsequently
described in the following clauses:
• — context establishment in Clause 7,;
• — risk assessment in Clause 8,;
• — risk treatment in Clause 9,;
• — risk acceptance in Clause Clause 10,;
• — risk communication in Clause 11,;
• — risk monitoring and review in Clause 12.
© ISO/IEC 2018 – All rights reserved 5

ISO/IEC 27005:redline:2018(E)
Additional information for information security risk management activities is presented in the
annexes. The context establishment is supported by Annex A (Defining the scope and boundaries of
the information security risk management process). Identification and valuation of assets and impact
assessments are discussed in Annex B. Annex C gives examples of typical threats and Annex D discusses
vulnerabilities and methods for vulnerability assessment. Examples of information security risk
assessment approaches are presented in Annex E.
Constraints for risk modification are presented in Annex F.
Differences in definitions between ISO/IEC 27005:2008 and ISO/IEC 27005:2011 are shown in Annex G.
All risk management activities as presented from Clause 7 to Clause 12 are structured as follows:
Input: Identifies any required information to perform the activity.
Action: Describes the activity.
Implementation guidance: Provides guidance on performing the action. Some of this guidance may not
be suitable in all cases and so other ways of performing the action may be more appropriate.
Output: Identifies any information derived after performing the activity.
5 Background
A systematic approach to information security risk management is necessary to identify organizational
needs regarding information security requirements and to create an effective information security
management system (ISMS). This approach should be suitable for the organization´s environment, and
in particularorganization’s environment and, in particular, should be aligned with overall enterprise
risk management. Security efforts should address risks in an effective and timely manner where
and when they are needed. Information security risk management should be an integral part of all
information security management activities and should be applied both to the implementation and the
ongoing operation of an ISMS.
Information security risk management should be a continual process. The process should establish
the external and internal context, assess the risks and treat the risks using a risk treatment plan to
implement the recommendations and decisions. Risk management analyses what can happen and what
the possible consequences can be, before deciding what should be done and when, to reduce the risk to
an acceptable level.
Information security risk management should contribute to the following:
— risks being identified;
•
• — risks being assessed in terms of their consequences to the business and the likelihood of their
occurrence;
• — the likelihood and consequences of these risks being communicated and understood;
• — priority order for risk treatment being established;
• — priority for actions to reduce risks occurring;
• — stakeholders being involved when risk management decisions are made and kept informed of the
risk management status;
• — effectiveness of risk treatment monitoring;
• — risks and the risk management process being monitored and reviewed regularly;
• — information being captured to improve the risk management approach;
• — managers and staff being educated about the risks and the actions taken to mitigate them.
6 © ISO/IEC 2018 – All rights reserved

ISO/IEC 27005:redline:2018(E)
The information security risk management process can be applied to the organization as a whole, any
discrete part of the organization (e.g. a department, a physical location, a service), any information
system, existing or planned or particular aspects of control (e.g. business continuity planning).
6 Overview of the information security risk management process
A high level view of the risk management process is specified in ISO 31000 and shown in Figure 1.
Figure 1 — The risk management process
© ISO/IEC 2018 – All rights reserved 7

ISO/IEC 27005:redline:2018(E)
Figure 2 shows how this International Standarddocument applies this risk management process.
The information security risk management process consists of context establishment (Clause 7), risk
assessment (Clause 8), risk treatment (Clause 9), risk acceptance (Clause 10), risk communication and
consultation (Clause 11), and risk monitoring and review (Clause 12).
8 © ISO/IEC 2018 – All rights reserved

ISO/IEC 27005:redline:2018(E)
Figure 2 — Illustration of an information security risk management process
As Figure 2 illustrates, the information security risk management process can be iterative for risk
assessment and/or risk treatment activities. An iterative approach to conducting risk assessment can
increase depth and detail of the assessment at each iteration. The iterative approach provides a good
balance between minimizing the time and effort spent in identifying controls, while still ensuring that
high risks are appropriately assessed.
The context is established first. Then, a risk assessment is conducted. If this provides sufficient
information to effectively determine the actions required to modify the risks to an acceptable level,
then the task is complete and the risk treatment follows. If the information is insufficient, another
iteration of the risk assessment with revised context (e.g. risk evaluation criteria, risk acceptance
criteria or impact criteria) will beis conducted, possibly on limited parts of the total scope (see Figure 2,
Risk Decision Point 1).
The effectiveness of the risk treatment depends on the results of the risk assessment.
Note that risk treatment involves a cyclical process of:
• — assessing a risk treatment;
© ISO/IEC 2018 – All rights reserved 9

ISO/IEC 27005:redline:2018(E)
• — deciding whether residual risk levels are acceptable;
• — generating a new risk treatment if risk levels are not acceptable; and
• — assessing the effectiveness of that treatment.
It is possible that the risk treatment willdoes not immediately lead to an acceptable level of residual
risk. In this situation, another iteration of the risk assessment with changed context parameters (e.g.
risk assessment, risk acceptance or impact criteria), if necessary, can be required, followed by further
risk treatment (see Figure 2, Risk Decision Point 2).
The risk acceptance activity has to ensure residual risks are explicitly accepted by the managers of
the organization. This is especially important in a situation where the implementation of controls is
omitted or postponed, e.g. due to cost.
During the whole information security risk management process, it is important that risks and their
treatment are communicated to the appropriate managers and operational staff. Even before the
treatment of the risks, information about identified risks can be very valuable to manage incidents and
can help to reduce potential damage. Awareness by managers and staff of the risks, the nature of the
controls in place to mitigate the risks and the areas of concern to the organization assist in dealing with
incidents and unexpected events in the most effective manner. The detailed results of every activity
of the information security risk management process and from the two risk decision points should be
documented.
ISO/IEC 27001 specifies that the controls implemented within the scope, boundaries and context of
the ISMS need to be risk -based. The application of an information security risk management process
can satisfy this requirement. There are many approaches by which the process can be successfully
implemented in an organization. The organization should use whatever approach best suits their
circumstances for each specific application of the processcontrols can be determined to implement the
risk treatment options chosen.
In an ISMS, establishing the context, risk assessment, developing risk treatment plan and risk
acceptance are all part of the “plan” phase. In the “do” phase of the ISMS, the actions and controls
required to reduce the risk to an acceptable level are implemented according to the risk treatment plan.
In the “check” phase of the ISMS, managers will determine the need for revisions of the risk assessment
and risk treatment in the light of incidents and changes in circumstances. In the ”act” phase, any actions
required, including additional application of the information security risk management process, are
performed.
The following table summarizes the information security risk management activities relevant to the
four phases of the ISMS processorganization should establish, implement and maintain a procedure to
identify the legal requirements applicable to:
Table 1 — Alignment of ISMS and Information Security Risk Management Process
ISMS Process Information Security Risk Management Process
Plan Establishing the context
Risk assessment
Developing risk treatment plan
Risk acceptance
Do Implementation of risk treatment plan
Check Continual monitoring and reviewing of risks
Act Maintain and improve the Information Security Risk Management Process
— the selection of criteria for risk evaluation (7.2.2), risk impact (7.2.3) and risk acceptance (7.2.4);
— the definition of the scope and boundaries of information security risk management (7.3 and A.2);
— risk evaluation (8.4);
— risk treatment of (9.1) and the implementation of risk reduction plans (9.2 and Annex F);
10 © ISO/IEC 2018 – All rights reserved

ISO/IEC 27005:redline:2018(E)
— the monitoring, review and improvement of risk management (12.2);
— asset identification (B.1.3) and asset valuation (B.2.3); and
— risk estimation (see examples in E.2.1).
7 Context establishment
7.1 General considerations
Input: All information about the organization relevant to the information security risk management
context establishment.
Action: The external and internal context for information security risk management should be
established, which involves setting the basic criteria necessary for information security risk
management (7.2), defining the scope and boundaries (7.3), and establishing an appropriate
organization operating the information security risk management (7.4).
Implementation guidance:
It is essential to determine the purpose of the information security risk management as this affects the
overall process and the context establishment in particular. This purpose can be:
• — supporting an ISMS;
• — legal compliance and evidence of due diligence;
• — preparation of a business continuity plan;
• — preparation of an incident response plan; and
• — description of the information security requirements for a product, a service or a mechanism.
Implementation guidance for context establishment elements needed to support an ISMS is further
discussed in Clauses 7.2, 7.3 and 7.4 below.
NOTE ISO/IEC 27001:2005 does not use the term “context”. However, all of Clause 7 relates to the
requirements “define the scope and boundaries of the ISMS” [4.2.1 a)], “define an ISMS policy” [4.2.1 b)] and
“define the risk assessment approach” [4.2.1 c)], specified in ISO/IEC 27001:2005.
Output: The specification of basic criteria, the scope and boundaries, and the organization for the
information security risk management process.
7.2 Basic criteria
7.2.1 Risk management approach
Depending on the scope and objectives of the risk management, different approaches can be applied.
The approach mightcan also be different for each iteration.
An appropriate risk management approach should be selected or developed that addresses basic criteria
such as: risk evaluation criteria, impact criteria, risk acceptance criteria.
Additionally, the organization should assess whether necessary resources are available to:
• — perform risk assessment and establish a risk treatment plan;
• — define and implement policies and procedures, including implementation of the controls selected;
• — Monitor controlsmonitor controls; and
© ISO/IEC 2018 – All rights reserved 11

ISO/IEC 27005:redline:2018(E)
• — monitor the information security risk management process.
NOTE See also ISO/IEC 27001:2005 (Clause 5.2.1) concerning the provision of resources for the
implementation and operation of an ISMS.
7.2.2 Risk evaluation criteria
Risk evaluation criteria should be developed for evaluating the organization's information security risk
considering the followingsfollowing:
• — the strategic value of the business information process;
• — the criticality of the information assets involved;
• Legal and regulatory requirements, and contractual obligations
• — operational and business importance of availability, confidentiality and integrity;
• — Stakeholdersstakeholders’ expectations and perceptions, and negative consequences for goodwill
and reputation;
Additionally, risk evaluation criteria can be used to specify priorities for risk treatment.
7.2.3 Impact criteria
NOTE ISO 31000 uses a concept of “consequence criteria” instead of “impact criteria”.
Impact criteria should be developed and specified in terms of the degree of damage or costs to the
organization caused by an information security event considering the following:
• — level of classification of the impacted information asset;
• — breaches of information security (e.g. loss of confidentiality, integrity and availability);
• — impaired operations (internal or third parties);
• — loss of business and financial value;
• — disruption of plans and deadlines;
• — damage of reputation;
• Breaches of legal, regulatory or contractual requirements
NOTE See also ISO/IEC 27001:2005 [Clause 4.2.1 d) 4] concerning the impact criteria identification for losses
of confidentiality, integrity and availability.
7.2.4 Risk acceptance criteria
Risk acceptance criteria should be developed and specified. Risk acceptance criteria often depend on
the organization's policies, goals, objectives and the interests of stakeholders.
An organization should define its own scales for levels of risk acceptance. The following should be
considered during development:
• — risk acceptance criteria can include multiple thresholds, with a desired target level of risk, but
provision for senior managers to accept risks above this level under defined circumstances;
• — risk acceptance criteria can be expressed as the ratio of estimated profit (or other business benefit)
to the estimated risk;
12 © ISO/IEC 2018 – All rights reserved

ISO/IEC 27005:redline:2018(E)
• — different risk acceptance criteria can apply to different classes of risk, e.g. risks that could result in
non-compliance with regulations or laws may not be accepted, while acceptance of high risks may
be allowed if this is specified as a contractual requirement;
• — risk acceptance criteria can include requirements for future additional treatment, e.g. a risk can
be accepted if there is approval and commitment to take action to reduce it to an acceptable level
within a defined time period.
Risk acceptance criteria can differ according to how long the risk is expected to exist, e.g. the risk
can be associated with a temporary or short -term activity. Risk acceptance criteria should be set up
considering the following:
• — business criteria;
• — Legal and regulatory aspectsoperations;
• — Operationstechnology;
• — Technologyfinance;
• Finance
• — social and humanitarian factors.
NOTE Risk acceptance criteria correspond to “criteria for accepting risks and identify the acceptable level of
risk” specified in ISO/IEC 27001:2005 Clause 4.2.1 c) 2).
More information can be found in Annex A.
7.3 Scope and boundaries
The organization should define the scope and boundaries of information security risk management.
The scope of the information security risk management process needs to be defined to ensure that
all relevant assets are taken into account in the risk assessment. In addition, the boundaries need to
be identified [see also ISO/IEC 27001:2005 Clause 4.2.1 a)]to address those risks that mightcan arise
through these boundaries.
Information about the organization should be collected to determine the environment it operates in
and its relevance to the information security risk management process.
When de
...

NORME ISO/IEC
INTERNATIONALE 27005
Troisième édition
2018-07
Technologies de l'information —
Techniques de sécurité — Gestion
des risques liés à la sécurité de
l'information
Information technology — Security techniques — Information
security risk management
Numéro de référence
©
ISO/IEC 2018
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO/IEC 2018
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, 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, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: +41 22 749 01 11
Fax: +41 22 749 09 47
E-mail: copyright@iso.org
Web: www.iso.org
Publié en Suisse
ii © ISO/IEC 2018 – 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 Structure du présent document . 1
5 Contexte . 2
6 Présentation générale du processus de gestion des risques en sécurité de l'information .3
7 Établissement du contexte . 6
7.1 Considérations générales . 6
7.2 Critères de base . 6
7.2.1 Approche de gestion des risques . 6
7.2.2 Critères d'évaluation du risque . 7
7.2.3 Critères d'impact . 7
7.2.4 Critères d'acceptation des risques . 7
7.3 Domaine d'application et limites . 8
7.4 Organisation de la gestion des risques en sécurité de l'information . 9
8 Appréciation des risques en sécurité de l'information . 9
8.1 Description générale de l'appréciation des risques en sécurité de l'information . 9
8.2 Identification des risques .10
8.2.1 Introduction à l'identification des risques .10
8.2.2 Identification des actifs .10
8.2.3 Identification des menaces .11
8.2.4 Identification des mesures de sécurité existantes .11
8.2.5 Identification des vulnérabilités .12
8.2.6 Identification des conséquences .13
8.3 Analyse des risques .14
8.3.1 Méthodologies d'analyse des risques .14
8.3.2 Appréciation des conséquences .15
8.3.3 Appréciation de la vraisemblance d'un incident .16
8.3.4 Estimation du niveau des risques .16
8.4 Évaluation des risques.17
9 Traitement des risques en sécurité de l'information .17
9.1 Description générale du traitement des risques.17
9.2 Réduction du risque .19
9.3 Maintien des risques .20
9.4 Refus des risques .21
9.5 Partage des risques .21
10 Acceptation des risques en sécurité de l'information .21
11 Communication et concertation relatives aux risques en sécurité de l'information .22
12 Surveillance et réexamen des risques en sécurité de l'information .23
12.1 Surveillance et réexamen des facteurs de risque .23
12.2 Surveillance, réexamen et amélioration de la gestion des risques .24
Annexe A (informative) Définition du domaine d'application et des limites du processus de
gestion des risques en sécurité de l'information .26
Annexe B (informative) Identification et valorisation des actifs et appréciation des impacts.31
Annexe C (informative) Exemples de menaces types .40
© ISO/IEC 2018 – Tous droits réservés iii

Annexe D (informative) Vulnérabilités et méthodes d'appréciation des vulnérabilités .44
Annexe E (informative) Approches d'appréciation des risques en sécurité de l'information .49
Annexe F (informative) Contraintes liées à la réduction du risque .55
Bibliographie .57
iv © ISO/IEC 2018 – Tous droits réservés

Avant-propos
L'ISO (Organisation internationale de normalisation) et l’IEC (Commission électrotechnique
internationale) forment le système spécialisé de la normalisation mondiale. Les organismes
nationaux membres de l'ISO ou de l’IEC participent au développement de Normes internationales
par l'intermédiaire des comités techniques créés par l'organisation concernée afin de s'occuper des
domaines particuliers de l'activité technique. Les comités techniques de l'ISO et de l’IEC collaborent
dans des domaines d'intérêt commun. D'autres organisations internationales, gouvernementales et non
gouvernementales, en liaison avec l'ISO et l’IEC, participent également aux travaux. Dans le domaine
des technologies de l'information, l'ISO et l’IEC ont créé un comité technique mixte, l'ISO/IEC JTC 1.
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 attiré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 et l’IEC ne sauraient être tenues pour
responsables 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 nature volontaire des normes, 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 www .iso .org/avant -propos.
Le présent document a été élaboré par le comité technique ISO/IEC JTC 1, Technologies de l'information,
sous-comité SC 27, Techniques de sécurité des technologies de l'information.
Il convient que l’utilisateur adresse tout retour d’information ou toute question concernant le présent
document à l’organisme national de normalisation de son pays. Une liste exhaustive desdits organismes
se trouve à l’adresse www .iso .org/fr/members .html.
Cette troisième édition annule et remplace la deuxième édition (ISO/IEC 27005:2011) qui a fait l'objet
d'une révision technique.
Les principales modifications par rapport à l’édition précédente sont les suivantes:
— toutes les références directes à l’ISO/IEC 27001:2005 ont été supprimées;
— une information claire a été ajoutée, stipulant que le présent document ne contient pas de
préconisations directes concernant la mise en œuvre des exigences du SMSI spécifiées dans l’ISO/
IEC 27001 (voir Introduction);
— l’ISO/IEC 27001:2005 a été supprimée de l’Article 2;
— l’ISO/IEC 27001 a été ajoutée à la Bibliographie;
— l’Annexe G et toutes les références à cette Annexe ont été supprimées;
— des modifications éditoriales ont été effectuées en conséquence.
© ISO/IEC 2018 – Tous droits réservés v

Introduction
Le présent document contient des lignes directrices relatives à la gestion des risques en sécurité de
l'information dans un organisme. Cependant, le présent document ne fournit aucune méthodologie
spécifique à la gestion des risques en sécurité de l'information. Il est du ressort de chaque organisme de
définir son approche de la gestion des risques, en fonction, par exemple, du périmètre d’un système de
management de la sécurité de l’information (SMSI), de ce qui existe dans l'organisme dans le domaine de
la gestion des risques, ou encore de son secteur industriel. Plusieurs méthodologies existantes peuvent
être utilisées en cohérence avec le cadre décrit dans le présent document pour appliquer les exigences
du SMSI. Le présent document est fondé sur la méthode d’identification des risques liés à des actifs, des
menaces et des vulnérabilités, qui n’est plus exigée par l’ISO/IEC 27001; il existe d’autres approches qui
peuvent être utilisées.
Le présent document ne contient pas de préconisations directes concernant la mise en œuvre des
exigences du SMSI spécifiées dans l’ISO/IEC 27001.
Le présent document s'adresse aux responsables et aux personnels concernés par la gestion des risques
en sécurité de l'information au sein d'un organisme et, le cas échéant, aux tiers prenant part à ces
activités.
vi © ISO/IEC 2018 – Tous droits réservés

NORME INTERNATIONALE ISO/IEC 27005:2018(F)
Technologies de l'information — Techniques de sécurité —
Gestion des risques liés à la sécurité de l'information
1 Domaine d'application
Le présent document contient des lignes directrices relatives à la gestion des risques en sécurité de
l'information.
Le présent document appuie les concepts généraux énoncés dans l'ISO/IEC 27001; il est conçu pour
aider à la mise en place de la sécurité de l'information basée sur une approche de gestion des risques.
Il est important de connaître les concepts, les modèles, les processus et les terminologies décrites dans
l'ISO/IEC 27001 et l'ISO/IEC 27002 afin de bien comprendre le présent document.
Le présent document est applicable à tous types d'organismes (par exemple les entreprises
commerciales, les agences gouvernementales, les organisations à but non lucratif) qui ont l'intention de
gérer des risques susceptibles de compromettre la sécurité des informations de l'organisme.
2 Références normatives
Les documents suivants cités dans le texte constituent, pour tout ou partie de leur contenu, des
exigences 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/IEC 27000, Technologies de l'information — Techniques de sécurité — Systèmes de management de la
sécurité de l'information — Vue d'ensemble et vocabulaire
3 Termes et définitions
Pour les besoins du présent document, les termes et les définitions de l'ISO/IEC 27000 s'appliquent.
L’ISO et l’IEC tiennent à jour des bases de données terminologiques destinées à être utilisées en
normalisation, consultables aux adresses suivantes:
— ISO Online browsing platform: disponible à l’adresse https: //www .iso .org/obp
— IEC Electropedia: disponible à l’adresse http: //www .electropedia .org/
4 Structure du présent document
Le présent document contient la description du processus de gestion des risques en sécurité de
l'information et la description de ses activités.
Les informations générales sont fournies dans l'Article 5.
Un aperçu général du processus de gestion des risques en sécurité de l'information est donné
dans l'Article 6.
Toutes les activités liées à la gestion des risques en sécurité de l'information, telles que présentées
dans l'Article 6, sont ensuite décrites dans les articles suivants:
— établissement du contexte dans l'Article 7;
— appréciation des risques dans l'Article 8;
— traitement des risques dans l'Article 9;
— acceptation des risques dans l'Article 10;
— communication et concertation relatives aux risques dans l'Article 11;
— surveillance et réexamen des risques dans l'Article 12.
Des informations supplémentaires relatives aux activités de gestion des risques en sécurité de
l'information sont présentées dans les annexes. L'établissement du contexte est abordé dans l'Annexe A
(Définition du domaine d'application et des limites du processus de gestion des risques en sécurité de
l'information). L'identification, la valorisation des actifs et l'appréciation des impacts sont traitées dans
l'Annexe B. L'Annexe C donne des exemples de menaces type et l'Annexe D traite des vulnérabilités et
des méthodes d’appréciation des vulnérabilités. Des exemples d'approches relatives à l'appréciation des
risques en sécurité de l'information sont présentés dans l'Annexe E.
Les contraintes liées à la réduction du risque sont traitées dans l'Annexe F.
Toutes les activités liées à la gestion des risques, présentées dans les Articles 7 à 12, sont structurées de
la manière suivante:
Élément(s) d'entrée: Identifie toute information requise pour réaliser l'activité.
Action: Décrit l'activité.
Préconisations de mise en œuvre: Propose des préconisations pour réaliser l'action. Il se peut que
certaines préconisations ne soient pas adaptées à tous les cas, et que d'autres solutions pour réaliser
l'action s'avèrent préférables.
Élément(s) de sortie: Identifie toute information obtenue après la réalisation de l'activité.
5 Contexte
Une approche systématique de la gestion des risques en sécurité de l'information est nécessaire pour
identifier les besoins organisationnels concernant les exigences en matière de sécurité de l'information,
et pour créer un système de management de la sécurité de l'information (SMSI) efficace. Il convient
que cette approche soit adaptée à l'environnement de l'organisme et soit notamment alignée sur la
démarche générale de gestion des risques de l'entreprise. Il convient que les efforts effectués en matière
de sécurité adressent les risques de manière efficace et opportune quand et lorsque cela est nécessaire.
Il convient que la gestion des risques en sécurité de l'information fasse partie intégrante de l'ensemble
des activités de management de la sécurité de l'information et qu'elle s'applique à la fois à la mise en
œuvre et au fonctionnement d'un SMSI.
Il convient que la gestion des risques en sécurité de l'information soit un processus continu. Il convient
que ce processus établisse le contexte externe et interne, apprécie les risques et les traite à l'aide d'un
plan de traitement des risques permettant de mettre en œuvre les recommandations et décisions.
La gestion des risques analyse les évènements susceptibles de se produire ainsi que leurs possibles
conséquences avant de décider de ce qui pourrait être fait, dans quels délais et à quel moment, pour
réduire les risques à un niveau acceptable.
Il convient que la gestion des risques en sécurité de l'information contribue à ce qui suit:
— l'identification des risques;
— l'appréciation des risques en termes de conséquences sur les activités métier et de vraisemblance;
— la communication et la compréhension de la vraisemblance et des conséquences de ces risques;
— l'établissement d'un ordre de priorité pour le traitement des risques;
2 © ISO/IEC 2018 – Tous droits réservés

— la définition des priorités d'actions afin de réduire les occurrences des risques;
— l'implication des parties prenantes lors de la prise de décisions relatives à la gestion des risques et
l'information sur l'état de la gestion des risques;
— l'efficacité de la supervision du traitement des risques;
— la surveillance et le réexamen réguliers des risques et du processus de gestion des risques;
— la capture de l'information afin d'améliorer l'approche de gestion des risques;
— la formation des dirigeants et du personnel sur les risques et les actions à entreprendre pour les
atténuer.
Le processus de gestion des risques en sécurité de l'information peut s'appliquer à l'organisme dans son
ensemble, à toute partie distincte de l'organisme (à titre d'exemples un département, un lieu physique,
un service), à tout système d'information existant ou prévu, ou à des types particuliers de mesures de
sécurité (par exemple la planification de la continuité d'activité).
6 Présentation générale du processus de gestion des risques en sécurité de
l'information
Un aperçu de haut niveau du processus de gestion des risques est spécifié dans l’ISO 31000 et illustré à
la Figure 1.
Figure 1 — Processus de gestion des risques
© ISO/IEC 2018 – Tous droits réservés 3

La Figure 2 illustre la manière dont le présent document applique ce processus de gestion des risques.
Le processus de gestion des risques en sécurité de l'information inclut l'établissement du contexte
(Article 7), l'appréciation des risques (Article 8), le traitement des risques (Article 9), l'acceptation des
risques (Article 10), la communication et la concertation relatives aux risques (Article 11), ainsi que la
surveillance et le réexamen des risques (Article 12).
Figure 2 — Illustration du processus de gestion des risques en sécurité de l'information
Comme l'illustre la Figure 2, le processus de gestion des risques en sécurité de l'information peut
être itératif pour les activités d'appréciation et/ou de traitement des risques. Une approche itérative
de conduite de l'appréciation des risques permet d'approfondir et de préciser l'appréciation à chaque
itération. Cette approche itérative assure un bon équilibre entre la minimisation du temps et des
efforts investis dans l'identification des mesures de sécurité et l'assurance que les risques élevés sont
correctement appréciés.
4 © ISO/IEC 2018 – Tous droits réservés

Le contexte est établi en premier lieu. Une appréciation des risques est ensuite réalisée. Si cette
appréciation donne suffisamment d'informations pour déterminer correctement les actions nécessaires
pour ramener les risques à un niveau acceptable, la tâche est alors terminée et suivie par le traitement
des risques. Si les informations ne sont pas suffisantes, une autre itération de l'appréciation des risques
est réalisée avec un contexte révisé (par exemple les critères d'évaluation du risque, les critères
d'acceptation des risques ou les critères d'impact) et, éventuellement, sur des parties limitées de
l'ensemble du domaine d'application (voir la Figure 2, point de décision relatif au risque n° 1).
L'efficacité du traitement des risques dépend des résultats de l'appréciation des risques.
Il est à noter que le traitement des risques implique un processus cyclique de:
— appréciation d'un traitement des risques;
— décision de reconnaître si les niveaux de risque résiduel sont acceptables;
— génération d’un nouveau traitement des risques si les niveaux de risque ne sont pas acceptables; et
— appréciation de l’efficacité du traitement considéré.
Il est possible que le traitement des risques ne donne pas immédiatement un niveau acceptable de
risque résiduel. Dans ce cas, une nouvelle itération de l'appréciation des risques utilisant, si nécessaire,
de nouveaux paramètres de contexte (à titre d'exemples l'appréciation des risques, l'acceptation des
risques ou les critères d'impact) peut être requise et suivie d'un autre traitement des risques (voir la
Figure 2, Point de décision relatif au risque n° 2).
L'activité d'acceptation des risques doit garantir que les risques résiduels sont explicitement acceptés
par les dirigeants de l'organisme. Elle est particulièrement importante dans une situation où la mise en
œuvre de mesures de sécurité est omise ou reportée, par exemple en raison des coûts.
Au cours de l’ensemble du processus de gestion des risques en sécurité de l'information, il est important
que les risques et leur traitement soient communiqués aux dirigeants et au personnel concerné. Avant
même le traitement des risques, les informations relatives aux risques identifiés peuvent être très
utiles pour gérer les incidents et contribuer à réduire les dommages potentiels. La sensibilisation des
dirigeants et du personnel aux risques, la nature des mesures de sécurité mises en place pour atténuer
les risques et les problèmes rencontrés par l'organisme sont utiles pour gérer les incidents et les
événements imprévus de la manière la plus efficace. Il convient de documenter les résultats détaillés de
toute activité du processus de gestion des risques en sécurité de l'information, ainsi que ceux obtenus à
partir des deux points de décision de risque.
L'ISO/IEC 27001 spécifie que les mesures de sécurité mises en œuvre dans le domaine d'application, les
limites et le contexte du SMSI doivent être fondées sur le risque. L'application d'un processus de gestion
des risques en sécurité de l'information peut répondre à cette exigence. De nombreuses approches
permettent de déterminer les mesures de sécurité pour mettre en œuvre les options choisies en matière
de traitement des risques.
Il convient que l’organisme établisse, mette en œuvre et tienne à jour des procédures pour identifier les
exigences légales applicables pour:
— la sélection des critères pour l’évaluation des risques (7.2.2), l’impact des risques (7.2.3) et
l’acceptation des risques (7.2.4);
— la définition du domaine d'application et des limites de la gestion des risques en sécurité de
l'information (7.3 et A.2);
— l'évaluation des risques (8.4);
— le traitement des risques (9.1) et la mise en œuvre de plans de réduction des risques (9.2 et Annexe F);
— la surveillance, la revue et l’amélioration de la gestion des risques (12.2);
— l’identification des actifs (B.1.3) et la valorisation des actifs (B.2.3); et
© ISO/IEC 2018 – Tous droits réservés 5

— l’estimation des risques (voir les exemples en E.2.1).
7 Établissement du contexte
7.1 Considérations générales
Éléments d'entrée: Toutes les informations relatives à l'organisme permettant l'établissement du
contexte de la gestion des risques en sécurité de l'information.
Action: Il convient d'établir le contexte externe et interne de la gestion des risques en sécurité de
l'information, ce qui implique de déterminer les critères de base nécessaires à la gestion des risques
en sécurité de l'information (7.2), de définir le domaine d'application et ses limites (7.3) et d'établir une
organisation adaptée au fonctionnement de la gestion des risques en sécurité de l'information (7.4).
Préconisations de mise en œuvre:
Il est essentiel de déterminer l'objectif de la gestion des risques en sécurité de l'information puisqu'il
influence l'ensemble du processus et, en particulier, l'établissement du contexte. L'objectif peut être:
— une réponse aux exigences d'un SMSI;
— la conformité avec la loi et la preuve de la mise en œuvre du devoir de précaution;
— la préparation d'un plan de continuité d'activité;
— la préparation d'un plan de réponse aux incidents; et
— la description des exigences en matière de sécurité de l'information pour un produit, un service ou
un mécanisme.
Les préconisations de mise en œuvre des éléments d'établissement du contexte nécessaires pour
répondre aux exigences d'un SMSI sont traitées en 7.2, 7.3 et 7.4.
Éléments de sortie: La spécification des critères de base, le domaine d'application et ses limites,
et l'organisation dédiée au fonctionnement du processus de gestion des risques en sécurité de
l'information.
7.2 Critères de base
7.2.1 Approche de gestion des risques
Selon le domaine d'application et les objectifs de la gestion des risques, différentes approches peuvent
s'appliquer. L'approche peut également être différente pour chaque itération.
Il convient de choisir ou d'élaborer une approche de gestion des risques adaptée qui inclue des critères
de base tels que les critères d'évaluation du risque, les critères d'impact et les critères d'acceptation des
risques.
En outre, il convient que l'organisme évalue si les ressources nécessaires sont disponibles pour:
— effectuer une appréciation des risques et établir un plan de traitement des risques;
— définir et mettre en œuvre des politiques et des procédures, y compris la mise en œuvre des mesures
de sécurité choisies;
— surveiller les mesures de sécurité; et
— surveiller le processus de gestion des risques en sécurité de l'information.
6 © ISO/IEC 2018 – Tous droits réservés

7.2.2 Critères d'évaluation du risque
Il convient d'élaborer des critères d'évaluation du risque afin d'évaluer le risque de l'organisme en
sécurité de l'information en prenant en compte les éléments suivants:
— la valeur stratégique des processus informationnels métier;
— la criticité des actifs informationnels concernés;
— l'importance opérationnelle et métier de la disponibilité, de la confidentialité et de l'intégrité;
— les attentes et les perceptions des parties prenantes ainsi que les conséquences négatives sur la
valorisation financière et la réputation de l'organisme.
En outre, les critères d'évaluation du risque peuvent être utilisés pour spécifier les priorités du
traitement des risques.
7.2.3 Critères d'impact
NOTE L’ISO 31000 utilise le concept de «critères de conséquences» au lieu de «critères d’impact».
Il convient que les critères d'impact soient élaborés et spécifiés en fonction du niveau de dommages ou
de coûts pour l'organisme pouvant être causés par un événement lié à la sécurité de l'information, en
tenant compte des points suivants:
— le niveau de classification de l'actif informationnel impacté;
— l'atteinte à la sécurité de l'information (par exemple, une perte de confidentialité, d'intégrité et de
disponibilité);
— les erreurs opérationnelles (équipes internes ou tierces parties);
— des pertes de marchés et de valeur financière;
— la perturbation des plans d'actions et des délais;
— les atteintes à la réputation.
7.2.4 Critères d'acceptation des risques
Il convient que les critères d'acceptation des risques soient élaborés et spécifiés. Ces critères dépendent
souvent des politiques, des intentions, des objectifs de l'organisme et des intérêts des parties prenantes.
Il convient que l'organisme définisse ses propres échelles pour les niveaux d'acceptation des risques. Il
y a lieu de prendre en compte les éléments suivants au moment de l'élaboration:
— les critères d'acceptation des risques peuvent inclure des seuils multiples correspondant à un niveau
de risque cible souhaité, tout en réservant aux cadres décisionnaires la possibilité d'accepter des
risques situés au-dessus de ce niveau dans certaines circonstances définies;
— les critères d'acceptation des risques peuvent être exprimés comme un rapport entre le profit estimé
(ou tout autre bénéfice métier) et le risque estimé;
— différents critères d'acceptation des risques peuvent s'appliquer à différents types de risques;
— les critères d'acceptation des risques peuvent inclure des exigences relatives à de futurs traitements
additionnels. Ainsi, il est possible d'accepter un risque s'il y a un engagement et une validation que des
mesures destinées à le réduire à un niveau acceptable, dans un délai défini, vont être mises en œuvre.
© ISO/IEC 2018 – Tous droits réservés 7

Les critères d'acceptation des risques peuvent varier selon la durée d'existence prévue du risque; il est,
par exemple, possible que le risque soit associé à une activité temporaire ou de courte durée. Il convient
de déterminer les critères d'acceptation des risques en tenant compte des points suivants:
— critères commerciaux;
— aspects opérationnels;
— aspects technologiques;
— aspects financiers;
— facteurs sociaux et humanitaires.
De plus amples informations sont données dans l'Annexe A.
7.3 Domaine d'application et limites
Il convient que l'organisme définisse le domaine d'application et les limites de la gestion des risques en
sécurité de l'information.
Il est nécessaire de définir le domaine d'application du processus de gestion des risques en sécurité
de l'information afin de garantir que tous les actifs concernés sont pris en compte dans l'appréciation
des risques. En outre, il est nécessaire d'identifier les limites afin de traiter les risques susceptibles de
survenir à travers elles.
Il convient de rassembler les informations relatives à l'organisme afin de déterminer l'environnement
dans lequel il intervient ainsi que son adéquation avec le processus de gestion des risques en sécurité
de l'information.
Lors de la définition du domaine d'application et des limites, il convient que l'organisme considère les
informations suivantes:
— les objectifs stratégiques commerciaux, les stratégies et les politiques de l'organisme;
— les processus métier;
— les fonctions et la structure de l'organisme;
— la politique de sécurité de l'information de l'organisme;
— l'approche globale de l'organisme vis-à-vis de la gestion des risques;
— les actifs informationnels;
— les localisations de l'organisme et leurs caractéristiques géographiques;
— les contraintes affectant l'organisme;
— les attentes des parties prenantes;
— l'environnement socioculturel;
— les interfaces (c'est-à-dire les échanges d'information avec l'environnement).
De plus, il convient que l'organisme justifie toute exclusion du domaine d'application.
Des exemples de domaine d'application de gestion des risques peuvent être une application ou une
infrastructure en technologie de l'information, un processus métier ou une partie définie d'un
organisme.
De plus amples informations sont données dans l'Annexe A.
8 © ISO/IEC 2018 – Tous droits réservés

7.4 Organisation de la gestion des risques en sécurité de l'information
Il convient de déterminer et de maintenir l'organisation et les responsabilités relatives au processus
de gestion des risques en sécurité de l'information. Les principaux rôles et responsabilités de cette
organisation sont les suivants:
— élaboration du processus de gestion des risques en sécurité de l'information adapté à l'organisme;
— identification et analyse des parties prenantes;
— définition des rôles et des responsabilités de toutes les parties, à la fois internes et externes à
l'organisme;
— établissement des relations entre l'organisme et les parties prenantes, des interfaces avec les
fonctions de gestion des risques de haut niveau de l'organisme (par exemple, gestion des risques
opérationnels) ainsi que des interfaces avec d'autres projets ou activités, si cela est pertinent;
— détermination des processus d'escalade;
— spécification des enregistrements à conserver.
Il convient que cette organisation soit approuvée par les dirigeants concernés au sein de l'organisme.
8 Appréciation des risques en sécurité de l'information
8.1 Description générale de l'appréciation des risques en sécurité de l'information
Éléments d’entrée: Critères de base, domaine d'application et limites, et organisation pour
l'établissement du processus de gestion des risques en sécurité de l'information.
Action: Il convient que les risques soient identifiés, quantifiés ou qualitativement décrits, et priorisés à
partir des critères d'évaluation du risque et des objectifs significatifs pour l'organisme.
Préconisations de mise en œuvre:
Un risque est la combinaison des conséquences qui découleraient de l'occurrence d'un événement
indésirable et de la probabilité d'occurrence de l'événement. L'appréciation des risques quantifie ou
décrit qualitativement le risque et permet aux dirigeants de classer les risques par ordre de priorité
selon leur gravité perçue ou en cohérence avec d'autres critères établis.
L'appréciation des risques inclut les activités suivantes:
— l'identification des risques (8.2);
— l'analyse des risques (8.3);
— l'évaluation des risques (8.4).
L'appréciation des risques détermine la valeur des actifs informationnels, identifie les menaces et
les vulnérabilités applicables existantes (ou susceptibles d'exister), identifie les mesures de sécurité
existantes et leurs effets sur le risque identifié, détermine les conséquences potentielles puis classe les
risques ainsi obtenus par ordre de priorité en cohérence avec les critères d'évaluation du risque définis
lors de l'établissement du contexte.
L'appréciation des risques est souvent réalisée en deux itérations (ou plus). Une appréciation de
haut niveau est d'abord effectuée afin d'identifier les risques potentiels majeurs qui justifient une
appréciation supplémentaire. L'itération suivante peut impliquer une étude détaillée des risques
potentiels majeurs mis en lumière par l'itération initiale. Lorsque cette démarche ne fournit pas
suffisamment d'informations pour apprécier les risques, d'autres analyses détaillées peuvent être
réalisées, probablement sur des sous-ensembles du domaine d'application et, éventuellement, à l'aide
d'une méthode différente.
© ISO/IEC 2018 – Tous droits réservés 9

Il incombe à l'organisme de choisir sa propre approche d'appréciation des risques en se basant sur les
objectifs et le but de l'appréciation des risques.
Une discussion des approches d'appréciation des risques en sécurité de l'information se trouve en
Annexe E.
Élément de sortie: Liste des risques appréciés classés par ordre de priorité en cohérence avec les
critères d'évaluation du risque.
8.2 Identification des risques
8.2.1 Introduction à l'identification des risques
L'objectif de l'identification des risques est de déterminer les événements susceptibles de se produire
causant une perte potentielle et de donner un aperçu de comment, où, et quand cette perte pourrait
survenir. Il convient que les étapes décrites dans les paragraphes suivants permettent de produire les
données d'entrée de l'activité d’analyse des risques.
Il convient que l’identification des risques inclue les risques dont la source est ou non sous le contrôle de
l’organisme, même si la source n’est peut-être pas évidente.
NOTE Les activités décrites dans les autres paragraphes peuvent être effectuées dans un ordre différent
selon la méthodologie appliquée.
8.2.2 Identification des actifs
Éléments d'entrée: Domaine d'application et limites de l'appréciation des risques à effectuer, liste des
composants avec les propriétaires, emplacement, fonction, etc.
Action: Il convient d'identifier les actifs relevant du domaine d'application établi.
Préconisations de mise en œuvre:
Un actif désigne tout élément ayant de la valeur pour l'organisme et nécessitant, par conséquent,
une protection. Concernant l'identification des actifs, il convient de garder à l'esprit qu'un système
d'information n’inclut pas uniquement du matériel et des logiciels.
Il convient de réaliser l'identification des actifs à un niveau de détail adapté qui fournisse suffisamment
d'informations pour l'appréciation des risques. Le niveau de détail utilisé pour l'identification des actifs
influence la quantité totale d'informations réunies pendant l'appréciation des risques. Le niveau peut
être affiné lors d'itérations ultérieures de l'appréciation des risques.
Il convient d'identifier un propriétaire pour chaque actif afin d'associer pour celui-ci une personne
responsable et redevable. Le propriétaire de l'actif ne jouit peut-être pas de droits de propriété sur l'actif
mais est responsable de sa production, de son développement, de sa maintenance, de son utilisation
et de sa protection selon le cas. Le propriétaire de l'actif est souvent la personne la plus à même de
déterminer la valeur qu'il représente pour l'organisme (voir 8.3.2 pour la valorisation des actifs).
Les limites de la revue sont le périmètre des actifs de l'organisme défini comme devant être géré par le
processus de gestion des risques en sécurité de l'information.
De plus amples informations quant à l'identification et à la valorisation des actifs liés à la sécurité de
l'information sont disponibles dans l'Annexe B.
Éléments de sortie: Liste des actifs dont les risques sont à gérer et liste des processus métier relatifs aux
actifs et leur pertinence.
10 © ISO/IEC 2018 – Tous droits réservés

8.2.3 Identification des menaces
Éléments d'entrée: Informations relatives aux menaces obtenues grâce à la revue des incidents, aux
propriétaires des actifs, aux utilisateurs et à d'autres sources, y compris des catalogues de menaces
externes.
Action: Il convient d'identifier les menaces et leurs sources.
Préconisations de mise en œuvre:
Une menace est susceptible d'endommager les actifs tels que des informations, des processus et des
systèmes et, par conséquent, des organismes. Les menaces peuvent être d'origine naturelle ou humaine
et peuvent être accidentelles ou délibérées. Il convient d'identifier les sources de menace à la fois
accidentelles et délibérées. Une menace peut survenir de l'intérieur ou de l'extérieur de l'organisme. Il
convient aussi d'identifier les menaces de manière générique et par type (à titre d'exemples: des actions
non autorisées, des dommages physiques, des défaillances techniques) puis, lorsque cela est pertinent,
des menaces individuelles particulières peuvent être identifiées au sein d'une classe générique. Cela
signifie qu'aucune menace n'est négligée, même une menace imprévue, mais que le volume de travail
requis reste limité.
Certaines menaces peuvent affecter plus d'un actif. Dans ce cas, elles peuvent avoir différentes
conséquences selon l'actif affecté.
Les éléments d'entrée de l'identification des menaces et de l'estimation de la vraisemblance (voir 8.3.3)
peuvent être obtenus auprès des propriétaires ou des utilisateurs d'actifs, auprès de l'équipe des
ressources humaines, auprès des services généraux et des experts en sécurité de l'information, des
experts en sécurité physique, du service juridique et d'autres organismes pertinents (y compris des
organismes juridiques), des services météorologiques, des compagnies d'assurance et des autorités
gouvernementales. Lors du traitement des menaces, il convient que les aspects relatifs à l'environnement
et à la culture soient également pris en compte.
Lors de la réalisation d'une appréciation, il convient de tenir compte de l'expérience obtenue en interne
à partir d'incidents et d'appréciations de menaces antérieures. Il peut s'avérer utile de consulter d'autres
catalogues de menaces (pouvant être spécifiques à un organisme ou à un secteur d'activité) afin de
compléter le cas échéant la liste de menaces gén
...