The KISS approach to ISO27k

From time to time on the ISO27k Forum, someone claims that certification auditors 'like to see', 'require' or even 'insist on' or 'demand' certain information security controls. Sometimes, it is further claimed or implied that certification auditors have actually raised or might yet raise nonconformances regarding the lack of certain controls, and consequently might refuse to certify their clients.

I'm not entirely convinced that such claims are true, for starters, but if so that hints at a problem with the certification and perhaps accreditation processes.

In accordance with ISO/IEC 27006, ISO/IEC 27007, ISO 19011 (revised last year) and their own internal certification audit procedures, accredited certification auditors should be certifying an ISO27k Information Security Management System against the requirements formally specified in the main body clauses of ISO/IEC 27001. They should definitely raise major nonconformances and refuse to certify if they have evidence that an organization has not fulfilled particular requirements in the main body of '27001. However, if there are issues regarding the organization’s interpretation and/or implementation of '27001 Annex A controls, that’s a different matter because Annex A itself is not mandatory.

A (re)current example on the Forum concerns asset inventories. The main body of '27001 does not formally require that organizations prepare and maintain inventories, databases or lists of their assets. Compliant organizations are required to consider the advice in Annex A regarding inventories and other matters, but they do not have to take the advice and they are free to interpret it in whatever way happens to suit their purposes.

Arguably, if an organization has identified and evaluated its information risks and decided to implement certain mitigating controls based on Annex A, but has not in fact done so yet (at least not satisfactorily) and has no real intention, then that suggests a failure of the ISMS processes which would likely constitute a reportable nonconformance. However, if the organization acknowledges that the controls are not fully implemented yet and is in the process of addressing that (ideally with some evidence of genuine intent, such as approved projects with allocated resources), then the ISMS processes appear to be working as planned … which would be a basis to challenge a nonconformance raised by the certification auditors. One of the objectives for an ISO27k ISMS is to drive and facilitate systematic improvement and maturity in this area: that’s nothing to be ashamed of - quite the reverse!

Unfortunately a number of myths and misunderstandings persist in the field, including allegedly common practices and widespread approaches that are not entirely aligned with the ISO standards. Even if many certified organizations happen to have asset inventories, that does not mean the standard formally requires everyone to do so. The same thing applies to information classification, antivirus controls, backups and so forth – in fact, the whole of Annex A ("Reference control objectives and controls") is advisory: certified organizations are formally required to check their selection of controls against Annex A "to ensure that no necessary controls have been overlooked" [27001 cluse 6.1.3c note 1] but they are not formally required to adopt and implement the Annex A controls. They are encouraged to select whatever controls happen to best address their risk mitigation needs, from any sources they choose including controls of their own invention. 

"Organizations can design controls as required, or identify them from any source." 

[ISO/IEC 27001:2013 clause 6.1.3b (note)]

Oh and by the way, mitigation is just one of four perfectly acceptable forms of risk treatment, along with avoidance, sharing and acceptance. Again, the organization is fully within its rights to choose its approach and the auditors should not complain (with some provisos concerning how those choices were made).

This point drove our development of the ISMS mandatory documentation checklist for the ISO27k Toolkit (free!). If you analyze the wording of ‘27001 carefully and narrowly, almost like a lawyer analyzing a contract, you find that many common practices are optional, not mandatory after all. This has implications for the certification auditors: clients have a sound basis to challenge audit findings or nonconformances on options that, for whatever reason, they have chosen not to take up. Provided the process through which they evaluated and chose their options is compliant with '27001, and provided they duly complied with their own policies and procedures, the auditors should not insist that those options are in fact required.

Having said all that, there is more to this than certified compliance with '27001. It could equally be argued that Annex A constitutes good practice, hence in accordance with '27001 6.3.1d, organizations that choose not to adopt Annex A controls should at least be able to justify their decisions in a Statement of Applicability. Right or wrong, discretion is appropriate and necessary under various circumstances, in practice. 

Furthermore, while certification auditors might be going beyond their brief if they refuse to certify organizations that choose not to adopt all the controls in Annex A, they might appear negligent if they didn’t at least point out substantial information security concerns which crop up in the course of their audits … which is where minor nonconformances, ‘other findings’, ‘potential points of concern’, informal reporting and the negotiations towards the end of an audit generally come into play. 'We will certify your ISMS, but we advise you of the following issues: ...'.

ISMS management reviews, ISMS internal audits etc. probably should dig out and report concerns of this nature too: they generally have a wider brief than certification and are not necessarily constrained to compliance auditing solely against the formal requirements. Almost anything is potentially reportable internally if a competent person believes and has evidence that is in the organization’s best interests. That includes audits and reviews of the ISMS against other requirements such as quality assurance or health and safety or environmental protection or corporate strategies or whatever. Organizations have many obligations and expectations in addition to those in ‘27001, not least meeting their own business objectives and duties towards various stakeholders.

So what does this all mean? Personally, despite being a fan of good security practices, I understand the value of a minimalist KISS approach (as in Keep your ISMS Simple, Stupid) with benefits such as:

• Ease of understanding, use, management, maintenance and auditing;
• Focus on the essentials, and do those well, make them slick;
• Lack of red tape and bloat - often itself a rats nest of security issues as well as the obvious costs and delays;
• Maximize bang for buck - the core processes and an ISO/IEC 27001 compliance certificate are valuable, even if the certified ISMS is minimalist;
• Release the organization from the constraints of overbearing security, encouraging investment and effort in other more valuable business opportunities;
• A solid foundation on which to build appropriate extensions at some future point - meaning both maturity and the flexibility to respond to novel situations as they arise.