ISO 27001:2013: What has changed? - Part II


ISO 27001

Information Security Risk Assessments in ISO/IEC 27001:2013

ISO/IEC 27001:2013 aligns with the principles and guidance given in ISO 31000 (risk management). Therefore, organisations with integrated management systems can apply the same risk assessment methodology across several disciplines. But what are the likely differences between this approach and the risk assessments conducted as part of ISO 27001:2005?

Let's remind ourselves of what an 'asset-based risk assessment' is about.

ISO 27001:2005 and "asset-based risk assessment" methodology

The first step in a risk assessment was the identification of all information assets in the organisation. That is to say, all the assets which may affect the security of information in the organisation. A value was assigned to each asset in terms of the worst-case impact that the loss of Confidentiality, Integrity or Availability (C-I-A) may have on the organisation. In essence, this was intended as an asset prioritisation mechanism. The higher value assets went through to the next stage, namely identification of the threats and vulnerabilities associated with the higher value assets.

Assets could be associated with several threats. And every threat could be associated with several vulnerabilities. With the battlefield now laid out in this way, i.e. with all the organisations assets assigned an appropriate value and the potential impacts in the worst-case scenario determined - the probability of threats exploiting the vulnerabilities was then assessed, along with the impact should this occur, assuming that no controls were in place. A pre-control (or inherent) risk score was then calculated. Risks that scored medium to high were then taken to the next step in the process.

Existing controls or mitigating factors which reduce the impact or probability of each risk were identified. Impact and probability scores were then reassessed to reflect the impact of these controls. Risks with scores that were deemed 'unacceptable' (i.e. above the acceptable risk threshold) were then raised on the Information Security Risk Register, were mitigating actions were tracked by the Information Security team, and reported and escalated.

The end game of this process was to design and implement a coherent and comprehensive suite of information security controls and/or other forms of risk treatment (such as risk avoidance or risk transfer) to address those risks that were deemed unacceptable.

So what does ISO 27001:2013 expect you to do differently to assess Information Risk? Let's start with Clause 6, which is headed Planning.

6.1 Actions to address risks and opportunities

When planning for the information security management system, ISO 27001:2013 says that the organisation "shall consider the issues referred to in 4.1 [Understanding the organisation and its context]". This means determining external and internal issues that are relevant to its purpose. Skip to 5.3 Organisational roles, responsibilities and authorities, and we find that it is the role of "top management" to ensure that the responsibility and authority for roles relevant to information security are assigned and communicated. Specifically, they shall assign responsibility for ensuring that the information security management system (ISMS) conforms to the requirements of the International Standard, and, that the performance of the ISO 27001:2013-compliant ISMS is reported to top management. Note as well that in 6.1.1, actions to address risks and opportunities include in 6.1.1 (c) achieving "...continual improvement'.

Top-level Information security policy in ISO 27001:2013 does not need to establish criteria against which risks will be evaluated – this was the requirement of ISO 27001:2005 4.2.1 b); however, you will still need to define the risk assessment criteria, but not as part of the top-level policy.

In ISO 27001:2013 you need to identify risk owners for each risk.

The 2013 revision does not require a so-called asset-based risk assessment, as outlined above, i.e. which would identify the risks based on assets, threats and vulnerabilities. Rather, in ISO 27001:2013, your organisation can identify risks using some other (perhaps one more familiar to risk managers?) risk methodology. Significantly, in ISO 27001:2013 'asset owners' are replaced by 'risk owners' [See Moving from ISO/IEC 27001:2005 to ISO/IEC 27001:2013 [PDF], published by BSI UK, page 4.]

What exactly is a 'risk owner'? ISO 27000:2014 defines the risk owner as a “person or entity with the accountability and authority to manage a risk". It is worth remembering that the 'asset owners' as defined in ISO/IEC 27001:2005 very often did not have the authority to resolve potential information security risks. The 2013 version addresses this problem by requiring that risk owners approve the information security risk treatment plan and accept of the residual information security risks. Risk owners are also responsible for monitoring risks assigned to them.

Clause 6.1.2, Information security risk assessment, specifically concerns the assessment of information security risk. In aligning with the principles and guidance given in ISO 31000, this clause removes the identification of assets, threats and vulnerabilities as a prerequisite to risk identification. This widens the choice of risk assessment methods that an organisation may use and still conform to the standard. The clause also refers to ‘risk assessment acceptance criteria’, which allows criteria other than just a single level of risk. Risk acceptance criteria can now be expressed in terms other than levels, for example, the types of control used to treat risk. This is the clause that refers to ‘risk owners’ rather than ‘asset owners’ and later (in Clause 6.1.3 f)) requires their approval of the risk treatment plan and residual risks.

Book a free demo of the Cognidox Document Management System

Selection of controls from Annex A is no longer a requirement?

Clause 6.1.3 describes how an organisation can respond to risks with a risk treatment plan; an important part of this is choosing appropriate controls. It is similar to its counterpart in ISO/IEC 27001:2005, however, it refers to the ‘determination’ of necessary controls rather than selecting controls from Annex A.

The 114 controls in the 14 groups listed in Annex A are now used to determine whether any necessary controls have been omitted (see Clause 6.1.3 c)). Annex A has effectively become a reference source against which you can cross-check the controls determined in 6.1.3 b) with "a comprehensive list of control objectives and controls", in order to ensure that " necessary controls are overlooked". - A significant change.

Statement of Applicability (SOA) - is it required and what format?

In keeping with ISO 27001:2005, organisations are still required to produce a Statement of Applicability (SOA). The format of an ISO/IEC 27002:2013 conformant SOA doesn’t need to be different from the previous standard. However, be aware that the control set is different.

Organisations transitioning to ISO/IEC 27001:2013 will be required to update their SOAs. When doing so, you will need to ensure that control implementation strictly conforms to the new wording given in Annex A.

Next time: In ISO/IEC 27001:2013 the requirements for documented information are no longer summarised in a clause of their own, as they are in the ISO/IEC 27001:2005 Standard; instead, they are spread throughout the standard, presented in the clause to that they refer to.

I will list these clauses and what Documented Information you need.

This guest post was written by Michael Shuff. You can email him here.

Find out more about Cognidox Document Management solutions for ISO standards-compliance by downloading our Information Security white paper at

Tags: ISO 9001:2015, Compliance

Paul Walsh

Written by Paul Walsh

Paul Walsh was one of the founders of Cognidox. After a period as an academic working in user experience (UX) research, Paul started a 25-year career in software development. He's worked for multinational telecom companies (Nortel), two $1B Cambridge companies (Ionica, Virata), and co-founded a couple of startup companies. His experience includes network management software, embedded software on silicon, enterprise software, and cloud computing.

Related Posts

8 tips for documenting your SOPs (Standard Operating Procedures)

There are many reasons why organisations need to document their SOPs. From ensuring uniformity in ...

Should you use Microsoft software to build your own digital QMS?

SMEs creating a digital Quality Management System (QMS) will often reach for the most familiar ...

Document Control requirements in ISO 9001:2015; what you need to know

Document control is a key part of any Quality Management System (QMS) and, therefore, a requirement ...

A short guide to non-conformance reports; what, why and how

How do you log and deal with non-conformities so that faulty products don't end up in the hands of ...

Data integrity in life sciences: the vital role of ALCOA principles

Data integrity is central to the safe development and manufacturing of every life-science product ...

Corrective action: why, when and how?

It’s the job of your corrective action process to identify and eliminate the systemic issues that ...