ISO/IEC 27001 Annex A status

I've just completed an internal audit of an ISO27k ISMS for a client. By coincidence, a thread on ISO27k Forum this morning brought up an issue I encountered on the audit, and reminded me of a point that has been outstanding for several years now.

The issue concerns the formal status of ISO/IEC 27001:2013 Annex A arising from ambiguities or conflicts in the main body wording and in the annex. 

Is Annex A advisory or mandatory? Are the controls listed in Annex A required by default, or optional, simply to be considered or taken into account?

The standard is distinctly ambiguous on this point, in fact there are direct conflicts within the wording - not good for a formal specification against which organizations are being audited and certified compliant.

Specifically, main body clause 6.1.3 Information security risk treatment clearly states as a note that "Organizations can design controls as required, or identify them from any source." ... which means they are not required to use Annex A.

So far so good .... however, the very next line of the standard requires them to "compare the controls determined in 6.1.3 b) above with those in Annex A and verify that no necessary controls have been omitted". This, to me, is a badly-worded suggestion to use Annex A as a checklist. Some readers may interpret it to mean that, by default, all the Annex A controls are "necessary", but (as I understand the position) that was not the intent of SC 27. Rather, "necessary" here refers to the organization's decision to treat some information risks by mitigating them using specific controls, or not. If the organization chooses to use certain controls, those controls are "necessary" for the organization, not mandatory for compliance with the standard.

To make matters worse still, a further note describes Annex A as "a comprehensive list of control objectives and controls", a patently false assertion. No list of control objectives and controls can possibly be totally comprehensive since that is an unbounded set. For starters, someone might invent a novel security control today, one that is not listed in the standard since it didn't exist when it was published. Also, there is a near-infinite variety of controls including variants and combinations of controls: it is literally impossible to identify them all, hence "comprehensive" is wrong.

The standard continues, further muddying the waters: "Control objectives are implicitly included in the controls chosen. The control objectives and controls listed in Annex A are not exhaustive and additional control objectives and controls may be needed." This directly contradicts the previous use of "comprehensive".

As if that's not bad enough already, the standard's description of the Statement of Applicability yet again confuses matters. "d) produce a Statement of Applicability that contains the necessary controls (see 6.1.3 b) and c)) and justification for inclusions, whether they are implemented or not, and the justification for exclusions of controls from Annex A". So, despite the earlier indication that Annex A is merely one of several possible checklists or sources of information about information security controls, the wording here strongly implies, again, that it is a definitive, perhaps even mandatory set after all.

Finally, Annex A creates yet more problems. It is identified as "Normative", a key word in ISO-land meaning "mandatory". Oh. And then several of the controls use the key word "shall", another word reserved for mandatory requirements in ISO-speak.

What a bloody mess!

Until this is resolved by wording changes in a future release of the standard, I suggest taking the following line:
  • Identify and examine/analyse/assess/evaluate your information risks;
  • Decide how to treat them (avoid, mitigate, share and/or accept);
  • Treat them however you like: it is YOUR decision, and you should be willing to justify your decision … but I generally recommend prioritizing and treating the most significant risks first and best, working systematically down towards the trivia where the consequences of failing to treat them so efficiently and effectively are of less concern;
  • For risks you decide to mitigate with controls, choose whatever controls suit your situation. Aside from Annex A, there are many other sources of potential controls, any of which might be more suitable and that’s fine: go right ahead and use whatever controls you believe mitigate your information risks, drawing from Annex A or advice from NIST, DHS, CSA, ISACA, a friend down the pub, this blog, whatever. It is your choice. Knock yerself out;
  • If they challenge your decisions, refer the certification auditors directly to the note under 6.3.1 b: “Organizations can design controls as required, or identify them from any source.” Stand your ground on that point and fight your corner. Despite the other ambiguities, I believe that note expresses what the majority of SC27 intended and understood. If the auditors are really stubborn, demonstrate why your controls are at least as effective or even better than those suggested in Annex A;
  • Perhaps declare the troublesome Annex A controls “Not applicable” because you prefer to use some other more appropriate control instead;
  • As a last resort, declare that the corresponding risks are acceptable, at least for now, pending updates to the standard and clearer, more useful advice;
  • Having supposedly treated the risks, check that the risk level remaining after treatment (“residual risk”) is acceptable, otherwise cycle back again, adjusting the risk treatment accordingly (e.g. additional or different controls).
If you are still uncertain about this, talk it through with your certification auditors – preferably keeping a written record of their guidance or ruling. If they are being unbelievably stubborn and unhelpful, find a different accredited certification body and/or complain about this to the accreditation body. You are the paying customer, after all, and it’s a free market!