The formalities of certification

ISO/IEC JTC 1/SC 27 is currently getting itself all hot-under-the-collar about cloud security certificates, certifying compliance with standards that were neither intended nor written for certification purposes. 

The ISO27k cloud security standards ISO/IEC 27017 and ISO/IEC 27018 are not written as formally as certifiable standards such as ISO/IEC 27001 ... and yet I gather at least one accredited certification body has been issuing compliance certificates anyway, implying that the auditors must have used their discretion in interpreting the standards and deciding whether the organizations fulfilled the requirements sufficiently well to 'deserve' certificates. The trustworthiness of those certificates, then, depend in part on the competence and judgement of the certification auditors, not just on the precise wording of the standards. In other words, there's an element of subjectivity about it.

The key issue is that, in this context, compliance certification is a formal process designed to ensure that every duly-issued certificate says something meaningful, trustworthy and hence valuable about the certified organization's status - specifically, that it has been independently and competently verified that they fulfill all the mandatory requirements of the respective standard. Certification is meant to be an objective test.

That's why certifiable standards such as ISO/IEC 27001 are so precisely worded and narrowly interpreted, for example distinguishing "shall" (= mandatory) from "should" (= discretionary) despite those being different tenses of the exact same English verb. Standards that are not intended to be used for certification processes are not so precisely and narrowly worded, allowing more discretion on how they are applied. To avoid confusion (!), they are not supposed to use the word "shall", and there are drafting rules about similar words e.g. "must", "may" and "can" laid down in the formal ISO Directives. 

The idea, obviously enough, is to leave as little room for subjective interpretation as possible in the certifiable standards, a tricky objective in a field as diverse and dynamic as information risk and security management, especially given the huge variety of applicable organizations. The context is markedly different to, say, the specification of nuts and bolts.

ISO 9000 was, I think, the first certifiable ISO standard to address this issue: rather than attempt to specify and certify an organization's product quality practices directly, the standard formally specifies an overarching "quality management system", which in turn should ensure that the products are of an appropriate quality. The "certifiable management system" approach has since spread to information security, environmental protection and so on.

It is more of an issue for the accreditation and certification bodies or ISO than for SC 27 but, hey, SC 27 has plenty of passionately-held opinions and, to be fair, it is an integrity issue. I suspect there will be a crack-down on non-management system certifications, or at least a rewording to distance them from the management systems compliance certificates. That in turn will increase pressure to develop certifiable [management system] standards for cloud security and other domains (such as IoT security) where there is clearly market demand.