The positive effects of risk are not the primary sources of opportunities

  The new edition of ISO/27002 is now a draft international standard, but why wait? … the new controls are built-into IMS-Smart’s Assistant SAAS offering

Risks and opportunities


Appendix 2 of the ISO/IEC Directives (Part 1 Consolidated ISO Supplement), Annex SL specifies the high level structure and identical core text for all ISO management system standards (MSS). Clause 6.1 requires all MSS to have a clause entitled “Actions to address risks and opportunities”. In ISO/IEC 27001, this clause is numbered 6.1.1 and is reproduced with a small change of wording. This article explores the meaning of this requirement.

What do Annex SL and ISO/IEC 27001 say?

Annex SL requires organisations to plan actions to address risks and opportunities to:

  • give assurance that the management system (MS) can achieve its intended result(s);
  • prevent, or reduce, undesired effects; and
  • achieve continual improvement.

It also requires organisations to plan how to:

  • integrate and implement the actions into its MS processes; and
  • evaluate the effectiveness of these actions.

ISO/IEC 27001 says “ensure” rather than “give assurance that” and uses the original Annex SL word “outcome” rather than the revised Annex SL word “result”. These changes are referred to as deviations A full list of ISO/IEC 27001 Annex SL deviations is given in David Brewer’s book “An introduction to ISO/IEC 27001:2013”..

How do Annex SL, ISO 31000 and ISO/IEC 27001 define risk?

Annex SL defines risk as the “effect of uncertainty”, and notes that an “effect is a deviation from the expected — positive or negative”. Here, the phase “positive or negative” goes with the word “effect”, not the word “deviation”.

ISO 31000, the ISO standard on risk management, uses a slightly different definition: the “effect of uncertainty on objectives”. ISO/IEC 27001 uses the ISO 31000 definition. It does this because, during the revision of the 2005 edition of ISO/IEC 27001, the responsible standards committee, JTC 1 SC 27 WG1Joint Technical Committee 1 Sub Committee 27 Working Group 1, chose to align the revised standard with ISO 31000 and thereby deviate from the Annex SL definition.

Why are they different?

When the committee responsible for Annex SL discussed the matter, some members declared a preference for using the ISO 31000 definition whilst others did not. One of the issues is that some MSS are compelled to abide by the regulatory definition of risk for their discipline, which is different. Others consider that the ISO 31000 definition is constrained by the phrase “on objectives”. This is because Annex SL uses the term in the context of “XXX objectivesAnnex SL uses the term XXX throughout as a place-holder for the MSS discipline. Thus in ISO/IEC 27001, XXX becomes information security; in ISO 9001, XXX becomes quality, etc.”, being the objectives set by the organisation in fulfilment of Clause 6.2 (XXX objectives). They conclude that this implies that risks can only exist is there is some stated objective. However, since ISO 31000 is not a MSS, it does not use the XXX convention and therefore the term “objective” takes on whatever meaning is appropriate to the context in which the term “risk”. Unfortunately, in the context of a MSS for some experts, the only appropriate meaning is XXX objectives, which is why the problem occurs. Nevertheless, one way out of this conundrum is to include objectives that are implied by the MSS. In the case of ISO/IEC 27001, there is a requirement to identify risks associated with the loss of confidentially, integrity, and availability of information within scope of the ISMS. Thus, ISO/IEC 27001 implies that an objective of all ISMS is the preservation of confidentially, integrity, and availability of such information. Moreover, if you use the event-consequence approach to risk assessment, the prevention, and detection of each event, and reaction to each consequence can also be considered to be an objective.

What are opportunities?

Annex SL does not define the term “opportunity”. The term therefore takes on its Oxford English Dictionary meaning: “a time or set of circumstances that makes it possible to do something.”

ISO 31000 does not say much about opportunities apart from:

  • point out that organisations may wish to increase risk in order to pursue an opportunity; and
  • a positive effect of risk is a source of opportunity.

Some experts have interpreted this as meaning that the positive effects of risk are the only sources of opportunity. This is not trueRisk is only one source of opportunity that organisations can leverage. Other sources which can be identified, created or otherwise discovered include: innovation, new technologies, new standards and regulations, political and societal changes, market demand for products and services, …. Others have dismissed the positive effects of risk as, in their discipline, the only negative effects are considered, e.g. for information security — but is this true?Consider the implied objective of all ISMS — the preservation of confidentiality, integrity, and availability of information within scope of the ISMS. Since the only effect of any deviation can be to compromise the-confidentiality, integrity, and availability of information, all effects of uncertainty on that objective are negative, and therefore the answer is yes.

But are opportunities important?

For organisations, yes — the seizure and creation of opportunities is the means by which organisations achieve their objectives. However, often the bolder the approach taken to the fulfilment of objectives, the greater the risks and these risks need to be managed. This is the meaning of the advice given in ISO 31000 about increasing risk to pursue and opportunity. From the perspective of information security, more often than not, the opportunities that give rise to increased information security risk are not caused by the positive effects of information security risk but by the pursuit of the organisation’s business objectives. Thus, the importance of opportunities becomes most apparent when a management system is considered in the context of the organisation’s entire operations, not from the perspective of a single discipline, such as information security. Opportunity exploitation better belongs to disciplines such as marketing and promotions, and research and innovation.

What are the origins of the requirement?

Prior to the introduction of Annex SL (2012), MSS used the concept of preventive action. The idea here was to take action to prevent the occurrence of a future nonconformity. It was then recognised that this was simply risk management and it was decided to treat it as such. However, having introduced the concept of risk it was realised that there would be an imbalance without the introduction of opportunitiesThe need to incorporate opportunity management in parallel with risk management was recognised long before it was introduced into Annex SL, see the paper by Brewer, Nash and List, published in 2005, and our page on IMS architecture.

How does ISO/IEC 27001 deal with information security risk?

This Annex SL requirement presented a challenge to JTC 1 SC27 WG1 in producing the 2013 edition of ISO/IEC 27001. This ISMS requirements standard has always embraced risk management ever since it emerged as British Standard (BS) 7799-2:1998. At first view there is a collision between the Annex SL, Clause 6.1 requirement and the ISO/IEC 27001 requirements to assess and treat information security risk. The solution was to regard the Annex SL requirement as applying to risks in general and add two discipline specific clauses to deal with information security risk assessment and risk treatment. This gave rise to the familiar ISO/IEC 27001 structure for its Clause 6.1:

  • 6.1.1 General (being the slightly modified variant of Annex SL Clause 6.1 as described above);
  • 6.1.2 Information security risk assessment; and
  • 6.1.3 Information security risk treatment.

Brewer, in his book “An introduction to ISO/IEC 27001:2013” explains (page 43 of the paperback edition) the relationship between the various parts of Clause 6.1.1 and the following two clauses, concluding that Clauses 6.1.2 and 6.1.3 are merely special cases of the assessment and treatment components of Clause 6.1.1 that apply when the risk concerns information security.

Scope of Clause 6.1.1 – a conundrum

There is a clear implication here, by the wording of these requirements, that these risks (and opportunities) only concern the management system and are not information security risks, those risks being addressed by other requirements (principally Clauses 6.1.2 and 6.1.3). Whilst this is certainly one way to interpret these requirements, the interpretation is shaken once preservation of confidentiality, integrity and availability is introduced in Clause 4 as an issue or requirement. Thus, one might interpret Clause 6.1.1 as applying to all risks, i.e. risks that concern the management system and information security risks. Whilst at first view the existence of these differing interpretations may appear a little worrying, the wording of Clauses 6.1.2 and 6.1.3 ensures that both interpretations would lead to exactly the same outcomes.


Clauses 6.1.1 a) to c) concern risk identification and correspond to Clause 6.1.2 for the identification of information security risk, whilst Clause 6.1.1 d) concerns risk treatment and corresponds to Clause 6.1.3 for the treatment of information security risk. Clauses 6.1.2 and 6.1.3 may be regarded as the way to implement Clauses 6.1.1 a) to d) when the risk that is being considered is an information security risk.

Thus, in practice:

  • Clauses 6.1.1 a) to d) only apply when the risk being considered is not an information security risk, or if it is an opportunity that is being considered; and
  • Clauses 6.1.2 and 6.1.3 only apply when a risk is being considered and it is an information security risk.

The effect of Clause 6.1.1 e) 1) is to ensure that if there is an issue or requirement that affects the smooth running of the management system, then its resolution will be built into the management system processes.

However, for information security risk, the information security controls that are specified by the risk treatment plan are already part of the management system (see Chapter 1 - Information Security Management Systems) and therefore Clause 6.1.1 e) 1) only has any effect in the case of opportunities and non-information security risks.

Likewise, the purpose of Clause 6.1.1 e) 2) is to ensure that the actions determined by Clause 6.1.1 d) are evaluated for effectiveness, which, in the case of the risk treatment plan, is covered by Clause 9.1.

Thus, to all intents and purposes, the interpretation that Clause 6.1.1 only applies to the management system is perfectly sound.

Extract from “An introduction to ISO/IEC 27001:2013” by kind permission of the author, Dr David Brewer

ISO/IEC 27003 presents a similar argument.

Will the revised edition of Annex SL shed light on this?

Yes it will. The revised Annex SL, Appendix 3 gives guidance to MMS writers and ISO editors and in revising MSS subsequent to its publication, organisations might see the results of applying that advice. However, the new guidance does not invalidate what is in ISO/IEC 27001:2013, it merely offers alternative solutions.

The new guidance points out that :

  • whilst risk can generate a positive effect, risk is only one source of opportunity that users can leverage;
  • if a formal approach to risk management is required, MSS writers are at liberty to put their discipline specific risk management requirements in Clause 6 (as in the case of ISO/IEC 27001), Clause 8 (as in the case of ISO 22301) or both; and
  • if MSS writers wish to include discipline specific requirements for opportunity management, one approach could be to mirror or invert the guidance provided by 31000This is the approach taken by Brewer, Nash and List, published in 2005, and our page on opportunity exploitation plans. However, it is not a simple inversion..

What does this mean for me?

If you have an integrated management system, you would be excused for thinking that the different MSS definitions of risk will cause problems, but in practice they do not — at least that is the experience of all the integrated management system managers that IMS-Smart has spoken to. One of the reasons for this is that their organisations take an organisation-wide, discipline-independent approach to risk management.

Likewise, if you just have an ISMS, the definition of risk should not influence the way in which you interpret the requirements of Clause 6.1. Just regard “…on objectives” as referring to the fulfilment of whatever objective is impeded by the risk in question (i.e., just as intended by ISO 31000), and not necessarily to any specific Clause 6.2 information security objective. Moreover, if you take an ISO 31000 approach to the fulfilment of Clauses 6.1.2 and 6.1.3 (as would be the case, for example, if you use IMS-Smart On-Line) you can apply that method to Clause 6.1.1 as well. Some organisations, for example, have risk treatment plans for non-information security specific events such as lack of resource. Considering prevent, detect, and react is a good discipline to use for risk management, irrespective of the nature of the risk.

One final point is to reflect on innovation, changes in technology, and suchlike, not as sources of risk but as sources of opportunity. Opportunities for MS improvements feed into Clause 10.2 and are dealt with there. However, Annex SL has no clause for the treatment of other opportunities, such as exploiting an organisation’s MS certifications for business gain. Nevertheless, there is nothing to stop an organisation from doing so. Using a structured approach to opportunity exploitation is encouraged.