ISO/IEC 27001:2013 ambiguities

ISO/IEC 27001 concerns at least* two distinct classes of risk - ISMS risks and information risks** - causing confusion. With hindsight, the ISO/IEC JTC 1 mandate to require a main-body section ambiguously titled "Risks and opportunities" in all the certifiable management system standards was partly to blame for the confusion, although the underlying issue pre-dates that decision: you could say the decision forced the U-boat to the surface.

That is certainly not the only issue with '27001. Confusion around the committee's and the standard's true intent with respect to Annex A remains to this day: some committee members, users and auditors believe Annex A is a definitive if minimalist list of infosec controls, hence the requirement to justify Annex A exclusions ... rather than justify Annex A inclusions. It is strongly implied that Annex A is the default set. In the absence of documented and reasonable statements to the contrary, the Annex A controls are presumed appropriate and necessary ... but the standard’s wording is quite ambiguous, both in the main body clauses and in Annex A itself.

In ISO-speak, the use of ‘shall’ in "Normative" Annex A indicates mandatory requirements; also, main body clause 6.1.3(c) refers to “necessary controls” in Annex A – is that ‘necessary for the organization to mitigate its information risks’ or ‘necessary for compliance with this standard and hence certification’?  Without explanation, it could mean either.

Another issue with '27001 concerns policies: policies are mandated in the main body and recommended in Annex A. I believe the main body is referring to policies concerning the ISMS itself (e.g. a high-level policy or strategy stating that the organization needs an ISMS for business reasons) whereas Annex A concerns lower-level information security-related policies … but again the wording is somewhat ambiguous, hence interpretations vary (and yes, mine may well be wrong!). There are other issues and ambiguities within ISO27k, and more broadly within the field of information risk and security management.

Way down in the weeds of Annex A, “asset register” is an ambiguous term comprised of two ambiguous words. 

• Having tied itself in knots over the meaning of “information asset” for some years, the committee eventually reached a truce by replacing the definition of “information asset” with a curious and unhelpful definition of “asset”: the dictionary does a far better job of it! 
• In this context, "register" is generally understood to mean some sort of list or database ... but what are the fields and how much granularity is appropriate? Annex A doesn't specify.

But wait, there’s more! The issues extend beyond '27001. The '27006 and '27007 standards are (I think!) intended to distinguish formal compliance audits for certification purposes from audits and reviews of the organization’s information security arrangements for information risk management purposes. Aside from the same issue about the mandatory/optional status of Annex A, there are further ambiguities tucked away in the wording of those standards, not helped by some committee members’ use of the term “technical” to refer to information security controls, leading some to open the massive can-o-worms labelled “cyber”!

Having said all that, we are where we are. The ISO27k standards are published, warts and all. The committee is doing its best both to address such ambiguities and to maintain the standards as up-to-date as possible, given the practical constraints of reaching consensus among a fairly diverse global membership using ISO’s regimented and formal processes, and the ongoing evolution of this field. Those ambiguities can be treated as opportunities for both users and auditors to make the best of the standards in various contexts, and in my experience rational negotiation (a ‘full and frank discussion’) will normally resolve any differences of opinion between them. I’d like to think everyone is ultimately aligned on reaching the best possible outcome for the organization, meaning an ISMS that fulfills various business objectives relating to the systematic management of information risks. 

* I say ‘at least’ because a typical ISMS touches on other classes of risk too (e.g. compliance risks, business continuity risks, project/programme management risks, privacy risks, health and safety risks, plus general commercial/business risks), depending on how precisely it is scoped and how those risk classes are defined/understood. 

** I’ve been bleating on for years about replacing the term “information security risk”, as currently used but not defined as such in the ISO27k standards, with the simpler and more accurate “information risk”.  To me, that would be a small but significant change of emphasis, reminding all concerned that what we are trying to protect - the asset - is, of course, information. I’m delighted to see more people using “information risk”. One day, maybe we’ll convince SC 27 to go the same way!