Status of ISO27001 Annex A
In the course of debating and attempting to bury the zombie, some members trot out their own curious interpretations of the standard, pointing out actual and apparent discrepancies in the wording which, to them, indicate that Annex A is at least partly mandatory. I'm too polite to say they are wrong, but I believe they are misguided or mistaken - partly, it must be admitted, because the standard is ambiguously worded in some areas, hence it has to be interpreted carefully in practice.
To be clear, based on my three decades' professional experience and membership of ISO/IEC JTC 1/SC 27, my position is that none of the controls outlined in Annex A are mandatory.
None at all.
Zero.
Nil.
Nada.
[Cue tumbleweed]
This is a fundamental but complex issue to explain, so please forgive yet another lengthy post. In hope of decapitating the zombie, once and for all, I feel the urge to explain in detail.
To kick off, I’ll emphasise the critical distinction between two key terms:
- Mandatory requirements are formally described in the main body of ISO/IEC 27001. In order to be certified, ALL organisations absolutely MUST do all those things and should be prepared to convince the certification auditors of that;
- Discretionary items such as the controls summarised in Annex A are options to be considered - suggestions or recommendations, good practices you could say. Clause 6.1.3 indicates that management has much more latitude in this area provided they follow the mandatory information risk management processes from the main body, and again they may need to convince the certification auditors that they diligently followed the specified processes. Most organisations find many of the Annex A controls applicable, but seldom all of them. In the extreme, a few brave organisations choose to exclude ALL of the Annex A controls precisely as worded in the standard, instead electing to use custom controls, even if many in fact end up strangely similar to the Annex A outlines: they are merely word-smithed fine-tuned variants.
There are touch-points between the management system (as formally specified in the main body of '27001) and the information security controls (as succinctly outlined in annex A). However, both conceptually and practically, they are distinct parts to the standard with specific implications for certification.
Here's an example. Any management system, such as an ISMS, revolves around and depends upon management information. That management information has various associated information risks and security requirements. For example, there are information risks associated with the security metrics (which are a mandatory part of the ISMS, as specified by the main body clause 9.1 “Monitoring, measurement, analysis and evaluation”) requiring risk treatments, typically through information security controls to protect that management information – controls that may be selected from Annex A, or from any other source, perhaps even created from scratch by creative thinking and innovation.
The standard does not demand specific Annex A controls to protect the security metrics or other management information: the organisation evaluates the risks and chooses whichever controls best suit its purposes – in other words, the controls are discretionary but, for certification, the risk management process for selecting and implementing various controls must comply with the main body requirements.
The touch point comes in clause 9.1 part (b): “The organisation shall determine … the methods for monitoring, measurement, analysis and evaluation, as applicable, to ensure valid results; NOTE The methods selected should produce comparable and reproducible results to be considered valid.” So here is a main body mandatory requirement to ensure the validity of the ISMS metrics, but notice there is no explicit requirement to use certain controls from Annex A. The organisation determines for itself how to ensure its security metrics are valid, and in practice the controls in this area vary between certified organisations. That’s fine, so long as they each followed the information risk management process defined by their ISMS, and those ISMSs in turn fulfill all the mandatory requirements of the standard.
To confuse matters a little, there are in fact some discretionary aspects to the main body of ‘27001, dotted in amongst the mandatory requirements. Clause 6.1.3 is a classic example: the organization “shall define and apply an information security risk treatment process” … but the process it describes has management selecting controls, taking account of things, determining which controls are ‘necessary’ etc. That’s a blend of mandatory and discretionary requirements.
Another confusion is caused, unfortunately, by the use of the reserved term “shall” throughout the standard including Annex A. “Shall” normally denotes mandatory requirements in ISO-land. Personally, I think SC 27 made a mistake in changing “should” in the drafts of ‘27001 Annex A to “shall” in the published version, a change that happened quite late in the drafting process as I recall, with the publication deadline looming. On the other hand, the change was a compromise that placated those on the committee who were adamant and had been passionately arguing that some of the Annex A controls are universally required and ought to be mandatory. It also (I think) satisfied an ISO directive about the wording to be used in the management systems standards - a double whammy.
Anyway, the upshot is that we’ve ended up with ‘a racing horse designed by committee’ (as shown above). This, along with the ambiguous wording of clause 6.1.3 about Annex A, will hopefully be resolved when ‘27001 is revised and reissued. The intended and formally specified status of Annex A remains the most contentious aspect of ‘27001 for SC 27. This is one persistent resilient awkward bugger of a zombie!