The process of revising ISO/IEC 27001


The process of revising ISO/IEC 27001:2005 started in 2008, yet the new edition was only published in 2013. This web page documents that revision process. It is intended as a warning to the standards development community. If you are just interested in the results of the revision, our page on the 2013 standard is what you need to read.

There is no doubt that ISO/IEC 27001 and 27002 will be revised again. Hopefully the next revision process will be more efficient and timely. It should be; the internal processes within SC 27 are being radically revised to follow the official ISO and IEC approach to standards development. Whether this will actually result in a more timely standard and perhaps a better standard remains to be seen.

There were three major influences on the revision process:

  • ISO directives Annex SL (High level structure and identical core text for management system standards), which has caused ISO to adopt a new structure for ISO/IEC 27001. (This was originally called Draft Guide 83, but in April 2012 it was published as a annex in the revised ISO directives.)
  • ISO 31000 (Risk management - principles and guidelines), which has caused ISO to rethink its approach to risk assessment
  • Practical experience in applying ISO/IEC 27001: 2005.

The revision process

ISO JTC 1 SC 27 WG 1, the committee responsible for ISO/IEC 27001 met twice per year starting in 2008, firstly in April/May and secondly in October. Having decided to revise the standard, co-editors were assigned. Each National Body (e.g. BSI in the UK), and there were around 42 of these with interests in ISO/IEC 27001, comments on the standard. Comments are presented in a manner that requires precise identification of the subject, an explanation of why the comment is being made and proposed changes. These are then collated by the co-editors who guide the members of WG 1 through them in the international meetings and moderate the discussion amongst the assembled national experts in order to achieve a consensus resolution of each one. Afterwards they produce a new draft and most importantly a disposition of comments so that each National Body knows whether its comments have been accepted or not, and if not, why not. This is tough work. As a popular and important standard there can be hundreds of comments. At our meeting in Nairobi, for example, there were over 470 comments on the first Committee Draft which gave rise to a 137 page long Disposition of Comments.

The version of a standard presented for final approval is called a Final Draft International Standard (FDIS). Prior to the FDIS, we had a DIS (Draft International Standard), which was publicly available, and two Committee Drafts (CDs). Prior to the CDs, the previous drafts were Working Drafts (WDs) and there were four of them. The meetings at which these documents were discussed, together with their significant outcomes were:

Location Date Result Significant outcomes
Beijing, China April 2009 WD1 Decision to revise ISO/IEC 27001:2005; call to dump Annex A
Redmond, USA October 2009 WD2 Call to retain Annex A; agreement to align with IS 31000
Melaka, Malaysia April 2010 WD3 Agreement to adopt Guide 83; decision on Annex A deferred to Berlin; first consensus thoughts on alignment with IS 31000
Berlin, Germany October 2010 WD4 Decision taken to retain Annex A as a cross-checking mechanism; first consensus thoughts on alignment with Guide 83; existing risk assessment requirements challenged
Singapore April 2011 CD1 Decision to loose the detailed risk assessment requirements; agreement on how to align with ISO directives Annex SL
Nairobi October 2011 CD2 Removal of duplicate requirements and further work on the revised risk assessment requirements
Stockholm May 2012 CD3 Making sure all are happy with the revised risk assessment requirements and ISO directives Annex SL; confirmation that Annex A is here to stay
Rome October 2012 DIS Both ISO/IEC 27001 and 27002 are progressed to draft international standards status
Sophia Antipolis April 2013 FDIS Both ISO/IEC 27001 and 27002 are progressed to final draft international standards status
Incheon, South Korea October 2013 BRM Both ISO/IEC 27001 and 27002 are approved for publication

BRM stands for Ballot Resolution Meeting. This is a go/no-go decision on publication, only minor editorial changes are permitted.

ISO directives - Annex SL

Annex C to ISO/IEC 27001:2005 compares its requirements with those of ISO 9001 and ISO 14001. The fact that there are many similarities is quite intentional and was one of the original objectives in creating BS 7799-2:2002 as it eases an organisation’s ability to construct and operate integrated management systems. However, there are subtle differences which have reputedly made it difficult for some organisations.

Accordingly, ISO’s Technical Management Board (TMB) commissioned the Joint Technical Coordination Group (JTCG) to establish a new standard for developing management system standards. The result was Guide 83, which following a number of iterations, was published (April 2012) as Annex SL in the revised ISO directives.

It specifies a high level structure for all management system standards, and where requirements are deemed to be identical there is identical core text.  There are rules for the integration of discipline specific requirements.

The figure shows the mapping between the 2005 version of ISO/IEC 27001 and the current edition, which conforms to that specified by Annex SL.

Much of sections 4, 5, 7, 9 and 10 consists of the Annex SL identical core text with very little additional information security specific text. The bulk of the information security specific text was originally put into Section 8 - Operations, but in Stockholm it was moved to Section 6. There was only a small majority of National Bodies in favour of this move but following reconsideration in Rome it was agreed to keep it there. However, we note that in accordance with the Laws of Commutation and Simultaneity, where a requirement is placed in a standard does not matter. The order of requirements does not reflect their importance or imply the order in which they are to be implemented, although it may impact upon their understandability.


ISO 31000

ISO 31000:2009 is a new standard on risk management. It is generally applicable to all disciplines.

The standard contains some familiar terms, such as event, impact and likelihood; but also some unfamiliar ones, such as consequence and source of risk. Most noticeable, however, is the absence of the familiar information security terms: assets, threats and vulnerabilities. Another difference is that ISO 31000 lists seven ways to treat risk, as opposed to the four ways in ISO/IEC 27001:2005. It also uses the ISO Guide 73 definition of control, namely a measure that modifies risk.

Perhaps unsurprisingly, we found that it was possible to recast the Brewer-List method without using assets, threats and vulnerabilities, and drew the conclusion that it was is possible to conduct a risk assessment without using assets, threats and vulnerabilities. This is now generally accepted and since CD1 there has been no mention of assets, threats or vulnerabilities in the standard.

Making sure it will work

As part of our contribution to the ISO work, Gamma transitioned a real ISMS to CD1, CD2, CD3 and the DIS, and we therefore knew the types of challenges that organisations would face when converting existing ISMS to the new standard.

We also produced detailed mapping tables that show how the requirements of the new standard map onto the old.

What about the future?

There are going to be further revisions of ISO/IEC 27001. Hopefully performed in a more efficient and timely manner.

One thing that is obvious from the story above is that there were several changes of direction, each of which delayed the revision by at least six months. Secondly, despite the involvement of National Bodies at the Working Draft stage of the revision process it still took three Committee Drafts to satisfy the national experts shadowing WG 1. This should not happen. Editors and co-editors are supposed to be experts who can work together quickly to produce a draft document which is then approved for wider circulation by the representatives of National Bodies serving on the Working Group.

In future WG 1 will be adopting a new method of working where Working Drafts and first Committee Drafts will be produced by co-editors working together, with other Working Group members contributing and approving as independent experts. National Bodies will express their views through ballots and related comments only at Committee Draft and beyond. Where differences of opinion exist, wherever possible they will still be resolved. But if there is general consensus on a solution, remaining opposition will be noted and accepted without delaying future progress.

It remains to be seen how well WG 1 will adapt to this new process.

Observations about requirement standards

Whilst we were at the Singapore meetings, we and some other National Body experts noticed that there appeared to some underlying rules, or laws that governed the optimum way of writing requirements standards. They therefore constitute a set of principles that all management system standards should follow. For example, it now seems generally recognised in WG 1 that an ISMS is not built by implementing the requirements of ISO/IEC 27001 (or indeed any other management system standard) in the order that they are presented in the standard. The order of implementation does not matter and the end result is that for conformance all requirements must be satisfied simultaneously. There are five such laws:

Since then, we have discovered a sixth law that concerns the relationship between Discipline-specific and Identical Core Text requirements.

The five laws identified in Singapore

Note: the contents of this section are enclosed in “collapsible panels” . Click on a panel to reveal/hide its contents.

The law of commutation

The order in which requirements are presented in a requirements standard does not imply their order of implementation.
Thus, a requirements standard that consists of three requirements presented in the order A, B, C must be semantically equivalent to a standard that presents the same three requirements in the order B, C, A or indeed in any other order.

The law of simultaneity

Conformance means that all requirements are simultaneously satisfied.

The law of simultaneity follows directly from the law of commutation. It means that in principle a requirements standard can be expressed as a set of mathematically precise requirements conjoined by the logical AND operator. Thus, the specifications discussed above can be recast in the form A ∧ B ∧ C.  (Note that B ∧ C ∧ A ≡ A ∧ B ∧ C.)

Any management system standard should specify what shall be done and not how it shall be done, which may be organisation specific.

The law of explicit alternatives

A requirement expressed using the form “w, x, y and z”, means that for conformance the expression w x   y z must be true. If w, x, y and z are supposed to be alternatives; the requirement must instead be expressed in the form “w, x, y or z” (which implies that w x   y z must be true).
As an example, consider the requirement, which is taken from the identical core text or Section 7.2 (Competence) in the High Level Structure:  “The organization shall ensure these persons are competent on the basis of appropriate education, training or experience”. This means the organization shall ensure that the competence of people is judged on the basis of at least one of the three factors education, training and experience of its ISMS. If instead the identical core text had used the word “and”, it would have meant that for conformance all three factors would have to be true for every person in the organization each and every time when such a judgment of competence is made.

The law of impartiality

Given a requirements standard with two requirements A and B, where B is giving advice on how to implement A, requirement B should be removed.

As an example, consider the two requirements:

  1. The organization shall continually improve the suitability, adequacy and effectiveness of the information security management system.
  2. The improvement shall be performed through the use of the information security policy, information security objectives, audit results, analysis of monitored events, corrective and preventive actions and management review.

Note the use of the conjunction word “and” in (a). This text, which is the identical core text for Section 10.2 (Continual improvement) in the High Level Structure means, in accordance with the law of explicit alternatives, that the organization must be continually improving all three factors suitability, adequacy and effectiveness of its ISMS.

Requirement (a) does not specify how these improvements are to be made. It is therefore semantically equivalent to replace it by an identically worded requirement with the addition of the words “by …” where “…” represents an infinitely long list of all the methods by which an organization could improve its ISMS. The words contained in the second requirement (“information security policy, information security objectives, audit results” etc.) would appear in this list. Thus the second requirement is a proper subset of the first. The law of simultaneity says that for conformance both requirements must be met simultaneously and for that to happen all the factors listed in requirement (b) must be satisfied each and every time an improvement is made.

The effect of the second requirement is therefore to make the first redundant (although if this is what is really meant, it would be more neatly expressed as “The organization shall continually improve the suitability, adequacy or effectiveness of the information security management system through the use of the information security policy, information security objectives, audit results, analysis of monitored events, corrective and preventive actions and management review.”

Note the use of the word “and” in this requirement. It makes it an extremely onerous requirement, as all factors have to be present. The word “or” would be better, as in that case improvement could be made using just one of the quoted factors.  The correct solution is, of course, to delete the second requirement thereby removing the restriction and allowing the organization to decide how best to improve. In other words, a specification standard needs to be impartial.

The law of singularity

Requirements should not be repeated, or otherwise duplicated.
There are numerous cases in ISO/IEC 27001:2005 where requirements are repeated, often with subtle differences. For example, in 4.2.3 (f) it says “[The organization shall] undertake a management review of the ISMS on a regular basis to ensure that the scope remains adequate and improvements in the ISMS process are identified (see 7.1)”. Section 7.1 says that “Management shall review the organization’s ISMS at planned intervals (at least once per year) to ensure its continuing suitability, adequacy and effectiveness. The requirement goes on to list a number of possible changes but does not mention scope. There is clearly a danger here as repeated requirements at best confuse and at worst contradict.

Discipline-specific/common text relationships

Need for discipline-specific requirements

We noted that one cannot rely on an identical core text requirement to guarantee conformance with a specific discipline-specific text requirement — the discipline-specific text requirement must be made explicitly. As an example consider a proposed Discipline-specific requirement:

identify effectiveness measurements for the information security risk treatment plan and specify how these measurements are to be made.

One might be tempted to delete this requirement and rely instead on the Identical Core Text requirements of 9.1 (a):

The organization shall determine what needs to be measured and monitored

and 9.1 (b)

The organization shall determine the methods for monitoring, measurement, analysis and evaluation, as applicable, to ensure valid results.

However, there is no guarantee that the organisation would identify effectiveness measures whist applying 9.1 (a) and 9.1 (b), making such deletion foolhardy. In the DIS, the actual solution was to augment 9.1(a) to say:

The organization shall determine what needs to be measured and monitored, including information security processes and controls

Moreover, 8.3(f) and 9.1 (a, b) is a an example of a special relationship that may exist between a discipline-specific text requirement and an identical core text requirement.
Given two requirements, A and B such that B is a special case of A that is to apply in some special case S then requirement A can be regarded as applying to all cases except case S.

Suppose that there are two requirements, A and B, such that B is a special case of A that is to apply in some special case S.

On application of A to some case c1, let the result be R1, and likewise let the result of applying B to the special case S be QS.

Suppose A is applied first and is applied to {C: c1, c2, c3, … cn, cn+1, …} cases. The result set is:

{R1, R2, R3, … Rn, Rn+1, …}

Suppose B is then applied. The result is:


However, by the Law of Simultaneity, requirement A also applies to case S and therefore the true result set for requirement A is:

{R1, R2, R3, …RS, Rn, Rn+1, …}

The complete result set for application of requirements A and B id therefore the union of (3) and (2), i.e.:

{R1, R2, R3, …RS, QS, Rn, Rn+1, …}

Now, B is a special case of A that applies in case S. This means that in order to satisfy B at the same time as satisfying A, we would have to apply A is the manner prescribed by B. The result is QS. There (4) becomes:

{R1, R2, R3, … QS, QS, Rn, Rn+1, …} ≡ {R1, R2, R3, … QS, Rn, Rn+1, …} ≡ {R1, R2, R3, … RS, Rn+1, …} ∪{ QS}

In other words, despite the existence of the Law of Simultaneity, the special relationship that exists between requirements A and B means that  in practice A can be safely applied to all cases except those in which B applies, and the Law of Simultaneity is still satisfied.