ISO-IECJTC1-SC27-WG1 N2154 Second Working Draft For ISOIEC 27005 Information Security Risk Management

ISO/IEC JTC 1/SC 27/WG 1 N 2154
ISO/IEC JTC 1/SC 27/WG 1

Information security management systems
Convenorship: BSI (United Kingdom)
Document type: Working Draft Text
Title: Second working draft for ISO/IEC 27005 Information security

risk management
Status: This document is circulated for information and action.

All WG1 expert comments shall be submitted via the WG
1 consultation
page https://isotc.iso.org/livelink/livelink/open/jtc1sc27wg1.
WG 1 expert comments are due by 28th Feb 2020.
Date of document: 2019-11-13
Source: Project Editors 27005 (ANDRUKIEWICZ Elzbieta: RUMPEL,

Rainer, KIKUCHI, Masato)
Expected action: COMM
Action due date: 2019-02-28
Email of convenor: edwardj7@msn.com
Committee URL: https://isotc.iso.org/livelink/livelink/open/jtc1sc27wg1

© ISO 2019– All rights reserved
1 ISO/IEC 27005:####(E)
2 ISO/IEC JTC1/SC 27/WG 1 N2154
3 Secretariat: DIN
4 Information security, cybersecurity and privacy protection —

5 Information security risk management
7 2nd Working Draft

8
9 Warning for WDs and CDs
10 This document is not an ISO International Standard. It is distributed for review and comment. It is subject to
11 change without notice and may not be referred to as an International Standard.
12 Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of
13 which they are aware and to provide supporting documentation.
14
15
16 © ISO 2019, Published in Switzerland
17 All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized
18 otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on the
19 internet or an intranet, without prior written permission. Permission can be requested from either ISO at the
20 address below or ISO’s member body in the country of the requester.
21 ISO copyright office

22 Ch. de Blandonnet 8 • CP 401
23 CH-1214 Vernier, Geneva, Switzerland
24 Tel. + 41 22 749 01 11
25 Fax + 41 22 749 09 47
26 copyright@iso.org
27 www.iso.org
28 Content
29 Foreword .................................................................................................................................................................. 3
30 Introduction ............................................................................................................................................................. 5
31 1 Scope .................................................................................................................................................................. 6
32 2 Normative references .................................................................................................................................... 6
33 3 Terms and definitions ................................................................................................................................... 6
34 3.1 Terms related to information security risk............................................................................................. 7
35 3.2 Terms related to information security risk management................................................................. 10
36 4 Structure of this document ........................................................................................................................ 12
37 5 Context establishment ................................................................................................................................. 12
38 5.1 Introduction ................................................................................................................................................... 12
39 5.2 Scope of the risk assessment and risk treatment ................................................................................ 13
40 5.3 Choosing an appropriate method............................................................................................................. 13
41 5.4 Organizational considerations .................................................................................................................. 13
42 5.5 Establishing and maintaining information security risk criteria ................................................... 14
43 5.5.1 Introduction ............................................................................................................................................. 14
44 5.5.2 Risk acceptance criteria ........................................................................................................................ 14
45 5.5.3 Criteria for performing information security risk assessments ............................................... 15
46 6 Risks and opportunities relating to the outcome(s) of the ISMS ..................................................... 18
47 7 Information security risk assessment process ..................................................................................... 19
48 7.1 Introduction ................................................................................................................................................... 19
49 7.2 Identifying information security risks.................................................................................................... 20
50 7.2.1 Risks associated with the loss of confidentiality, integrity and availability of
51 information .............................................................................................................................................. 20
52 7.2.2 Identifying risk owners ......................................................................................................................... 21
53 7.3 Analyzing information security risks ...................................................................................................... 22
54 7.3.1 Introduction ............................................................................................................................................. 22
55 7.3.2 Assessing potential consequences ..................................................................................................... 22
56 7.3.3 Assessing likelihood .............................................................................................................................. 23
57 7.3.4 Determining the levels of risk ............................................................................................................. 24
58 7.4 Evaluating the information security risks ............................................................................................. 24
59 7.4.1 Comparing the results of risk analysis with the risk criteria ..................................................... 24
60 7.4.2 Prioritizing the analysed risks for risk treatment ........................................................................ 25
61 8 Information security risk treatment process ....................................................................................... 26
62 8.1 Introduction ................................................................................................................................................... 26
63 8.2 Selecting appropriate information security risk treatment options ............................................. 26
© ISO 2019 – All rights reserved 1

ISO/IEC 27005:####(E)
64 8.3 Determining all controls that are necessary to implement the information security risk
65 treatment options ................................................................................................................................... 27
66 8.4 Comparing the controls determined with those in ISO 27001 Annex A ........................................ 29
67 8.5 Producing a Statement of Applicability .................................................................................................. 30
68 8.6 Information security risk treatment plan.............................................................................................. 31
69 8.6.1 Formulation of the risk treatment plan............................................................................................ 31
70 8.6.2 Approval by risk owners....................................................................................................................... 32
71 8.6.3 Acceptance of the residual information security risks ................................................................ 32
72 9 Operation ........................................................................................................................................................ 33
73 9.1 Performing information security risk assessment process .............................................................. 33
74 9.2 Performing information security risk treatment process................................................................. 33
75 10 Leveraging related ISMS processes.......................................................................................................... 33
76 10.1 Context of the organization (Clause 4) ............................................................................................. 33
77 10.2 Leadership and commitment (Clause 5.1) ....................................................................................... 34
78 10.3 Communication (Clause 7.4)................................................................................................................ 34
79 10.4 Documented information (Clause 7.5) ............................................................................................. 36
80 10.4.1 General ...................................................................................................................................................... 36
81 10.4.2 Documented information about processes ..................................................................................... 36
82 10.4.3 Documented information about results ........................................................................................... 36
83 10.5 Monitoring and measurement (Clause 9.1) ..................................................................................... 37
84 10.5.1 General ...................................................................................................................................................... 37
85 10.5.2 Monitoring and review of factors influencing risks ...................................................................... 37
86 10.6 Management review (Clause 9.3) ....................................................................................................... 38
87 10.7 Corrective action (Clause 10.1)........................................................................................................... 38
88 10.8 Continual improvement (Clause 10.2) .............................................................................................. 38
89 Annex A (informative) Information security risk cycle ............................................................................ 41
90 Annex B (informative) Information security risk criteria values - examples .................................... 43
91 B.1 Criteria related to risk assessment .......................................................................................................... 43
92 B.1.1 Quantitative approach .......................................................................................................................... 43
93 B.1.2 Qualitative approach ............................................................................................................................. 46
94 B.2 Risk acceptance criteria .............................................................................................................................. 47
95 Bibliography .......................................................................................................................................................... 48
96
97
2 © ISO #### – All rights reserved

98 Foreword
99 ISO (the International Organization for Standardization) is a worldwide federation of national
100 standards bodies (ISO member bodies). The work of preparing International Standards is normally
101 carried out through ISO technical committees. Each member body interested in a subject for which a
102 technical committee has been established has the right to be represented on that committee.
103 International organizations, governmental and non-governmental, in liaison with ISO, also take part in
104 the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all
105 matters of electrotechnical standardization.
106 The procedures used to develop this document and those intended for its further maintenance are
107 described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
108 different types of ISO documents should be noted. This document was drafted in accordance with the
109 editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
110 Attention is drawn to the possibility that some of the elements of this document may be the subject of
111 patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
112 any patent rights identified during the development of the document will be in the Introduction and/or
113 on the ISO list of patent declarations received (see www.iso.org/patents).
114 Any trade name used in this document is information given for the convenience of users and does not
115 constitute an endorsement.
116 For an explanation on the voluntary nature of standards, the meaning of ISO specific terms and
117 expressions related to conformity assessment, as well as information about ISO's adherence to the
118 World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see the following
119 URL: www.iso.org/iso/foreword.html.
120 This document was prepared by Joint Technical Committee 1 ISO/IEC JTC1 Information Technology,
121 Subcommittee SC 27, IT Security Techniques.
122 This fourth edition cancels and replaces the third edition (ISO/IEC 27005:2018), which has been
123 technically revised.
124 The main changes compared to the previous edition are as follows:
125 — xxx xxxxxxx xxx xxxx
126 A list of all parts in the ISO/IEC 27000 series can be found on the ISO website.
127
Editors’ Note:
The expert expresses the following concern:
“There seems to be a general assumption in this draft that the user of the standard will be at a level of
knowledge equivalent to that of the contributors to it. As a result, many critical topics are merely
mentioned in passing without any supporting explanation. The reality is that guidance standards are
widely used by less experienced practitioners, so we should try to ensure that 27005 can fulfil their
needs.”
Therefore, experts are requested to further contribute to provide explanation and justification
wherever statements such as "decision should be made", "appropriate", "taken into account" etc. are
made.

ISO/IEC 27005:####(E)
128
129
130
131
132
133
134
135
136
137
138
139
140
141

142 Introduction
143 This document provides guidance on:
144 - (primarily) implementation of the information security risk requirements defined in ISO/IEC
145 27001,
146 - information security risk management activities and the necessary references to complete these
147 activities within the 27000 family, and
148 - all actions which address risks and opportunities, related to information security (see ISO/IEC
149 27001, clauses 6.1 and 8).
150 This document is fully aligned with ISO/IEC 27001:2013 and provides an explanation of the
151 requirements for dealing with ISO/IEC 27001:2013, Annex A controls.
152 The intended recipients of this document are:
153 - organizations who intend to establish an ISMS that aligns at ISO/IEC 27001 or an ISMS
154 compliant with ISO/IEC 27001,
155 - persons that perform or are involved in information security risk management (e.g. ISMS
156 professionals, risk owners, and other interested parties), and
157 - organizations intending to improve their information security risk management process.
Editors’ Note: Experts are requested to further contribute to this Clause, in particular to the following:
- how the standard relates to the previous edition (ISO/IEC 27005:2018);

- how it relates to other members of the ISO/IEC 27xxx family of standards and other
management standards;
- why and in what way the standard is interrelated to ISO 31000; and
- (possibly) simplified approach to usage of this document by SMEs.

ISO/IEC 27005:####(E)
158
159 Information security, cybersecurity and privacy protection —

160 information security risk management
161 1 Scope
162 This document provides guidance to assist organizations to:
163 - fulfil the requirements of ISO/IEC 27001 concerning actions to address risks and opportunities,
164 specifically to perform information security risk assessment and treatment, and
165 - perform information security risk management activities.
166 This document is applicable to all organizations, regardless of type, size or nature.
167 2 Normative references

168 The following documents are referred to in the text in such a way that some or all of their content
169 constitutes requirements of this document. For dated references, only the edition cited applies. For
170 undated references, the latest edition of the referenced document (including any amendments) applies.
171 ISO/IEC 27000, Information Technology — IT Security Techniques – Information Security Management
172 Systems – Overview and Vocabulary
173 3 Terms and definitions

174 For the purposes of this document, the terms and definitions given in ISO/IEC 27000 and the following
175 apply.
176 ISO and IEC maintain terminological databases for use in standardization at the following addresses:
177 — IEC Electropedia: available at http://www.electropedia.org/
178 — ISO Online browsing platform: available at https://www.iso.org/obp
Editors’ Notes:
1. By the decision of editing group all terms from ISO/IEC 27000:2018 related to the
(information security) risk have been re-introduced in this document to work on them
according to the Design Specification.
2. Simultaneously, according to ISO/IEC Directives 2018 Annex SP 5.5, all terms and
definitions shall follow ISO 31000. For that reason all relevant definitions in this document
are taken from ISO 31000 and can differ from these from ISO/IEC 27000:2018.
3. Terms in ISO 31000:2018 are presented in systematic order. A concept presented below
follows the one from ISO 31000 or several definitions could be helpful to understand the
whole concept.
4. Examples for several terms and their definitions are considered to be useful for the readers.
Experts are requested to comment on the Clause 3 content with respect to the above mentioned
principles.

179 3.1 Terms related to information security risk
180 3.1.1
181 risk
182 effect of uncertainty on objectives
183 Note 1 to entry: An effect is a deviation from the expected. It can be positive, negative or both, and can address,
184 create or result in opportunities and threats.
185 Note 2 to entry: Objectives can have different aspects and categories, and can be applied at different levels.
186 Note 3 to entry: Risk is usually expressed in terms of risk sources (3.1.2), potential events (3.1.3), their
187 consequences (3.1.4) and their likelihood (3.1.7).
188 [SOURCE: ISO 31000:2018]
Editors’ Note: Notes from ISO/IEC 27000:2018 are listed below. These can be merged with the notes which
accompany the definition form ISO 31000.
189 Note 1 to entry: An effect is a deviation from the expected — positive or negative.
190 Note 2 to entry: Uncertainty is the state, even partial, of deficiency of information related to, understanding or
191 knowledge of, an event, its consequence, or likelihood.
192 Note 3 to entry: Risk is often characterized by reference to potential events (3.1.3) and consequences (3.1.4), or a
193 combination of these.
194 Note 4 to entry: Risk is often expressed in terms of a combination of the consequences of an event (including
195 changes in circumstances) and the associated likelihood (3.1.7) of occurrence.
196 Note 5 to entry: In the context of information security management systems, information security risks can be
197 expressed as effect of uncertainty on information security objectives.
198 Note 6 to entry: Information security risk is associated with the potential that threats will exploit vulnerabilities of
199 an information asset or group of information assets and thereby cause harm to an organization.
Editors’ Note: The expert attention is drawn to the definition of ‘risk’ taken from current ISO/IEC Directives, Part
1, Consolidated ISO Supplement, 2018, Annex SL, Appendix 2 with the following:
3.9
risk
effect of uncertainty
Note 1 to entry: An effect is a deviation from the expected — positive or negative.
Note 2 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 3 to entry: Risk is often characterized by reference to potential “events” (as defined in ISO Guide 73:2009,
3.5.1.3) and “consequences” (as defined in ISO Guide 73:2009, 3.6.1.3), or a combination of these.
Note 4 to entry: Risk is often expressed in terms of a combination of the consequences of an event (including
changes in circumstances) and the associated “likelihood” (as defined in ISO Guide 73:2009, 3.6.1.1) of occurrence.
Difference in definitions between Annex SL and Annex SP of the same Directives should be solve at the ISO/CS
level.
200 3.1.2
201 risk source
202 element which alone or in combination has the potential to give rise to risk
203 [SOURCE: ISO 31000:2018]
204 3.1.3

ISO/IEC 27005:####(E)
205 event
206 occurrence or change of a particular set of circumstances
207 Note 1 to entry: An event can have one or more occurrences, and can have several causes and several
208 consequences (3.1.4).
209 Note 2 to entry: An event can also be something that is expected which does not happen, or something that is not
210 expected which does happen.
211 Note 3 to entry: An event can be a risk source.
212 [SOURCE: ISO 31000:2018]
Editors’ Note: ISO 31000:2018 uses one term ‘consequences’ throughout the text to describe possible
effects related to the risk there is proposal to keep to this concept and use a word ‘impact’ in its
common dictionary meaning.
213 3.1.4
214 consequence
215 outcome of an event (3.1.3) affecting objectives
216 Note 1 to entry: A consequence can be certain or uncertain and can have positive or negative direct or indirect
217 effects on objectives.
218 Note 2 to entry: Consequences can be expressed qualitatively or quantitatively.
219 Note 3 to entry: Any consequence can escalate through cascading and cumulative effects.
220 [SOURCE: ISO 31000:2018]
221 3.1.5
222 threat
223 potential cause of an unwanted incident, which can result in harm to a system or organization
224 3.1.6
225 vulnerability
226 weakness of an asset or control (3.1.12) that can be exploited by one or more threats (3.1.5)
227 3.1.7
228 likelihood
229 chance of something happening
230 Note 1 to entry: In risk management terminology, the word “likelihood” is used to refer to the chance of
231 something happening, whether defined, measured or determined objectively or subjectively, qualitatively or
232 quantitatively, and described using general terms or mathematically (such as a probability or a frequency over a
233 given time period).
234 Note 2 to entry: The English term “likelihood” does not have a direct equivalent in some languages; instead, the
235 equivalent of the term “probability” is often used. However, in English, “probability” is often narrowly interpreted
236 as a mathematical term. Therefore, in risk management terminology, “likelihood” is used with the intent that it
237 should have the same broad interpretation as the term “probability” has in many languages other than English.
238 [SOURCE: ISO 31000:2018]
239 3.1.8
240 level of risk
241 magnitude of a risk (3.1.1) expressed in terms of the combination of consequences (3.1.4) and their
242 likelihoods (3.1.7)

243 [SOURCE: ISO Guide 73:2009, 3.6.1.8, modified — “or combination of risks” has been deleted in the
244 definition.]
245
246 3.1.9
247 risk criteria
248 terms of reference against which the significance of risk (3.1.1) is evaluated
249 Note 1 to entry: Risk criteria are based on organizational objectives, and external context (3.1.10) and internal
250 context (3.1.11).
251 Note 2 to entry: Risk criteria can be derived from standards, laws, policies and other requirements.
252 [SOURCE: ISO Guide 73:2009, 3.3.1.3]
253 3.1.10
254 external context
255 external environment in which the organization seeks to achieve its objectives
256 Note 1 to entry: External context can include the following:
257 — the cultural, social, political, legal, regulatory, financial, technological, economic, natural and competitive
258 environment, whether international, national, regional or local;
259 — key drivers and trends having impact on the objectives of the organization;
260 — relationships with, and perceptions and values of, external interested parties.
261 [SOURCE: ISO Guide 73:2009, 3.3.1.1, modified — ‘interested party’ is used instead of ‘stakeholder’ in
262 Note 1 to entry]
263 3.1.11
264 internal context
265 internal environment in which the organization seeks to achieve its objectives
266 Note 1 to entry: Internal context can include:
267 — governance, organizational structure, roles and accountabilities;
268 — policies, objectives, and the strategies that are in place to achieve them;
269 — the capabilities, understood in terms of resources and knowledge (e.g. capital, time, people, processes, systems
270 and technologies);
271 — information systems, information flows and decision-making processes (both formal and informal);
272 — relationships with, and perceptions and values of, internal interested parties;
273 — the organization's culture;
274 — standards, guidelines and models adopted by the organization;
275 — form and extent of contractual relationships.
276 [SOURCE: ISO Guide 73:2009, 3.3.1.2, modified — ‘interested party’ is used instead of ‘stakeholder’ in
278 3.1.12
279 control
280 measure that maintains and/or modifies risk (3.1.1)
281 Note 1 to entry: Controls include, but are not limited to, any process, policy, device, practice, or other conditions
282 and/or actions which maintain and/or modify risk.

ISO/IEC 27005:####(E)
283 Note 2 to entry: Controls may not always exert the intended or assumed modifying effect.
284 [SOURCE: ISO 31000:2018]
285 3.1.13
286 residual risk
287 risk (3.1.1) remaining after risk treatment (3.2.6)

288 Note 1 to entry: Residual risk can contain unidentified risk.
289 Note 2 to entry: Residual risk can also be referred to as “retained risk”.
290 3.1.14
291 risk owner
292 person or entity with the accountability and authority to manage a risk (3.1.1)
293 [SOURCE: ISO Guide 73:2009, 3.5.1.5]
294
295 3.2 Terms related to information security risk management
296 3.2.1
297 risk management process
298 systematic application of management policies, procedures and practices to the activities of
299 communicating, consulting, establishing the context and identifying, analysing, evaluating, treating,
300 monitoring and reviewing risk (3.1.1)
301 [SOURCE: ISO Guide 73:2009, 3.1]
302 3.2.2
303 risk assessment
304 overall process of risk identification (3.2.3), risk analysis (3.2.4) and risk evaluation (3.2.5)
305 [SOURCE: ISO Guide 73:2009, 3.4.1]
306 3.2.3
307 risk identification
308 process of finding, recognizing and describing risks (3.1.1)
309 Note 1 to entry: Risk identification involves the identification of risk sources, events (3.1.3), their causes and their
310 potential consequences (3.1.4).
311 Note 2 to entry: Risk identification can involve historical data, theoretical analysis, informed and expert opinions,
312 and interested parties’ needs.
313 [SOURCE: ISO Guide 73:2009, 3.5.1, modified — ‘interested party’ is used instead of ‘stakeholder’ in
315 3.2.4
316 risk analysis
317 process to comprehend the nature of risk (3.1.1) and to determine the level of risk (3.1.8)
318 Note 1 to entry: Risk analysis provides the basis for risk evaluation (3.2.5) and decisions about risk treatment
319 (3.2.6).
320 Note 2 to entry: Risk analysis includes risk estimation.
321 [SOURCE: ISO Guide 73:2009, 3.6.1]

322 3.2.5
323 risk evaluation
324 process of comparing the results of risk analysis (3.2.4) with risk criteria (3.1.9) to determine whether
325 the risk (x) and/or its magnitude is acceptable or tolerable
326 Note 1 to entry: Risk evaluation assists in the decision about risk treatment (3.2.6).
327 [SOURCE: ISO Guide 73:2009, 3.7.1]

328 3.2.6
329 risk treatment
330 process to modify risk (3.1.1)
331 Note 1 to entry: Risk treatment can involve:
332 — avoiding the risk by deciding not to start or continue with the activity that gives rise to the risk;
333 — taking or increasing risk in order to pursue an opportunity;
334 — removing the risk source;
335 — changing the likelihood (3.1.7);
336 — changing the consequences (3.1.4);
337 — sharing the risk with another party or parties (including contracts and risk financing);
338 — retaining the risk by informed choice.
339 Note 2 to entry: Risk treatments that deal with negative consequences are sometimes referred to as “risk
340 mitigation”, “risk elimination”, “risk prevention” and “risk reduction”.
341 Note 3 to entry: Risk treatment can create new risks or modify existing risks.
342 [SOURCE: ISO Guide 73:2009, 3.8.1, modified — “decision” has been replaced by “choice” in Note 1 to
343 entry.]
Editors’ Note:
The change in definition 3.2.7 is based on ISO 31000:2018 (see Note 1 to the ‘risk treatment’ definition
above)
344 3.2.7
345 risk acceptance
346 informed decision to retain a particular risk (3.1.1)
347 Note 1 to entry: Risk acceptance can occur without risk treatment (3.2.6) or during the process of risk treatment.
348 Note 2 to entry: Accepted risks are subject to monitoring and review.
349 [SOURCE: ISO Guide 73:2009, 3.7.1.6, modified — “take” has been replaced by “retain” ]
350 3.2.8
351 risk communication and consultation
352 set of continual and iterative processes that an organization conducts to provide, share or obtain
353 information, and to engage in dialogue with interested parties regarding the management of risk (3.1.1)
354 Note 1 to entry: The information can relate to the existence, nature, form, likelihood (3.1.7), significance,
355 evaluation, acceptability and treatment of risk.
356 Note 2 to entry: Consultation is a two-way process of informed communication between an organization and its
357 interested parties on an issue prior to making a decision or determining a direction on that issue. Consultation is
358 — a process which impacts on a decision through influence rather than power; and
359 — an input to decision making, not joint decision making.

ISO/IEC 27005:####(E)
360 4 Structure of this document
[Editors’ Note 1: Editors’ suggest to provide more text at later stage when the structure and partly
content are more mature]
[Editors’ Note 2: It has been agreed to adopt an unified way of providing descriptions of risk activities,
starting from chapter 8, similar to the one used in ISO/IEC 27005:2018. Experts are encouraged to
provide such descriptions, where relevant.]
361 All risk management activities as presented from Clause 7 to Clause 10 are structured as follows:
362 Input: Identifies any required information to perform the activity.
363 Action: Describes the activity.
[Editors’ Note: After lengthy discussion the editing group has decided to continue work on structured
description of relevant information security risk activities using ‘trigger criteria’ item. As for the
beginning it has been decided to re-introduce the concept abandoned during previous revision:
“It should be possible to provide additional guidance regarding when an activity should be started
(triggered). This allow the various activities to be started only when there is an actual need for them, and
to specify this need. For example, in a scope and context where nothing much changes, starting a risk
assessment may be done at fixed intervals (say: each year). However, in a scope and context where changes
occur frequently and have to be catered for, risk assessments may need to start whenever such a change
occurs, or by other criteria that the organization may want to set “
Experts are invited to further contribute to this item of process description]
364 Trigger: Provides guidance on when to start the action.
365 Output: Identifies any information derived after performing the activity, as well as any criteria that such
366 output should satisfy.
367 Guidance: Provides guidance on performing the action, keyword and key concept.
368 5 Context establishment
369 5.1 Introduction
370 Typically, organisation’s business objectives include increase of the organisation’s value. Organisations
371 identify opportunities and exploit them to meet their business objectives. However, such exploitation is
372 accompanied by risks that affect the achievement of their business objectives.
373 According to ISO/IEC 27001 Clause 6.1.1 a), an organization should consider the risks and
374 opportunities relevant to the intended outcome(s) of the ISMS as a whole. ISMS scope definition, top
375 management's commitment to information security and resources to operate the ISMS are correlated to
376 "information security”. Opportunities of this category can be opportunities relating to the outcome(s) of
377 the ISMS, the commercial value of an ISMS, the efficiency of operating ISMS processes and information
378 security controls, etc. The risks that are to be considered to meet the requirements of clause 6.1.1
379 include risks associated with information security. However, clause 6.1.1 also allows for consideration
380 of risks to intended outcomes that are not directly associated with information security. Clause 6.1.2
381 provides a focus on risks directly associated with information security.
382 According to ISO/IEC 27001 Clauses 6.1.2, an organization should consider the information security
383 risks. The process of assessing and treating information security risks should be applied to risks

384 associated with the loss of confidentiality, integrity and availability for information within the scope of
385 the information security management system.
386 5.2 Scope of the risk assessment and risk treatment
387 The risk assessment and risk treatment activities are performed with regards to the context of the ISMS.
388 The context depends on the reason why they are conducted:
Editors’ Note:
Experts are requested to further contribute to the following list due to the expert proposal to consider
revising the list to encompass business risk rather than merely maintenance of the ISMS.
389
390 - to analyse a new asset to be incorporated in the scope of the ISMS;

391 - to analyse the impact of the proposed removal from the ISMS scope;
392 - to analyse the impact of the change or replacement of an asset within the scope of the ISMS;
393 - to analyse the risks opened by a failure of information within scope of the ISMS to comply with
394 its security configuration.
395 Organizations can perform risk assessments embedded within many different processes such as IT
396 project management, vulnerability management, incident management, problem management, or even
397 ad hoc on a given management identified precise topic. When combined together, the whole generally
398 addresses all the information within the scope of the ISMS.
399 If there is anything within the scope of the information security risk assessment that is outside the
400 scope of the ISMS, then either that something should be excluded from the risk assessment, or the scope
401 of the ISMS should be expanded to include it. This can happen if a risk source has been identified as a
402 result of the risk identification process that was not known about when the scope of the ISMS was
403 defined.
404 5.3 Choosing an appropriate method
405 In general, the information security risk management approach and methods should be aligned with the
406 approach and methods used to manage the other risks of the organization.
407 The chosen approach should be documented and preferably chosen among consolidated and public
408 methodologies, being subject to the experts’ community scrutiny.
409 According to ISO/IEC 27001 Clause 6.1.2 b), an organization should ensure that repeated information
410 security risk assessments produce consistent, valid and comparable results. It means the chosen
411 method should ensure the following properties of results:
412 ¾ consistency: assessments of the same risks performed by different persons, or by the same
413 persons on different occasions, in the same context should produce the same results;
414 ¾ comparability: scales should be defined for risk assessment criteria so that assessments
415 performed for different classes of risk produce results that can be related to each other;
416 ¾ validity: assessments should produce the results that accord as closely as possible with reality.
417 5.4 Organizational considerations
418 ISO/IEC 27000:2018, 3.50 defines an organization as “person or group of people that has its own
419 functions with responsibilities, authorities and relationships to achieve its objectives”. An organization
420 is not necessarily a company, other corporate body or legal entity, it can also be a subset of a legal entity
421 (e.g. the IT department of a company, a staff unit), and can be considered as the ‘organization’ within
422 the context of ISMS.

ISO/IEC 27005:####(E)
423 It is important to sense that risk tolerance, expressed by determining levels of acceptable risks, can and
424 may vary considerably from organization to organization. For instance, factors affecting an
425 organization’s risk tolerance are size, complexity, sector and risk appetite, i.e. level and type of risk that
426 an organization is willing to pursue or retain. Risk tolerance should be governed by the management of
427 the organization.
428 The organization should ensure that the role of the risk owner is determined for the information
429 security risk management activities. Risk owners should get appropriate authority and responsibility
430 for managing identified risks.
431 5.5 Establishing and maintaining information security risk criteria
432 5.5.1 Introduction
433 ISO/IEC 27001 Clause 6.1.2 a) requires organizations to define their risk criteria, i.e. the terms of
434 reference by which they evaluate the significance of the risks that they identify and thus make decisions
435 concerning risks.
436 ISO/IEC 27001 specifically requires an organization to define the criteria which it intends to use to:
437 a) determine the acceptability of a risk; and
438 b) when risk assessments are to be performed.
439 In general, to set risk criteria, the following should be considered:

440 — the nature and type of uncertainties that can affect outcomes and objectives (both tangible and
441 intangible);
442 — how consequence (both positive and negative) and likelihood will be defined, predicted and
443 measured;
444 — time-related factors;
445 — consistency in the use of measurements;

446 — how the level of risk is to be determined;
447 — how combinations and sequences of multiple risks will be taken into account;
448 — the organization’s capacity.
449 Further considerations on risk criteria can be found in Annex B.
450 5.5.2 Risk acceptance criteria
451 In risk evaluation, risk acceptance criteria are used to determine whether a risk is acceptable or not.
452 In risk treatment, risk acceptance criteria are used to determine whether the proposed risk treatment is
453 sufficient to reach an acceptable level of risk.
454 In management review, risk acceptance criteria are used to review whether residual risks meet risk
455 acceptance criteria.
456 An organization should define its own scales for levels of risk acceptance. The following should be
457 considered during development:
458 a) the level of management with delegated authority to make risk acceptance decisions;

459 b) risk acceptance criteria can include multiple thresholds, with a desired target level of risk, and only
460 the determined level of management should retain risks above this level;
461 c) risk acceptance criteria can be expressed by a threshold for
462 o the product of estimated extent of consequences and estimated likelihood of the event
463 or
464 o the ratio of estimated profit (or other business benefit) to the estimated loss expectancy;
465 d) different risk acceptance criteria can apply to different classes of risk, e.g. risks that could result in
466 non-compliance with regulations or laws may not be retained, while acceptance of high risks can be
467 allowed if the acceptance is a result of a contractual requirement;
468 e) risk acceptance criteria may include requirements for future additional treatment, e.g. a risk could
469 be retained on a short term basis even the level of risk exceeds the risk acceptance criteria if there is
470 approval and commitment to take action to implement a chosen set of controls to reach an
471 acceptable level within a defined time period;
472 f) risk acceptance criteria should be defined based upon the risk appetite that indicates amount and
473 type of risk that organization is willing to pursue or retain; and
474 g) risk acceptance criteria may be absolute or conditional depending on the context.
475 Risk acceptance criteria should be set up considering the following influencing factors:
476 h) business objectives;

477 i) business opportunities;
478 j) legal and regulatory aspects;
479 k) operational activities;
480 l) technological constraints;
481 m) financial constrains;
482 n) processes;
483 o) supplier relationships; and
484 p) human factors.
485 However, a simple acceptance criterion (yes/no) does not always suffice in practice.
486 In many cases, decision to retain risk can be made at specific levels of risk (specific combinations of
487 likelihood and consequence), but there may be circumstances where it is necessary to set thresholds of
488 acceptability for extreme consequences regardless of their likelihood or extremely high likelihoods
489 regardless of consequences where the effect on the organization primarily results from one or other.
490 For example, acceptance of a rare event that wipes out the stock value of a company or a constant drain
491 on resources resulting from the need to control frequent minor infractions of a policy should be
492 considered primarily on the basis of which of the two factors have the dominant effect on the
493 organization.
494 An organization can set a lower threshold for acceptability of risk with a large risk appetite, and may
495 adopt criteria that allow acceptance of more risk than an organization with a low risk appetite. This
496 protects the organization from over‑control, i.e. having so many information security controls that they
497 frustrate the ability of the organization to achieve its objectives.
498
499 Risk acceptance criteria can differ according to how long the risk is expected to exist, e.g. the risk can be
500 associated with a temporary or short‑term activity.
501 The risk acceptance criteria should be approved by the responsible management.
502 5.5.3 Criteria for performing information security risk assessments
503 5.5.3.1 Introduction
504 Risk assessment criteria specify how the significance of an assessed risk is described in terms of
505 consequences, likelihood, and level of risk.

ISO/IEC 27005:####(E)
506 The information security risk criteria should be established considering the context of the organization
507 and should be defined in accordance with top management’s risk preferences and risk perceptions on
508 one hand and should allow for a feasible and appropriate risk management process on the other hand.
509 Risk assessment criteria, or a formal basis for defining them, should be standardized across the
510 organization for all types of risk assessment. This facilitates the communication, comparison and
511 aggregation of risks across the organization.
512 Risk assessment criteria should be developed and specified in terms of the necessity of treating them,
513 considering the following:
514 a) sensitivity of information and how long it remains sensitive;

515 b) the quantity and any concentration of, information;
516 c) the strategic value of the business processes that make use of the information;
517 d) the criticality of the information and assets related to information involved;
518 e) operational and business importance of availability, confidentiality and integrity; and
519 f) the expectations and perceptions of interested parties, and negative consequences such as loss of
520 goodwill and reputation.
521 Usually, information security risk assessment criteria include:
522 - Criteria concerning consequences;

523 - Likelihood criteria; and
524 - Criteria for determining level of risk.
525 5.5.3.2 Consequence criteria
526 Consequence criteria should be developed and specified in terms of the extent of damage or loss or gain.
527 When defining them, there should be considered especially the following:
528 a) loss of life or harm to individuals or groups;

529 b) loss of freedom, dignity or right to privacy;
530 c) loss of staff and intellectual capital (skills and expertise);
531 d) impaired internal or third party operations, e.g. damage to a business function or process
532 e) effects to plans and deadlines;
533 f) loss of business and financial value;
534 g) loss of business advantage or market share;
535 h) damage to public trust or reputation;
536 i) breaches of legal, regulatory or statutory requirements;
537 j) breaches of contracts or service levels; and
538 k) consequences to interested parties.
539 Consequence criteria define how an organization will categorize the significance of potential
540 information security events to the organization. It is necessary to determine how many categories of
541 consequence will be used, what the categories will be called, and what consequences are associated
542 with each category. Consequence criteria will be different for different organizations depending on its
543 internal and external context. For example, realistic lower and upper limits of an organization's
544 consequence scale expressed in monetary terms could be the maximum amount the organization is
545 prepared to write off in a fiscal year and the minimum amount in the same period that would force it
546 into liquidation. This context-dependent range would then be divided into several consequence
547 categories, the number and distribution of which would depend on the risk perception and appetite of
548 the organization. Monetary consequence scales are commonly expressed in decades or powers of ten:
549 e.g. 100-1000, 1000-10,000 and so on, but alternative quantization schemes may be used where they fit
550 the organization's context better.

551 If different scales are used, for example to distinguish effects on people from effects on business process
552 delivery, it is prudent to be able to equate the points on one scale with those on the other. Financial loss
553 is a commonly used means to achieve this. For example, a breach of data protection legislation can
554 result in a substantial fine, additional work (and therefore unanticipated labour costs) and a significant
555 loss of revenue due to customers taking their business elsewhere. Indeed, the cost of information
556 security breaches is often expressed in terms of monetary loss.
557 Because consequences in different domains or departments of an organization may initially be

558 expressed in various different ways rather than directly in monetary terms, it is essential that these
559 various expressions can be cross-referenced to a common (typically monetary) anchoring scale to
560 ensure that equivalent levels of consequence in the different domains are correctly correlated with each
561 other.
562 The "levels" of consequences range from information loss, loss of information-related assets and
563 information process, to the impact on operational business goals and projected business losses. The
564 high-level consequences remain generally constant with the time and are usually not affected by the
565 controls. The low-level consequences (operational or tactical) are the ones the risk owner will easily
566 perceive and measure. By reducing such consequences, the chance that the event hits business
567 processes and its objectives is reduced. By stopping negative effects of the event at low level, the high-
568 level consequences will never materialize and the stakes will remain untouched. This is a part of wider
569 concept of risk cycle - see Annex B for details.
570 5.5.3.3 Likelihood criteria
571 Likelihood criteria should generally be developed taking into account how likely anticipated
572 information security events can be. Determining criteria will depend on aspects such as:
573 a) the probability of occurrence of accidental or natural events e.g. force majeure events;
574 b) the degree of exposure of relevant information or the asset related to information to the threat;
575 c) the degree of vulnerability of the organization;
576 d) technology failure; and
577 e) human misbehaviour or omissions.
578 Likelihood criteria define how an organization will categorize the frequency of information security
579 events. Likelihoods can be expressed in probabilistic terms (the chance that an event will occur in a
580 given time frame) or in frequentist terms (the notional average number of occurrences in a given time
581 frame). The frequentist representation is often easier to communicate but only the probabilistic
582 representation can be used when aggregating likelihoods.
583 Estimation of likelihood is intrinsically uncertain, not only because it considers things that have not yet
584 happened and are therefore not fully known, but also because likelihood is a statistical measure and is
585 thus not directly representative of individual events. The three basic sources of assessment uncertainty
586 are:
587 - personal uncertainty originating in the judgement of the assessor, which derives from
588 variability in the mental heuristics of decision making;
589 - methodological uncertainty, which derives from the use of tools that inevitably model events
590 simplistically; and
591 - systemic uncertainty about the anticipated event itself, which derives from insufficient
592 knowledge (in particular, if evidence is limited or a risk source changes with time).
593 To be effective, the criteria should span and segregate the expected range of frequencies so that
594 differences can be identified. The range of likelihood categories should be capable of being applied
595 to events that are almost inevitable as well as those that are expected to occur infrequently (e.g.
596 logarithmic scale). Similarly, likelihood criteria will depend on whether the anticipated rate of
597 occurrence of events is widely variable or relatively predictable within a narrow range.

ISO/IEC 27005:####(E)
598 5.5.3.4 Criteria for determining the level of risk
599 The purpose of levels of risk is to facilitate risk owners to decide about retaining or otherwise treating
600 risks and if necessary to prioritize for risk treatment. The assessed level of particular risk should help
601 the organization to determine the urgency for addressing that risk.
602 Depending on the situation, the inherent level of risk (without considering any controls), or the current
603 level of risk (allowing for the effectiveness of any controls already implemented) should be considered.
604 The organization should develop a risk ranking, taking into account the following:
605 a) The consequence criteria and likelihood criteria should be taken into account when determining the
606 level of risk;
607 b) the worst case impact that information security events may have on strategic, tactical and
608 operational levels; and
609 c) legal and regulatory requirements, and contractual obligations.
610 Criteria for the level of risk are required so that analysed risks are ready for evaluation.
611 Criteria for levels of risk can be qualitative (e.g. Extreme, High, Medium, Low) or quantitative (e.g. in
612 terms of monetary value, loss of lives, market share) in nature.
613 Whether quantitative or qualitative criteria are used, evaluation scales should ultimately be anchored to
614 a quantitative reference scale that is understood by all interested parties, and both risk assessment and
615 risk evaluation should include at least periodic formal calibration against the quantitative scale to
616 ensure validity, consistency and comparability of results.
617 If qualitative approach is used, the levels of any qualitative scale should be unambiguous, its increments
618 should be clearly defined, the qualitative descriptions for each level should be expressed in objective
619 language and the levels should not overlap. Furthermore, if multiple qualitative criterion sets are used
620 in parallel, e.g. to address risks in different business domains, the qualitative expressions at each
621 equivalent level on all scales should correspond to the same qualitative level.
622 6 Risks and opportunities relating to the outcome(s) of the ISMS

623 An organization intending to implement an ISMS should clearly and precisely analyse its situation in
624 terms of current strengths, opportunities, weaknesses and threats and compare this status against the
625 one expected after the complete implementation. Strengths should be exploited and enhanced and
626 opportunities taken, while weaknesses and threats should be reduced and countered.
627 Threats are uncertainties which can make it more difficult to achieve objectives and opportunities are
628 uncertainties that make it easier to achieve objectives.
629 An example of threat that make it more difficult to achieve objectives of ISMS is the possibility that
630 considerably low risk acceptance criteria defined based on unnecessary risk adverse attitude of the
631 organization might lead to the implementation of overly strict information security and decrease the
632 organisation’s value. It is a risk relevant to the intended outcome(s) of the ISMS.
633 An example of opportunity that makes it easier to achieve objectives of ISMS is the possibility that
634 implementation of organization-wide information security can increase customer’s trust and the
635 organisation value. It is an opportunity relevant to the intended outcome(s) of the ISMS.
636 The structure of ISO/IEC 27001 subdivides risks and opportunities into two categories during planning:
637 a) risks and opportunities relevant to the intended outcome(s) of the ISMS as a whole; and
638 b) information security risks that relate to the loss of confidentiality, integrity and availability of
639 information within the scope of the ISMS.

640 The first category should be handled in accordance with requirements specified in ISO/IEC 27001:2013,
641 subclause 6.1.1 (General). Risks that fall into this category can be risks relating to the ISMS itself, the
642 ISMS scope definition, top management’s commitment to information security, resources for operating
643 the ISMS, etc. Opportunities that fall into this category can be opportunities relating to the outcome(s)
644 of the ISMS, the commercial value of an ISMS, the efficiency of operating ISMS processes and
645 information security controls, etc. For risks and opportunities relevant to the intended outcome(s) of
646 the ISMS, the organization determines them based on internal and external issues (see 4.1) and
647 requirements from interested parties (see 4.2). There is no obligation on a particular method.
648 The second category consists of all risks that directly relate to the loss of confidentiality, integrity and
649 availability of information within the scope of the ISMS. These risks should be handled in accordance
650 with 6.1.2 (information security risk assessment) and 6.1.3 (information security risk treatment). These
651 activities are discussed in Clause 7 and 8, respectively. Risks that relate to preservation of information
652 security can result from a variety of causes including organizational failures, process failures,
653 management system failures, inadequate information processing system security controls, or
654 inadequate protection of information itself. While clause 6.1.1 d) requires ‘actions to address these
655 risks’, clauses 6.1.2 and 6.1.3 elaborate on what is required. It is possible that some organizations may
656 choose to broaden the scope of the way they meet the requirement s of 6.1.2 and 6.1.3 to cover all
657 categories of relevant risks, not just risks associated with information security.
658 NOTE Risk assessment and risk treatment activities are referred to as processes in ISO/IEC 27001 (6.1.2 and
659 6.1.3).
660 7 Information security risk assessment process
662 The organization should define an information security risk assessment process.
663 Risk assessment enables risk owners to prioritize risks aligned with the treatment perspective
664 according mainly to their perceived consequences and likelihood or other established criteria.
665 Risk assessment consists of the following activities:
666 a) Risk identification, which is a process of finding, recognizing and describing risks; to perform
667 risk identification, information security objectives need to be established in conformance with
668 ISO/IEC 27001, Clause 6.2; further details on risk identification are provided in Clause 7.2;
669 b) Risk analysis, which is a process to comprehend the nature of risk and to determine the level of
670 risk; risk analysis involves consideration of the causes and sources of risk, the likelihood that
671 the corresponding event occurs, the likelihood that this event has consequences and the
672 severity of the consequences; further details on risk analysis are provided in Clause 7.3;
673 c) Risk evaluation, which is a process of comparing the results of risk analysis with risk criteria to
674 determine whether the risk and/or its magnitude is acceptable and to prioritize the analysed
675 risks for risk treatment; based on this comparison, the need for treatment can be considered;
676 further details on risk evaluation are provided in Clause 7.4.
677 The risk assessment process should be based on methods and tools designed in sufficient detail such
678 that it leads to consistent, valid and reproducible results. Furthermore, the outcome should be
679 comparable, i.e. it’s comprehensible whether the level of risk increased or decreased.
680 ISO/IEC 27001 does not mandate a particular approach to be used to fulfil the requirements in Clause
681 6.1.2 of ISO/IEC 27001. There are two main approaches for assessment. They are discussed in more
682 details in Clause 7.2.1.
683 Information on information security risk assessment methods and techniques can be found in [Annex
684 ZYX]. Additional information on risk assessment techniques can be found in IEC 31010.

ISO/IEC 27005:####(E)
685 Editors’ Note 1: Keep in mind that Annex ZYX does not exist yet.
686 7.2 Identifying information security risks
687 7.2.1 Risks associated with the loss of confidentiality, integrity and availability of information
688 Input: Events that can negatively influence the achievement of information security objectives in the
689 organization or in other organizations; evaluation criteria for information assets.”
690 Action: Risks associated with the loss of confidentiality, integrity and availability of information should
691 be identified.
692 Trigger: Risk owners, interested parties and/or experts may detect, or have a need to search for, new or
693 changed events or situations that can affect the achievement of the objectives of the ISMS.
694 Output: A comprehensive list of risks.
695 Implementation guidance:
696 Risk identification is the process of finding, recognizing and describing risks. This involves the
697 identification of risk sources, events, their causes and their potential consequences.
698 The aim of risk identification is to generate a comprehensive list of risks based on those events that can
699 prevent, affect or delay the achievement of information security objectives.
700 ISO/IEC 27001:2013, 6.1.2 c) requires the organization to define and apply an information security risk
701 assessment process that identifies the information security risks. There are two approaches commonly
702 used to perform risk identification:
703 a) event-based approach: identify risks through a consideration of risk sources and events
704 (including their consequences); and
705 b) asset-based approach: identify risks taking into account the value of information assets, the
706 applicable threats and vulnerabilities that exist.
707 Event-based approach has an advantage in establishing a high level view of risk situation without
708 spending a considerable amount of time in identification of assets on a detailed level and allows the
709 organization to focus their risk treatment efforts on the critical risks. Evaluation of events in this
710 approach normally relies on historical data. However, in case that future events cannot be considered
711 they follow past trends, evaluation of such events can rely on knowledge and imagination of experts.
712 In the event-based approach, the underlying concept is that risks can be identified and assessed through
713 an evaluation of events and consequences. Determination of the consequences satisfies the requirement
714 to assess the potential consequences, whilst determination of the likelihood that an event might occur
715 satisfies the need to assess likelihood of the risk. Events and consequences can often be determined by a
716 discovery of the concerns of top management, risk owners and the requirements identified in
717 determining the context of the organization (ISO/IEC 27001:2013, Clause 4). Often, such concerns (e.g.
718 denial of service, disclosure, hacking, IT failure, fraud) can be distinguished as being either events or
719 consequences. Thus, interviews with top management and those people in the organization who have a
720 responsibility for a business process can assist in identifying not only the relevant events and
721 consequences, but also the risk owners.
722 The underlying concept of the asset-based approach is that risks can be identified and assessed through
723 an inspection of assets, threats and vulnerabilities. A threat exploits a vulnerability of an asset to
724 compromise the confidentially, integrity and/or availability of an item of corresponding information. If
725 all valid combinations of assets, threats and vulnerabilities can be enumerated within scope of the ISMS,

726 then, in theory, all the risks would be identified. For further steps of risk assessment, a list of assets
727 associated with information and information processing facilities should be drawn up.
728 In principle, the two approaches differ only in the level at which the identification is initiated. The
729 event-based approach starts from the top, and the asset-based approach starts at the bottom. It should
730 be noted both approaches can describe the same risk scenario where an information asset is at the
731 bottom and a business exposure - at the top. Identifying the contributory risk sources using an event-
732 based assessment typically requires drilling down towards lower levels, but using an asset-based
733 assessment is likely to require searching upwards towards aggregate consequences.
734 Any other risk identification approach can be used as long as it ensures the production of consistent,
735 valid and comparable results, satisfying requirement 6.1.2 b) of ISO/IEC 27001.
736 Comprehensive identification is critical, because an information security risk that is not identified at
737 this stage will not be included in further analysis.
738 Risk identification should include risks whether or not their source is under the control of the
739 organization, even if no specific risk sources is evident. During the first performance, risk assessment
740 should not be conducted very detailed. Usually, it should concentrate on high level information security
741 risks of the organisation. In subsequent runs of identification one should step forward to other risks
742 and increasing levels of detail.
743 More information on risk identification methods can be found in Annex ZYX.
744 7.2.2 Identifying risk owners
745 Input: List of identified risks
746 Action: Risks should be associated to risk owners.
747 Trigger: Lack of clarity in responsibilities for risk assessment
748 Output: List of risk owners with associated risks
750 The risk owner is a person or entity with the accountability for the asset under risk and the authority
751 for managing the risk.
752 EXAMPLE Top management, process owner, functional owners, department managers, asset owners
753 can be the risk owners.
754 An organization should define criteria for identifying risk owners. Such criteria should take into
755 consideration that risk owners:
756 - are accountable and have the authority for managing the risks they own. They should have a
757 position in the organization that allows them to actually exercise this authority;
758 - should have the competence for dealing with risk, i.e. they understand the issues at hand, and be
759 in a position to make informed decisions, e.g. regarding how to treat the risks; and
760 - should have adequate resources to manage their risks, i.e. sufficient time, money, and
761 information.
762 Failing to take these items into account is a risk of the overall risk management of the ISMS, and this
763 risk is owned by top management.

ISO/IEC 27005:####(E)
764 Identification of such a risk owner, and the identification of an information owner, should occur early
765 on in the process as they will be required to provide input to the establishing risk criteria activity
766 (Clause 5.2), and determine the consequences induced from potential information security damages
767 (Clause 7.3.1 - 7.3.3).
768 To each risk should be allocated. The allocation should take place as part of the risk assessment process
769 at the latest if the risks are identified.
770 7.3 Analyzing information security risks
771 7.3.1 Introduction
772 [Editors’ Note 2: The editing group agreed both approaches proposed in the Clause 7.2 should be
773 further discussed. However, it was proposed to remain generic in the core text and move details to an
774 annex.]
775 Risk analysis has the objective to determine the level of the risk.
776 ISO 31000 is referenced in ISO/IEC 27001 as a general model. ISO/IEC 27001, subclause 6.1. requires
777 that for each identified risk the risk analysis is based on assessing the consequences resulting from the
778 risk and assessing the likelihood of the risk to determine a level of risk.
779 Techniques for risk analysis based on consequences and likelihood can be:
780 1) qualitative, using a scale of qualifying attributes (e.g. high, medium, low);
781 2) quantitative, using a scale with numerical values (e.g. monetary cost, frequency or probability of
782 occurrence); or
783 3) semi-quantitative, using qualitative scales with assigned values.
784 7.3.2 Assessing potential consequences
785 Input: A list of business objectives, a list of business processes, a list of information and assets related to
786 information or a list of events, depending on the approach applied.
787 Action: The consequences resulting from the failure to adequately preserve confidentiality, integrity or
788 availability of information should be identified and assessed.
789 Trigger: Assessment of the consequences becomes necessary when:
790 - it has not been done before;
791 - the list produced by ‘risk identification’ is changed;
792 - risk owners or interested parties have changed the units in which they want consequences to be
793 specified; or
794 - changes in the scope or context are determined that may affect consequences.
795 Output: A list of potential consequences related to risk scenarios with their consequences related to
796 assets or events, depending on the approach applied.
798 Loss of confidentiality, integrity or availability of information is immediate consequence effect of a
799 failure to adequately preserve the security of information. Furthermore, such consequence can affect
800 business or other objectives. Consequence analysis is preferably performed bottom up from the
801 information security consequences by considering what might happen if there is a loss of information
802 confidentiality, integrity or availability. Typically, the risk owner can estimate the damages if the event
803 occurs. The following elements should be taken into consideration:
804 - estimation (or measure based on experience) of the losses -time or data- due to the event as the
805 result of the interrupting or disturbing the operations;

806 - estimation/perception of the consequence severity (e.g. expressed in money); and

807 - recovery costs depending on whether it can be done internally (by the risk owner team), or
808 there is a need to call an external entity.
809 More information on risk analysing methods can be found in Annex YYY.
810 7.3.3 Assessing likelihood
811 Input: A list of identified relevant event or risk scenarios, including identification of risk sources, and
812 business processes, business objectives and likelihood criteria. Furthermore, lists of all existing controls,
813 their effectiveness, implementation and usage status.
814 Action: The likelihood of occurrence of possible or actual scenario should be assessed and expressed
815 using established likelihood criteria.
816 Trigger: TBD
817 Output: A list of events or risk scenarios complemented by likelihoods that events occur or these events
818 have consequences.
820 After identifying the risk scenarios, it is necessary to analyse the likelihood of each scenario and
821 consequence occurring, using qualitative or quantitative analysis techniques. It should be noted that
822 assessing the likelihood is not obvious and should be expressed in different ways. This should take
823 account of how often the risk sources occur and how easily the vulnerabilities can be exploited,
824 considering:
825 - experience and applicable statistics for risk source likelihood;
826 - for deliberate risk sources: the motivation and capabilities, which will change over time, and
827 resources available to possible attackers, as well as the perception of attractiveness and
828 vulnerability of assets for a possible attacker;
829 - for accidental risk sources: geographical factors, e.g. proximity to chemical or petroleum plants,
830 the possibility of extreme weather conditions, and factors that could influence human errors
831 and equipment malfunction;
832 - vulnerabilities and any compensating controls, both individually and in aggregation; and
833 - existing controls and how effectively they reduce vulnerabilities.

834 Risk sources can be human. Analysing the human risk source potentials with regard to the likelihood of
835 a given scenario the following should be considered:
836 - the degree of motivation of the source (e.g. the viability [cost/benefit] of the attack);
837 - the required skill of the deliberate source;
838 - the available tools and resources to the source; and
839 - influences on the source such as serious crime, terrorist organizations or foreign intelligence.
840 To increase the reliability of estimating likelihood, organizations should consider using:
841 1. team assessments rather than individual assessments;

842 2. external sources, such as information security breaches reports; and
843 3. scales with at least four categories; and unambiguous categories, such as “once a year”,
844 rather than “infrequent”.
845 When assessing the likelihood of events, it is important to recognise the difference between
846 independent and dependent events. The likelihoods of events that depend on each other is conditioned

ISO/IEC 27005:####(E)
847 by the relationship between them (e.g. a second event may be inevitable if a first event occurs) so that
848 separate assessment of both their likelihoods is not necessary. The likelihoods of relevant independent
849 events are all essential contributors to the likelihood of a consequence to which they contribute. For
850 example, the likelihood of a denial of service attack on a server depends on the current threat landscape
851 and the vulnerability and accessibility of the server, but once the attack has started the likelihood of the
852 second and subsequent malicious packets is effectively 100%, consideration of which contributes
853 nothing useful to the task of assessing the likelihood of the DoS.
854 It should be useful to identify any dependencies between the events contributing to a risk scenario and
855 in the first instance assess the likelihoods of those events that are independent of each other.
856 The overall likelihood of business consequences of an information security event typically depends on
857 the likelihoods of potentially several lower level contributory events and their consequences. Therefore,
858 rather than attempting to estimate the likelihood of business consequences in a single high level
859 assessment, it can be more valid to start by aggregating the likelihoods of the individually assessed
860 lower level events that contribute to it.
861 7.3.4 Determining the levels of risk
862 Input: A list of risk scenarios with their consequences related to assets or events and their likelihood
863 (quantitative or qualitative)
864 Action: The level of risk should be determined as a combination of the assessed likelihood and the
865 assessed consequences for all relevant risk scenarios.
866 Trigger: Determining levels of risk becomes necessary if the information security risks are to be
867 evaluated.
868 Output: A list of risks with level values assigned
870 Determination of the level of risk is based on assessed consequences, and likelihood. The estimated risk
871 is a combination of the likelihood of a risk scenario and its consequences. The level of risk should be
872 determined using the criteria established as described in Clause 5.5.2.
Editors’ Note: There is an expectation expressed by expert to describe the topic in more details in an
annex. One possible source for this existing Annex E from 27005:2018 "Information security risk
assessment approaches"
Experts are invited to contribute, both to the standard main body, and the annex
873 7.4 Evaluating the information security risks
874 7.4.1 Comparing the results of risk analysis with the risk criteria
875 Input: A list of risk criteria and of risks with level values assigned
876 Action: Level of risks should be compared against risk evaluation criteria, particularly risk acceptance
877 criteria.
878 Trigger: Comparing the results of risk analysis with the risk criteria becomes necessary if the
879 information security risks are to be prioritized for treatment.
880 Output: A list of suggestions for decisions on additional actions regarding the management of risks

882 Once the risks have been identified and assigned likelihood and severity of consequence values,
883 organizations should apply their risk acceptance criteria to determine whether or not the risks are
884 acceptable. If they are not acceptable, then they should be prioritized for treatment.
885 To evaluate risks, organizations should compare the assessed risks (selected methods or approaches
886 are discussed in Annex XYZ) with the risk criteria defined during the context establishment.
887 Risk criteria used to make decisions should consider the objectives of the organization and appropriate
888 interested parties views etc. Decisions as taken in the risk evaluation activity are mainly based on the
889 acceptable level of risk. However, consequences, likelihood, and the degree of confidence in the risk
890 identification and analysis should be considered as well. Aggregation of multiple low or medium risks
891 can result in much higher overall risks and need to be addressed accordingly.
892 There may be uncertainties in defining the boundary between those risks that need treatment and
893 those that do not. Under certain circumstances, using a single level as the acceptable level of risk which
894 divides risks that need treatment from those which do not may not be appropriate. It can be more
895 appropriate to use a different approach such as “as low as reasonably practical” that provides
896 conditional rather than absolute acceptable level of risk. For example, a risk matrix may show three
897 regions: regions representing unacceptable risks, acceptable risks and risks that need to be reduced as
898 low as reasonably practicable. Reasonable practicability is given by the ratio between the costs and
899 benefits of reducing a specific risk.
900 The levels of risk could be validated based on consensus of security from IT and/or business specialists.
901 If any level of risk differs from risk owner’s general conception, it should be reviewed whether the risk
902 owner’s conception does not reflect the real situation or something is not appropriate in risk estimation,
903 or the risk model itself.
904 7.4.2 Prioritizing the analysed risks for risk treatment
905 Input: A list of the results of risks compared with risk criteria
906 Action: The risks on the list should be prioritized considering assessed levels of risks.
907 Trigger: Prioritizing the analysed risks for risk treatment becomes necessary if the information security
908 risks are to be treated.
909 Output: A list of prioritized risks with risk scenarios that lead to those risks
911 Risk evaluation uses the understanding of risk obtained by risk analysis to make proposals for deciding
912 about the next step to take. Those should refer to:
913 - whether a risk treatment is required; and

914 - priorities for risk treatment considering assessed levels of risks.
915 Risk criteria used to prioritize risks should consider the objectives of the organization, contractual, legal
916 and regulatory requirements and appropriate interested parties views. Prioritization as taken in the
917 risk evaluation activity are mainly based on the acceptance criteria.

ISO/IEC 27005:####(E)
918 8 Information security risk treatment process
920 The input of the information security risk treatment is based on the risk assessment process outcomes
921 in the form of prioritized set of risks to be treated, based on risk criteria.
922 The output of this process is a set a necessary information security controls (ISO/IEC 27001 Clause
923 6.1.3 b)) that are to be deployed or enhanced in relation to one another in accordance with the risk
924 treatment plan (Clause 6.1.3 e)). Deployed in this way the effectiveness of the risk treatment plan will
925 be to modify the information security risk facing the organization so that it meets the organization’s
926 criteria for acceptability.
927 8.2 Selecting appropriate information security risk treatment options
928 Input: A list of prioritized risks risk scenarios that lead to those risks
929 Action: Risk treatment options should be chosen, necessary controls should be determined and risk
930 treatment plan(s) should be formulated.
931 Trigger: Selecting appropriate information security risk treatment options becomes necessary if a risk
932 treatment plan is to be formulated.
933 Output: Approved information security risk treatment plan(s) with retained residual information
934 security risks
936 ISO 31000:2018 cites seven options for risk treatment:
937 a) avoiding the risk by deciding not to start or continue with the activity that gives rise to the risk;
938 b) taking or increasing the risk in order to pursue an opportunity;
939 c) removing the risk source;
940 d) changing the likelihood;
941 e) changing the consequences;
942 f) sharing the risk (e.g. through contracts, buying insurance); and
943 g) retaining the risk by informed decision.
944 In practice, this list can be shortened. Always, four options are recommended to consider taking into
945 account their relevance to the actions toward risk factors which include:
946 - risk avoidance, by deciding not to start or continue with the activity that gives rise to the risk;
947 - risk modification, by changing the likelihood of the occurrence of an event or a consequence or
948 changing the severity of the consequence;
949 - risk retention, by informed choice; and
950 - risk sharing, by splitting responsibilities with other parties, either internally or externally,
951 Excepting options b) (taking risk) and g), each of the options requires a control. An example of risk
952 avoidance in case of theft of documents threat is ensuring that sensitive information is not stored on
953 laptops. In case of risk sharing at least one control is required to modify the likelihood or severity but
954 the organization delegates the responsibility of implementing the control to another party. One of the
955 purposes of increasing risk is to guard against over-control. The presence of too many controls can have
956 an adverse effect on meeting business objectives.
957 Risk treatment options should be selected based on the outcome of the risk assessment, the expected
958 costs for implementing these options and the expected benefits from these options, both singly and in

959 context of other controls. Risk treatment should be prioritized according to levels of risk as defined,
960 time constraints and necessary sequence of implementations, and risk evaluation outcomes established
961 in Clause 7.4. While choosing the option one can consider how a particular risk is perceived by affected
962 parties, and which ways of risk communication with these parties the most appropriate are.
963 8.3 Determining all controls that are necessary to implement the information security
964 risk treatment options
Editors’ Note 1: Classification of controls should be further considered.

The common categorization of controls shows several pitfalls as they aim to counter one risk factor
(likelihood or consequence). In many cases the effect is on both factors, potentially with a different
level.
Some preventive and corrective controls need to be in place and permanently activated while others are
used only when the event occurs (reaction to the event). For example, a fire protection system consist of
several various controls: 1° fire resistant construction (walls and doors), 2° fire extinguishers, 3°
training people to evacuate and use the fire extinguishers, and 4° fire detectors. Where do we put these
controls in the current categorization while all are to be in place (far) before the fire starts?
Another expert presents an opinion that the ‘common’ categories of controls are too generic. If we have
a look at the event/incident, controls to be activated before, during and after the event can all be put
under the ‘preventive’ category because they prevent the occurrence or the extension of the
consequence. This does not allow to have a good perception of the nature of the controls. This revision
can also be the time to have a newer model for control categorization in opposition to remain with the
‘old fashioned’ model that is unclear. (see appendix). The proposed tags in 27002 based on the NIST
cybersecurity framework is one option, but it lacks the last stage ‘compensation’ that allows the
organization to recover (part of) the loss through insurances and suing the culprit.
Next opinion is that categorising controls based on their ability to enforce confidentiality, integrity or
availability […] It needs to be clear how these assignments were realised in terms of what factors were
considered and to what extent does each enforce CIA where assigned. The example of encryption is
again useful in that it enforces Confidentiality, some others are quite contentious though
Another element that might be explored is a mapping of controls to different attacks/techniques a
threat may employ to attack an organisation. This can be valuable in selecting controls specific to each
Threat/Threat Event combination. As an example, if we consider a Nation state conducting a DDoS
attack, a practitioner can consult a controls/threat event mapping to determine the best controls for
mitigating a DDoS attack. This in turn informs the risk treatment plan.
Additionally, there is a proposal to consider the Attributes that group controls in the revision of ISO/IEC
27002:2013 for classification of controls.
ISO/IEC 27002 should be referenced to implement the PDR and CIA attributes once the new draft is
stable, at least at CD level. Although ISO/IEC 27002 defines the attributes, it does not guide how to
utilize them. Experts are asked to provide explanation on how to apply controls to risks.
Experts are asked to consider the content of this subclause.
965 Input: A list of prioritized risks with event or risk scenarios that lead to those risks
966 Action: Determine all necessary controls for treating the risks based on the risk treatment options(s)
967 chosen such as to modify, retain, avoid or share the risks from any source of control sets.
968 Trigger: ISMS conformity; managing information security risks
969 Output: All necessary controls

ISO/IEC 27005:####(E)
971 Special attention should be given to determine the necessary information controls. One or more
972 controls should be applied to every risk needed to be modified. Necessary controls can be ISO/IEC
973 27001:2013, Annex A controls, controls defined in another standard or controls designed by the
974 organization ("custom controls").
975 Controls can be classified as preventive, detective and reactive:
976 a) Preventive control: a control that is intended to prevent the occurrence of an information
977 security event that can lead to the occurrence of one or more consequences;
978 b) Detective control: a control that is intended to detect the occurrence of an information security
979 event; and
980 c) Reactive control: a control that is intended to limit the consequences.
981 Control-type describes whether a control acts, or tends to act, to prevent or detect an event or react to
982 its consequence(s). For example, an information security policy is a control that maintains risk, but
983 policy compliance should reduce the likelihood of the occurrence of risk and can be therefore
984 categorized as being preventive.
985 The utility of categorizing controls as preventive, detective and reactive lies in its use to ensure the
986 construction of risk treatment plans are resilient to control failures. Provided there is an approximate
987 mix of preventive, detective and reactive controls:
988 ̶ detective controls should mitigate risk if the preventive controls fail;
989 ̶ reactive controls should mitigate risk if the detective controls fail; and
990 ̶ preventive controls should reduce the likelihood that the reactive controls should ever have to be used.
991 When utilize controls, organizations should first decide if it is possible to detect the occurrence of an
992 event. If that is the case, detective controls should be implemented. If it is not possible to detect an
993 event, detective controls could be ineffective, and more, that could be no way of telling whether a
994 preventive control is working. For example, if it is not clear if a computer has become part of a "botnet",
995 it cannot be known if the controls being used to prevent it becoming part of a botnet work as intended.
996 Reactive controls should be looked at next. If the detective controls fail, then there is likely to be one or
997 more undesirable consequences. Implementation of the reactive controls can assist in the limitation of
998 those consequences. Although reactive controls take effect after the onset of the consequence, often
999 they need to be deployed well in advance of the occurrence of any event. For example: Hard disc
1000 encryption does not prevent a laptop from being stolen or subsequent attempts to extract the data. It
1001 does, however, reduce the severity of the consequences of disclosure. The control, of course, needs to be
1002 deployed before the laptop is stolen.
1003 The categorization of controls is not absolute and depends on the context in which use of a control is
1004 described. For example, backup does not prevent the occurrence of an event that would otherwise
1005 result in data loss (e.g. a disc head crash or loss of a laptop), but it does assist to reduce the consequence.
1006 Some organizations may therefore consider this to be a reactive control rather than a preventive
1007 control. Similarly, encryption does not prevent the loss of information, but if the event is described as
1008 “personal data revealed to attacker”, then encryption is a preventive, rather than a reactive control.
1009 The order in which the controls addressing treating the risks are organized depends on various factors
1010 and many techniques can be used. It is the respective risk owners’ responsibility to decide the balance
1011 between the costs of investing in controls and assuming consequences in case of risk is materialized.

1012 Editors’ Note 2: Experts are asked to explore further the issue of adequate accumulation of coordinated
1013 controls (and Defense in Depth) that provides the real and effective security.
1014 The identification of existing controls can determine that these controls exceed current needs. A cost –
1015 benefit analysis should be undertaken before removing redundant or unnecessary controls is
1016 considered (especially, if the controls have high maintenance costs). Since controls can influence each
1017 other, removing redundant controls might reduce the overall security in place.
1018 8.4 Comparing the controls determined with those in ISO 27001 Annex A
1019 ISO/IEC 27001:2013, 6.1.3 c) requires an organization to compare the controls that it has determined
1020 as being necessary to implement its chosen risk treatment options with the controls listed in ISO/IEC
1021 27001:2013, Annex A. ISO/IEC 27001:2013, 6.1.3 d) requires organizations to document the result of
1022 this analysis in a "statement of applicability". The purpose of this is to act as a safety check to verify that
1023 no necessary controls have been omitted.
1024 As presented in Fig. 1, ISO/IEC 27001:2013, Annex A contains a comprehensive list of control objectives
1025 and controls. The organization should recognize the possibility that not all Annex A controls need be
1026 applicable. Of those that are, some can already have been determined by the organization and others
1027 don’t. The organization should also recognize the possibility that some of the controls that the
1028 organization has determined as being necessary (Clause 8.3) are not in Annex A. The final possibility is
1029 that the organization has failed to determine some other necessary custom controls, which are also not
1030 in Annex A. The result of this procedure is a partitioning of the Annex A controls into those that are
1031 applicable and those that are not applicable.

ISO/IEC 27005:####(E)
1032
1033 Fig. 1 Process of determining controls
1034 8.5 Producing a Statement of Applicability
1035 In accordance with ISO/IEC 27001:2013, the Statement of Applicability should contain:
1036 a) a list of the necessary controls;

1037 b) justification for each control’s inclusion (e.g. by reference to the relevant contract(s), legislation,
1038 regulations and/or risk treatment plan, or that part of a risk treatment plan where the controls
1039 have been selected);
1040 c) whether each necessary control is implemented or not (e.g. whether it is operational, under
1041 construction or not yet fully implemented, or work on its deployment has yet to start);
1042 d) a list of excluded Annex A controls (i.e. controls in ISO/IEC 27001:2013, Annex A that have not
1043 been determined as being necessary controls by the process of risk treatment); and
1044 e) justification for each excluded Annex A control’s exclusion.
1045 Justification for excluding any of the ISO/IEC 27001:2013, Annex A controls can include:
1046 1) there is no associated risk, e.g. A.14.2.7 (Outsourced development) is not applicable because all
1047 the organization’s system development is performed in-house;
1048 2) the associated risk is out of scope of the ISMS, e.g. A.14.2.7 (Outsourced development) is not
1049 applicable because management of any associated risks has also been outsourced;
1050 3) it is obviated by a custom control, e.g. A.8.3.1 (Management of removal media) can be excluded
1051 if an alternative control prevented the use of removal media;

1052 4) its control objective is adequately achieved by a custom control, e.g. A.18.1.1 (Identification of
1053 applicable legislation and contractual requirements) can be adequately addressed by a custom
1054 control focusing on business functions or processes rather than information systems – in this
1055 case the custom control can be regarded as a variation of the Annex A control); and/or
1056 5) its cost of implementation exceeds the perceived risk exposure.
1057 Case 4), which can be thought of as a variant of a ISO/IEC 27001:2013, Annex A control, is a particularly
1058 powerful device as it allows organizations to precisely state their controls (i.e. what they actually do),
1059 whilst at the same time acknowledging the corresponding generic control in ISO/ IEC 27001:2013,
1060 Annex A.
1061 Augmentation of the coverage of the Statement of Applicability to include controls from relevant sector-
1062 specific standards is particularly important if an organization wishes to adopt best sector- specific
1063 practice as represented by such standards.
1064 8.6 Information security risk treatment plan
1065 8.6.1 Formulation of the risk treatment plan
1066 The purpose of this activity is to create plan(s) for treating specific sets of the risks that are on the list of
1067 prioritized risks (see Clause 7.4). A risk treatment plan (RTP) is a plan to modify risk such that it meets
1068 the organization’s risk acceptance criteria. There are two different, but equally valid interpretations of
1069 the term ‘plan’ in the context of risk treatment. The first is a project plan, i.e. a plan to implement the
1070 organization’s necessary controls. The second is a design plan, i.e. the plan that not only identify
1071 necessary controls but describe how the controls interact with their environment and each other to
1072 modify risk. In practice, both are required.
1073 Once the controls are in place, the project plan ceases to have any value other than as a historical record,
1074 whereas the design plan will be still useful.
1075 Every risk that needs treatment must be treated in one of the risk treatment plans. An organization may
1076 choose to have several risk treatment plans which together implement all required aspects of risk
1077 treatment. These could be organized on the basis of where the information resides (e.g. one plan for the
1078 data centre, another for mobile computing, etc.), by asset (e.g. different plans for different asset
1079 classifications) or by events (such as those used when assessing risk using the event-based method).
1080 While creating the risk treatment plan, organizations should consider the following:
1081 - priorities in relation with the level of risk and urgency of treatment;
1082 - different types of controls (preventive, detective, reactive) or their composition are applicable;
1083 - the time for a control under implementation to reach its expected effectiveness varies from
1084 control to control;
1085 - there is sometimes a need to wait for a control to be settled before starting implementing a new
1086 one on the same asset; and
1087 - there is sometimes a delay between the time the control is implemented and the moment where
1088 it is fully effective and operational.
1089 A risk treatment plan should identify:
1090 - the risks and the corresponding risk treatment;

1091 - the actions to be done for the risk treatment;
1092 - cost of actions;
1093 - the actions expected effect on risk;
1094 - the resources to be used to implement that treatment;
1095 - priority, timing and schedule for implementation and testing;

ISO/IEC 27005:####(E)
1096 - metrics, performance indicators, and objectives;

1097 - roles and responsibilities; and
1098 - relationships with other risks and residual risks derived.
1099 The risk treatment plan actions should be ranked by priority in relation with the level of risk and
1100 urgency of treatment. The higher the level of risk, and in some cases the frequency of risk occurrence,
1101 the sooner the control is to be implemented.
1102 For each listed risk within the risk treatment plan, a detailed implementation information should be
1103 given which may include:
1104 - names of risk owners and persons responsible for the implementation;
1105 - implementation dates or timelines;
1106 - control activities planned to test the implementation result; and
1107 - implementation status.
1108 8.6.2 Approval by risk owners
1109 The information security risk treatment plan should be approved by the risk owners once it is
1110 formulated. Risk owners should also decide on the acceptance of residual information security risks.
1111 This decision should be based on defined risk acceptance criteria.
1112 The results of the risk assessment, the risk treatment plan and the remaining risks should be
1113 understandable to the risk owner so that they can discharge their responsibilities properly.
1114 8.6.3 Acceptance of the residual information security risks
Editors’ Note: As agreed at the meeting held in Gjovik, we should address two view of this activity:
1) acceptance of the ‘perceived’ residual risk before the risk treatment plan is actually launched. and
2) coverage the ‘follow-up’ of the plan and measure the actual residual risk when the plan is completed.
The follow-up of the plan should be addressed as well, even if we have to refer to
project/program/portfolio management. Depending on the time needed, there will be a lot of changes
in the context, level of risk and (security) decision during the journey. We have to keep in mind that the
risk treatment plan is there to ‘modify’ the behaviour of a living entity: the organization as an
information system’. As during a surgery, we have to keep the entity living and operational and have the
least negative effect on it.
Experts are asked for further contributions to cover these views.
1115 Risk treatment plans should describe how assessed risks are to be treated to meet risk acceptance
1116 criteria, which can be more complex than just determining whether or not a residual risk falls above or
1117 below a single threshold.
1118 In some cases, the level of residual risk may not meet risk acceptance criteria because the criteria being
1119 applied do not take into account prevailing circumstances. For example, it might be argued that it is
1120 necessary to retain risks because the benefits accompanying the risks are very attractive, or because the
1121 cost of risk modification is too high. However, it is not always possible to revise the risk acceptance
1122 criteria in a timely manner. In such cases, risk owners may have to retain risks that do not meet normal
1123 acceptance criteria. If this is necessary, the risk owner should explicitly comment on the risks and
1124 include a justification for the decision to override normal risk acceptance criteria.

1125 Risk acceptance may involve a process to achieve endorsements of treatments prior to a final risk
1126 acceptance decision. It is important for risk owners to review and approve proposed risk treatment
1127 plans and resulting residual risks, and record any conditions associated with such approval.
1128 9 Operation
1129 9.1 Performing information security risk assessment process
1130 ISO/IEC 27001:2013, 8.2 requires organizations to conduct further risk assessments at planned
1131 intervals or when significant changes are proposed, or occur.
1132 The information security risk assessment process defined and applied in (ISO/IEC 27001:2013, 6.1)
1133 should be integrated into the organizational operations and be performed at planned intervals or when
1134 significant changes are proposed or occur, taking account of the criteria established in ISO/IEC
1135 27001:2013, 6.1.2 a). The intervals at which the risk assessment is performed should be appropriate to
1136 the ISMS. When a significant change of the ISMS (or its context) or a change in the threat landscape (e.g.
1137 a new type of information security attack) had occurred, the organization should determine if this
1138 change requires an additional information security risk assessment.
1139 When making plans for routine risk assessments, organizations should take account of any calendar
1140 that applies to their general business processes. For example, if there is an annual budget cycle, the
1141 organization might need to submit funding requests at a certain time of year. Funds are then granted
1142 (diminished or denied) later. If the procurement processes are involved, there can be another cycle
1143 before risk treatment recommendations can be implemented and their effectiveness assessed prior to
1144 the next routine risk assessment. In such cases, risk assessments should be scheduled:
1145 a) to make their risk treatment recommendations in time for funding application;
1146 b) to be reassessed following the results of budget allocations; and
1147 c) to make the next routine assessment, once recommendations have been implemented, after any
1148 procurement activity.
1149 9.2 Performing information security risk treatment process
1150 ISO/IEC 27001:2013, 8.3 requires organizations to implement their risk treatment plans.
1151 Considerations included in Clause 8.6 are relevant to this Clause as well.
1152 10 Leveraging related ISMS processes

1153 Note 1: In the following headings one can find references included in brackets. The corresponding
1154 clauses are related to ISO/IEC 27001:2013.
1155 10.1 Context of the organization (Clause 4)
1156 The organization should have a high-level (e.g. strategic) understanding of the important issues that can
1157 affect the ISMS, either positively or negatively, It should further know the external and internal context
1158 that is relevant to its purpose and that affect its ability to achieve the intended outcome of its ISMS. The
1159 intended outcome should include preservation of the confidentiality, integrity and availability of
1160 information by applying the risk management process and in which risks are adequately managed.
1161 Then organization should understand in sufficient detail the circumstances in which the organization
1162 operates to be able to reliably identify risks. This means the organization should gather information
1163 concerning the external and internal context and the organization’s interested parties and their
1164 requirements (see ISO/IEC 27001:2013, 4.1 and 4.2), before any attempt is made by the organization to
1165 assess its information security risks, or indeed any other risks that could affect the intended outcome of
1166 the ISMS (see ISO/IEC 27001:2013, 6.1.1).

ISO/IEC 27005:####(E)
1167 The organization should consider all internal and external risk sources. Therefore, the organization’s
1168 understanding of interested parties that are opposed to the organization and their interests is highly
1169 relevant. An example of where an interested party has interests that are opposed to the organization’s
1170 objectives is the hacker. The hacker wishes a weak organization security. The organization should take
1171 account of this party’s interest by having the opposite, i.e. strong security. That means, some needs of
1172 prospects conflict with the purpose of the ISMS and the organization should ensure, through
1173 appropriate information security controls, that these interests are not met.
1174 Interfaces with services or activities that are not completely within the scope of the ISMS should be
1175 considered in the organization’s information security risk assessment. An example of such a situation is
1176 the sharing of assets (e.g. facilities, IT systems and databases) with other organizations or the
1177 outsourcing of a business function.
1178 How further relevant factors influencing information security are considered depends on the
1179 organization’s choice of risk identification and analysis methods.
1180 It should be borne in mind that the organization’s information security objectives (see ISO/IEC
1181 27001:2013, 6.2) can constrain the risk acceptance criteria (e.g. the acceptable level of risk can be a
1182 function of the potential rewards associated with different business activities). Furthermore, the
1183 information security policy can constrain risk treatment (e.g. a certain risk treatment options can be
1184 excluded by that policy).
1185
1186 10.2 Leadership and commitment (Clause 5.1)
1187 Editors’ Note: Experts are urgently asked to contribute to this Clause.
1188 10.3 Communication (Clause 7.4)
1189 Input: Information on risks, their causes, consequences and their likelihood identified through the risk
1190 management processes
1191 Action: Information on risks, their causes, consequences, their likelihood, and the controls being taken
1192 to treat them should be communicated to or obtained from the external and internal interested parties.
1193 Trigger: ISO/IEC 27001:2013 requires such communication.
1194 Output: Appropriate interested parties’ perceptions and continual understanding of the organization’s
1195 information security risk management process and results
1197 Communication and consultation is an activity to achieve agreement on how to manage risks by
1198 exchange and/or share information about risk with the risk owners and other appropriate interested
1199 parties. The information includes, but is not limited to the existence, nature, form, likelihood,
1200 magnitude, treatment, and acceptability of risks.
1201 ISO/IEC 27001:2013, 6.1.2 c) 2) requires that owners of the information security risks are identified.
1202 Risk ownership can be deliberately confused or concealed. Even when risk owners can be identified,
1203 they might be reluctant to acknowledge that they are responsible for the risks that they own, and
1204 obtaining their participation in the risk management process could be difficult. Hence, there should be a
1205 defined communication procedure for informing those concerned about risk ownership.
1206 ISO/IEC 27001:2013, 6.1.3 f) requires the risk owners to approve the risk treatment plan(s) and to
1207 decide on the acceptance of residual risk. Communication of the staff which is responsible for the

1208 implementation or maintenance of the information security management system with the risk owners
1209 is therefore an important activity. There should be an agreement on how to manage risks by exchanging
1210 and/or sharing information about risk with the risk owners, and perhaps other interested parties and
1211 decision-makers. The information includes, but is not limited to, the existence, nature, form, likelihood,
1212 severity, treatment and acceptability of risks. Communication should be bi-directional.
1213 Depending on the nature and sensitivity of the risk(s) there might be a need to limit some information
1214 about risks, their assessment and treatment on a need-to-know basis to those responsible for
1215 identifying, assessing and treating them. Limiting the communication about specific risks should be on
1216 an appropriate and proportionate basis, in consultation with the risk owners or potential owners, with
1217 the aim of avoiding publicizing the more sensitive risks and their associated vulnerabilities.
1218 Perceptions of risk can vary due to differences in assumptions, concepts, needs, issues and concerns of
1219 the appropriate interested parties as they relate to risk or the issues under discussion. Interested
1220 parties are likely to make judgments on the acceptability of risk, based on their perception of risk. This
1221 is especially important to ensure that the interested parties’ perceptions of risk, as well as their
1222 perceptions of benefits, can be identified and documented and the underlying reasons clearly
1223 understood and addressed.
1224 Communication and consultation concerning risks can result in improved interested parties’
1225 engagement with what is being done and appropriate interested parties taking ownership of decisions
1226 and outcomes. As a result, likelihood that they will accept findings and support action plans is often
1227 increased. In cases where interested parties are managers, this can build commitment to achieving risk
1228 management objectives and providing the necessary resources.
1229 Risk communication should be carried out in order to:
1230 - provide assurance of the outcome of the organization’s risk management;

1231 - collect risk information;
1232 - share the results from the risk assessment and present the risk treatment plan;
1233 - avoid or reduce both the occurrence and consequence of information security breaches due to the
1234 lack of mutual understanding among risk owners and appropriate interested parties;
1235 - support risk owners;
1236 - obtain new information security knowledge;
1237 - co-ordinate with other parties and plan responses to reduce the consequences of any incident;
1238 - give risk owners and appropriate interested parties a sense of responsibility about risks; and
1239 - improve awareness.
1240 An organization should develop risk communication plans for normal operations as well as for
1241 emergency situations. Therefore, risk communication and consultation activity should be performed
1242 continually.
1243 The co-ordination between major risk owners and appropriate interested parties can be achieved by
1244 the formation of a committee where debate about risks, their prioritization and appropriate treatment,
1245 and acceptance can take place.
1246 Risk communications can be voluntarily forwarded to external third parties for enabling better risk
1247 management or response coordination or awareness and can as well be required by regulators or
1248 business partners under certain circumstances.
1249 It is important to cooperate with the appropriate public relations or communications unit within the
1250 organization to coordinate all tasks related to risk communication. This is crucial in the event of crisis
1251 communication actions, for example, in response to particular incidents.

ISO/IEC 27005:####(E)
1252 10.4 Documented information (Clause 7.5)
1253 10.4.1 General
1254 ISO/IEC 27001 requires organizations to retain documented information concerning the risk
1255 assessment process (see ISO/IEC 27001:2013, 6.1.2) and results (see ISO/IEC 27001:2013, 8.2); and the
1256 risk treatment process (ISO/IEC 27001:2013, 6.1.3) and results (ISO/IEC 27001:2013, 8.3).
1257 10.4.2 Documented information about processes
1258 Documented information about the information security risk assessment process should contain:
1259 a) a definition of the risk criteria (including the risk acceptance criteria and the criteria for
1260 performing information security risk assessments);
1261 b) reasoning for the consistency, validity and comparability of results;
1262 c) a description of the risk identification method (including the identification of risk owners);
1263 d) a description of the method for analyzing the information security risks (including the
1264 assessment of potential consequences, realistic likelihood and resultant level of risk); and
1265 e) a description of the method for comparing the results with the risk criteria and the
1266 prioritization of risks for risk treatment.
1267 Documented information about the information security risk treatment process should contain
1268 descriptions of:
1269 f) the method for selecting appropriate information security risk treatment options;
1270 g) the method for determining necessary controls;
1271 h) how ISO/IEC 27001 Annex A is used to determine that necessary controls have not been
1272 inadvertently overlooked;
1273 i) how the SOA is produced;
1274 j) how risk treatment plans are produced; and
1275 k) how risk owners’ approval is obtained.
1276 10.4.3 Documented information about results
1277 As organizations are required to perform risk assessments planned intervals or when significant
1278 changes are proposed or occur, there should at least be evidence of a schedule, and risk assessments
1279 being performed in accordance with that schedule. If a change is proposed, or has occurred, then there
1280 should be evidence of the performance of an associated risk assessment. Otherwise the organization
1281 should explain why the change is or was not significant.
1282 Documented information about the information security risk assessment results should contain:
1283 a) the identified risks, their severity and likelihood;

1284 b) the identity of the risk owner(s);
1285 c) the results of applying the results of the risk acceptance criteria; and
1286 d) the priority for risk treatment.
1287 Documented information about the information security risk treatment results should contain:
1288 e) identification of the necessary controls; and

1289 f) evidence that these necessary controls act to modify risk so as to meet the organization’s risk
1290 acceptance criteria.

1291 10.5 Monitoring and measurement (Clause 9.1)
1292 10.5.1 General
1293 The organization’s monitoring process (see ISO/IEC 27001:2013, 9.1) should encompass all aspects of
1294 the risk assessment and risk treatment processes for the purposes of:
1295 a) ensuring that the risk treatments are effective and efficient in both design and operation;
1296 b) obtaining further information to improve risk assessment;
1297 c) analyzing and learning lessons from incidents (including near misses), changes, trends,
1298 successes and failures;
1299 d) detecting changes in the external and internal context, including changes to risk criteria and the
1300 risk itself, which can require revision of risk treatments and priorities; and
1301 e) identifying emerging risks.
1302 10.5.2 Monitoring and review of factors influencing risks
1303 Input: All risk information obtained from the risk management activities
1304 Action: Risks and their factors (i.e. value of assets, consequences, threats, vulnerabilities, likelihood of
1305 occurrence) should be monitored and reviewed to identify any changes in the context of the
1306 organization at an early stage, and to maintain an overview of the complete risk picture.
1307 Trigger: TBD
1308 Output: Continual alignment of the management of risks with the organization’s business objectives,
1309 and with risk acceptance criteria
1311 ISO/IEC 27001:2013, 9.1 requires organizations to evaluate their information security performance
1312 (and ISMS effectiveness). In accordance with this, organizations should use their risk treatment plan(s)
1313 as a subject for their performance evaluations. To do this, an organization should first define one or
1314 more information needs, for example, to describe what top management wishes to know about the
1315 organization’s ability to defend itself against threats. Using this as a top level specification, an
1316 organization should then determine the measurements that it needs to make and how such measures
1317 should be combined in order to satisfy the information need.
1318 Risks are not static. Event scenarios, asset values, threats, vulnerabilities, likelihoods and consequences
1319 can change abruptly without any indication. Therefore, constant monitoring should be carried out to
1320 detect these changes. This can be supported by external services that provide information regarding
1321 new threats or vulnerabilities. Organizations should ensure the continually monitoring of relevant
1322 factors, such as:
1323 a) new sources of risk, including freshly reported vulnerabilities in IT;

1324 b) new assets that have been included in the risk management scope;
1325 c) necessary modification of asset values, e.g. due to changed business requirements;
1326 d) identified vulnerabilities to determine those becoming exposed to new or re-emerging threats;
1327 e) changes in patterns of use of existing or new technologies that could open up new possible
1328 opportunities for attack;
1329 f) changes in laws and regulations;
1330 g) changes in risk appetite and perceptions of what is now acceptable and what is no longer
1331 acceptable; and
1332 h) information security incidents, both inside and outside of the organization.

ISO/IEC 27005:####(E)
1333 New sources of risk or changes in likelihood or consequences can increase risks previously assessed.
1334 Review of low and retained risks should examine each risk separately, and all such risks as an aggregate
1335 as well, to assess their potential accumulated consequence. If risks no longer fall into the low or
1336 acceptable risk category, they should be treated using one or more of the options in 8.2.
1337 Factors that affect the likelihood of the occurrence of event and their consequences of events can
1338 change, as can factors that affect the suitability or cost of the various treatment options. Major changes
1339 affecting the organization should be a reason for a more specific review. Therefore, the risk monitoring
1340 activities should be regularly repeated and the selected options for risk treatment should be reviewed
1341 periodically.
1342 New threats, vulnerabilities or changes in likelihood or consequences can increase risks previously
1343 assessed as low ones. Review of low and retained risks should consider each risk separately, and all
1344 such risks as an aggregate as well, to assess their potential accumulated consequence. If risks do not fall
1345 into the low or acceptable risk category, they should be treated using one or more of the options
1346 considered in Clause 9.
1347 Factors that affect the likelihood and consequences of threats occurring can change, as can factors that
1348 affect the suitability or cost of the various treatment options. Major changes affecting the organization
1349 should be reason for a more specific review. Therefore, the risk monitoring activities should be
1350 regularly repeated and the selected options for risk treatment should be reviewed periodically.
1351 The outcome of risk monitoring activities can be input to other risk review activities. The organization
1352 should review all risks regularly, and when major changes are proposed or occur in accordance with
1353 ISO/IEC 27001:2013, Clause 8).
1354 10.6 Management review (Clause 9.3)
1355 Input: Results of information security risk assessment(s), status of information security risk treatment
1356 plan
1357 Action: The results of information security risk assessment and status of the information security risk
1358 treatment plan should be reviewed to confirm that residual risks meet risk acceptance criteria, and that
1359 the risk treatment plan addresses all relevant risks and their risk treatment options.
1360 Output: Changes of the risk acceptance criteria and the criteria for performing information
1361 security risk assessments, updated information security risk treatment plan or Statement of
1362 Applicability
1363
1364 [Editors’ Note: Experts are asked for contributions to complement this subclause including
1365 consideration of risks and opportunities (outcome of the ISMS).]
1366 10.7 Corrective action (Clause 10.1)
1367 [Editors’ Note: Experts are urgently asked for contributions to this empty subclause.]
1368 10.8 Continual improvement (Clause 10.2)
1369 Input: All risk information obtained from the risk management activities
1370 Action: The information security risk management process should be continually monitored, reviewed
1371 and improved as necessary and appropriate.

1373 Ongoing monitoring and review is necessary to ensure that the context, the outcome of the risk
1374 assessment and risk treatment, as well as management plans, remain relevant and appropriate to the
1375 circumstances.
1376 The organization should make sure that the information security risk management process and related
1377 activities remain appropriate in the present circumstances and are followed. Any agreed improvements
1378 to the process or actions necessary to improve compliance with the process should be notified to the
1379 appropriate managers to have assurance that no risk or risk element is overlooked or underestimated
1380 and that the necessary actions are taken and decisions are made to provide a realistic risk
1381 understanding and ability to respond.
1382 For example, change management process should continuously provide feedbacks to the risk
1383 management process in order to ensure that variations to information systems able to modify risks are
1384 promptly taken into account, even modifying risk assessment activities program to properly evaluate
1385 them.
1386 Additionally, the organization should regularly verify that the criteria used to measure the risk and its
1387 elements are still valid and consistent with business objectives, strategies and policies, and that changes
1388 to the business context are taken into consideration adequately during the information security risk
1389 management process. This monitoring and review activity should address (but not be limited to):
1390 - legal and environmental context;

1391 - competition context;
1392 - risk assessment approach;
1393 - asset value and categories;
1394 - consequence criteria;
1395 - risk evaluation criteria;
1396 - risk acceptance criteria;
1397 - total cost of ownership; and
1398 - necessary resources.
1399 The organization should ensure that risk assessment and risk treatment resources are continually
1400 available to review risk, to address new or changed threats or vulnerabilities, and to advise
1401 management accordingly.
1402 Risk management monitoring can result in modifying or adding the approach, methodology or tools
1403 used depending on:
1404 - changes identified;

1405 - risk assessment iteration;
1406 - aim of the information security risk management process (e.g. business continuity, resilience to
1407 incidents, compliance); and
1408 - object of the information security risk management process (e.g. organization, business unit,
1409 information process, its technical implementation, application, connection to the internet).
1410 Output: Continual relevance of the information security risk management process to the organization’s
1411 business objectives or updating the process

ISO/IEC 27005:####(E)
Editors’ Note: As the editing group considers the main body is stable the questions of annexes are to be
worked out.
The following references to Annexes (partly non-existing) has been identified in 1st WD:
Currently in 2WD
Annex A (informative) Information security risk cycle
Annex B (informative) Information security risk criteria values - examples
Requests for Annexes marked in the text (partly non-existing)

5.5.1 "Further considerations on risk criteria can be found in Annex ."
7.1 "Information on information security risk assessment methods and techniques can be found in
[Annex ZYX]. Additional information on risk assessment techniques can be found in IEC 31010.
7.2.1 "More information on risk identification methods can be found in Annex ZYX"
7.3.2 "More information on risk analysing methods can be found in Annex YYY."
7.4.1 "To evaluate risks, organizations should compare the assessed risks (selected methods or
approaches are discussed in Annex XYZ) with the risk criteria defined during the context
establishment.
7.3.4 Rapporteurs Note: There is an expectation expressed by expert to describe the topic in more
details in an annex. One possible source for this existing Annex E from 27005:2018 "Information
security risk assessment approaches"
Requests pending from Study Period
1. An annex with examples of trigger criteria and categories leading to a partial update or a
complete risk assessment.
2. Risk, risk source, and risk owner for the management plan
3. Visualization method about chain of event, risk source and risk measures
Annexes proposed to be created

Proceed with such a mapping of controls (the final, agreed ISO 27002 control library) to a set of
as-yet-to-be-agreed list of threats.
The ISF would be happy to assist in such mapping should this idea be supported and a commonly-
agreed threat list be available.

Experts are asked to:
1) comment on the necessity of annexes mentioned above,
2) if the answer is positive for a given annex, indicate a source (with possibility to use the content of
annexes present in 3rd edition of ISO/IEC 27005:2018, or developed along with the revision which had
been cancelled in 2015 (see WG1 N 202), or any new source,
3) provide a proposal for a new annex content which deemed to be necessary.
1412

1413 Annex A
1414 (informative)
1415
1416 Information security risk cycle
1417 [Editors’ Note: This Annex has been introduced by the acceptance of the expert proposal to re-introduce
1418 the concept of risk cycle and how it influences the risk acceptance criteria, present in previous revision.
1419 Experts are asked to further contribute]
1420
1421 Figure A.1 — Information security risk cycle
1422 As the figure A.1 shows, any event in relation to information affects a supportive asset first. Typically it
1423 is:
1424 1. the medium on which information is stored;

1425 2. the network channel through which the information is communicated from one point to another; or
1426 3. the system that process the information.
1427 Information itself is seldom hit directly. This is because before the information is collected the attacker
1428 has to access the asset and manipulate it before being able to breach information security. Furthermore,
1429 accidental or natural events can repeatedly happen without taking into account the real effect.
1430 Deliberate events, however, happen ‘at purpose’ and the initiator (the threat agent) waits or (or not) for
1431 a feedback on the effect to consider whether the event will be restarted it as is or with modification to
1432 make sure the objectives are achieved.

ISO/IEC 27005:####(E)
1433 When dealing with risks, organization should consider this cycle and the ‘intent’ of the risk source.
1434 When managing the risks, it is dangerous to remain focused only on the ‘asset’ or ‘victim’ side as we
1435 commonly do. It is probably one of the reasons why security is one or two wars ‘behind’ the attacker.
1436 We should regularly use the aggressor’s way of thinking to be better prepared. Following this risk cycle
1437 is a way to follow the aggressor’s mind.
1438 Organizations should try to break this cycle at least once in each side: the ‘Threatening environment’
1439 and the ‘Consequence’ sides. The aim is to prevent the event results in consequences on the
1440 organization's stakes, values and strategic objectives. It’s good to remember that these three issues are
1441 at the basis of the information classification.
1442 The following risk elements should be taken into account when identifying and assessing risks:
1443 ¾ Threat (see Annex XXX)

1444 ¾ Risk source: can be human or natural (see Annex XXX) and his/her motivation, skills and
1445 resources
1446 ¾ Threat origin: external or internal to the scope of the risk management activity (and ISMS)
1447 ¾ Vulnerability(ies) (see Annex XXX)
1448 ¾ Target of the event
1449 ¾ Event
1450 ¾ Extent or severity of the event on the aimed target
1451 o consequence of the event on information and information processes
1452 o Consequences of the event on business (operational and tactical) objectives
1453 o Consequences (Losses) on the stakes, values and business strategic objectives.
1454 ¾ Information transmission back to the treat agent so that a decision can be made his/her own
1455 decision to pursue the objectives and how to achieve them effectively.
1456
1457

1458 Annex B
1459 (informative)
1460
1461 Information security risk criteria values - examples
1462 B.1 Criteria related to risk assessment
1463 B.1.1 Risk assessment general considerations
1464 In general, personal uncertainty dominates information risk assessment, and different assessors will
1465 exhibit differing tendencies to uncertainty when interpreting points on likelihood and consequence
1466 scales. The reference scales should relate the consequence, likelihood and risk categories to common
1467 unambiguously specified objective values, possibly expressed in terms such as financial loss in
1468 monetary units and notional frequency of occurrence in a finite period which are specific for the
1469 quantitative approach.
1470 Particularly where the qualitative approach is adopted, risk assessors should undergo training and
1471 periodic practice against an anchoring reference scale to maintain the calibration of their judgement.
1472 B.1.2 Quantitative approach
1473 The level of risk is represented by the product of the likelihood and the expected consequences of an
1474 event.
1475 The endpoints of a likelihood scale should be defined in terms that are practical for the organization to
1476 manage and for all interested parties to understand. Thus, the highest finite likelihood point on the
1477 scale might usefully be defined in terms of the maximum rate at which the organization can respond to
1478 events, and the lowest finite point in terms of no longer than the duration of the organization's long
1479 term strategic planning. This can keep the range of likelihoods expressed by the finite range of the
1480 likelihood scale comprehensible to all interested parties, and can also ensure that the individual
1481 categories themselves within that range do not each represent an excessive range of likelihoods.
1482 Likelihoods above and below the limits of the scale may usefully be expressed in terms of "greater than
1483 scale maximum" and "less than scale minimum", clearly indicating thereby that likelihoods beyond the
1484 limits of the defined scale are extreme cases to be considered exceptionally (possibly using special "out
1485 of bounds" criteria).
1486 The increments between the categories of a likelihood scale should be selected with reference to those
1487 of the chosen consequence scale to avoid the range of risk falling into each risk category being
1488 excessive. For example, monetary consequence scales are typically based on factors of ten (10--1000,
1489 1000-10,000 etc.) but if both likelihood and consequence scales have increments of a factor of ten, each
1490 of the resultant risk categories will represent a one hundred to one range of risk, which is likely to be
1491 too wide for prioritisation of risks across the organization as too many risks may fall into each category.
1492 For this reason, depending on the context it may be advantageous to make the increments of a
1493 likelihood scale smaller than those used on the associated consequence scale.
1494 If likelihood and consequence are represented by the indices of an exponential scale (i.e. the logarithms
1495 of the values on the scale), these should be summed. The equation is then:
1496 Level of risk value = level of likelihood value + level of consequence value
1497 In Table B.1, an example of a high frequency event would be a computer assisted event password attack
1498 or a distributed denial of service attack from a botnet. Indeed, attack frequencies can be much higher.
1499 An example of a low frequency event would be volcanic eruptions. Even if an event is predicted to
1500 happen only once per century that does not mean it would not occur during the lifetime of an ISMS.
1501 Table B.2 shows an example of logarithmic consequence scale.

ISO/IEC 27005:####(E)
1502
Approximate average frequency Scale value

One hundred times a second 11
Every second 9
Every hour 6
Every 8 hours 5
Twice a week 4
Once a month 3
Once a year 2
Once a decade 1
1503 Table B.1 — Example logarithmic likelihood scale
1504
Consequence (a loss of) Scale value

£1 000 000 6
£100 000 5
£10 000 4
£1 000 3
£100 2
£10 1
£1 or less 0
1505 Table B.2 — Example logarithmic consequence scale
1506 When considering multiple instances of an event, a reasonable approximation for aggregate exposure
1507 over time can often be derived by multiplying the consequence level of a single event by its expected
1508 number of occurrences in some chosen period. This is generally referred to as an aggregate loss
1509 expectancy. If the period chosen is one year, it is often called an annualized loss expectancy.
1510 Annualized loss expectancy is commonly expressed in monetary terms, but need not be so (for example,
1511 a hospital might use a patient recovery ratio).
1512 Aggregate loss expectancy can be modelled using a Monte Carlo simulation. This runs multiple
1513 scenarios (typically 10,000) of the risk being assessed to indicate the possible outcomes. The results of
1514 this simulation are typically modelled as a Poisson distribution or a loss exceedance curve. A Poisson
1515 distribution is a histogram that represents the likelihood with which a certain aggregate loss occurs.
1516 Each bar represents the count of the scenarios from the Monte Carlo simulation that have produced a
1517 similar aggregate loss expectancy. The higher the bar, the more likely it is to occur. Figure B.1 shows a
1518 representation of a Poisson distribution.

1519
1520 Figure B.1: Example of a Poisson distribution
1521 A loss exceedance curve (LEC) is a chart that demonstrates the likelihood (as a percentage or
1522 probability) of aggregate loss occuring in a given amount of time. The horizontal axis (X) displays the
1523 aggregate loss and the vertical axis (Y) shows the probability of the loss occurring. As the likelihood
1524 decreases, the consequence increases, meaning that it is very unlikely to have aggregate losses that are
1525 very high, although they remain possible. On the same graph, organizations can plot their ""risk
1526 appetite"", by drawing a curve to display the amount of aggregate loss (or risk) that they can accept.
1527 These two curves can then be compared and analysed to identify if risk exceeds, meets, or is below
1528 acceptable levels (i.e. the organization can afford to take more risk). If the curve for aggregate loss is
1529 above the curve for risk appetite, then the risk will need to be treated. If the curve for aggregate loss is
1530 below the curve for risk appetite, then the organization can afford to take on more risk, or consider
1531 spending less on controls. Figure B.2 shows a representation of a loss exceedance curve. In this
1532 example, there is a 70% probability that the consequence will be £50,000 and a 15% probability that
1533 the aggregate loss will be £100,000. The risk appetite allows for a 70% probability of an aggregate loss
1534 of £20,000, meaning that treatment will be required here, but that no treatment is required at the
1535 higher end of the scale, as the risk appetite exceeds the assessed aggregate loss.

ISO/IEC 27005:####(E)
1536
1537 Figure B.2 Example of a loss exceedance curve
1538 B.1.3 Qualitative approach
1539 Alternatively, qualitative approach to value risk criteria can be used.
1540 The utility of qualitative scales and the consistency of risk assessments that derive from them depend
1541 entirely on the consistency with which the category labels are interpreted by all interested parties. The
1542 levels of any qualitative scale should be unambiguous, its increments should be clearly defined, the
1543 qualitative descriptions for each level should be expressed in objective language and the categories
1544 should not overlap with each other.
1545 Table B.3 presents an example of qualitative approach.

Consequence ® Very Very
High Medium Low
Likelihood ¯ high low
Very high VH VH H H M
High VH H H M L
Medium H H M L L
Low M M L L VL
Very low L L L VL VL
1546 KEY VL = very low, L = low, M = medium, H = high, VH = very high.
1547 Table B. 3 Example of qualitative approach to risk criteria
1548 The design of a qualitative risk matrix should be guided by the organization’s risk acceptance criteria
1549 (see 6.5.2 and C.2). For example, an organization might be more concerned about extreme
1550 consequences despite their unlikely occurrence, or primarily concerned about high frequency events
1551 with lesser consequences.
1552 When designing a risk matrix, whether qualitative or quantitative, it should be noted that an
1553 organization's risk profile is normally asymmetrical. Trivial events are generally the most frequent and
1554 expected frequency typically reduces as consequences increase, culminating in very low likelihoods of
1555 extreme consequences. It is also uncommon for the business exposure represented by a high likelihood
1556 low consequence event to be equivalent to that represented by a low likelihood high consequence

1557 event. Therefore, although a risk matrix that is symmetrical about its low/low to high/high diagonal
1558 might seem easy to create and naively acceptable, it is unlikely to represent accurately any
1559 organization's real risk profile, and may therefore yield invalid results. To ensure that a risk matrix is
1560 realistic and can fulfil the ISO/IEC 27001 requirement for continuous improvement, the reasoning both
1561 for allocating each category to the likelihood and consequence scales and the risk matrix and regarding
1562 how the categories accord with the organization's risk profile should be documented when the scales
1563 and matrix are defined or amended.
1564
1565 The utility of qualitative scales and the consistency of risk assessments that derive from them depend
1566 entirely on the consistency with which the category labels are interpreted by all interested parties. The
1567 levels of any qualitative scale should be unambiguous, its increments should be clearly defined, the
1568 qualitative descriptions for each level should be expressed in objective language and the categories
1569 should not overlap with each other.
Editors’ Note: Experts are requested to further contribute to the following items due to the expert
proposal:
- The use of RAG (red/amber/green) should be properly explained (as a final simplification for
reporting to the executive) and not advocated as a basis for risk management assessments even
at strategic level, where (as this simple analysis demonstrates) it conclusively fails.
1570
1571 B.2 Risk acceptance criteria

1572 The criteria for the acceptance of risk can simply be a value above which the risk is deemed to be
1573 unacceptable. For example, in Table B.3, the value M can be chosen. Thus all risks with a value of VL, L
1574 or M would be considered by the organization to be acceptable and all risks with a value of H or VH
1575 would be considered as being unacceptable. If money/time is used as the unit of risk then the
1576 corresponding level of acceptable risk, using Table B.1 and Table B.2 can be the value 6, which
1577 corresponds to an annual loss expectancy of £10 000/year.
1578 When producing a diagram showing the organization's risk tolerance, as in Table B.3, it can be
1579 presented as a "heatmap", with each segment of the chart colour-coded using a Red/Amber/Green
1580 colour range to emphasize the organization's tolerance of each combination of likelihood and
1581 consequences.
1582
1583

ISO/IEC 27005:####(E)
1584 Bibliography
1585 [1] ISO/IEC 27001, Information Security Management Systems - Requirements
1586 [2] ISO/IEC 27003, Information security management system implementation guidance
1587 [3] ISO/IEC 27004, Information security management — Measurement
1588 [4] ISO 31000, Risk management - Guidelines
1589

ISO-IECJTC1-SC27-WG1 N2154 Second Working Draft For ISOIEC 27005 Information Security Risk Management

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ISO-IECJTC1-SC27-WG1 N2154 Second Working Draft For ISOIEC 27005 Information Security Risk Management

Uploaded by

Copyright:

Available Formats

ISO/IEC JTC 1/SC 27/WG 1 N 2154

ISO/IEC JTC 1/SC 27/WG 1

Document type: Working Draft Text

Title: Second working draft for ISO/IEC 27005 Information security

Status: This document is circulated for information and action.

Date of document: 2019-11-13

Source: Project Editors 27005 (ANDRUKIEWICZ Elzbieta: RUMPEL,

Expected action: COMM

Action due date: 2019-02-28

Email of convenor: edwardj7@msn.com

Committee URL: https://isotc.iso.org/livelink/livelink/open/jtc1sc27wg1

4 Information security, cybersecurity and privacy protection —

7 2nd Working Draft

16 © ISO 2019, Published in Switzerland

21 ISO copyright office

© ISO 2019 – All rights reserved 1

2 © ISO #### – All rights reserved

125 — xxx xxxxxxx xxx xxxx

The expert expresses the following concern:

© ISO 2019 – All rights reserved 3

4 © ISO #### – All rights reserved

152 The intended recipients of this document are:

- how the standard relates to the previous edition (ISO/IEC 27005:2018);

© ISO 2019 – All rights reserved 5

159 Information security, cybersecurity and privacy protection —

167 2 Normative references

173 3 Terms and definitions

177 — IEC Electropedia: available at http://www.electropedia.org/

178 — ISO Online browsing platform: available at https://www.iso.org/obp

6 © ISO #### – All rights reserved

179 3.1 Terms related to information security risk

188 [SOURCE: ISO 31000:2018]

203 [SOURCE: ISO 31000:2018]

© ISO 2019 – All rights reserved 7

211 Note 3 to entry: An event can be a risk source.

212 [SOURCE: ISO 31000:2018]

218 Note 2 to entry: Consequences can be expressed qualitatively or quantitatively.

220 [SOURCE: ISO 31000:2018]

238 [SOURCE: ISO 31000:2018]

8 © ISO #### – All rights reserved

252 [SOURCE: ISO Guide 73:2009, 3.3.1.3]

267 — governance, organizational structure, roles and accountabilities;

273 — the organization's culture;

274 — standards, guidelines and models adopted by the organization;

275 — form and extent of contractual relationships.

© ISO 2019 – All rights reserved 9

284 [SOURCE: ISO 31000:2018]

287 risk (3.1.1) remaining after risk treatment (3.2.6)

295 3.2 Terms related to information security risk management

320 Note 2 to entry: Risk analysis includes risk estimation.

321 [SOURCE: ISO Guide 73:2009, 3.6.1]

10 © ISO #### – All rights reserved

327 [SOURCE: ISO Guide 73:2009, 3.7.1]

333 — taking or increasing risk in order to pursue an opportunity;

334 — removing the risk source;

335 — changing the likelihood (3.1.7);

336 — changing the consequences (3.1.4);

338 — retaining the risk by informed choice.

359 — an input to decision making, not joint decision making.

© ISO 2019 – All rights reserved 11

360 4 Structure of this document

362 Input: Identifies any required information to perform the activity.

363 Action: Describes the activity.