ISO27k standards development - there has to be a better way

From time to time I update ISO27001security.com with news on the ISO/IEC 27000 standards, including information from the meetings of ISO/IEC JTC 1/SC 27.  Having contemplated the rate of progress on the updates to ISO/IEC 27001 and 27002, I feel the need to comment in general terms about the ISO/IEC process for developing and publishing standards.

Firstly, the process is convoluted and slow - so slow in fact that it may be outpaced by rapid technological changes (developing cloud security standards being a topical example, let alone something such as BYOD).  On the other hand, one of the key benefits of standards is to bring stability and order to the rather chaotic world around us.  It certainly helps to form a broad international consensus on the terms and concepts we use, and that in turn facilitates a common understanding of the complex issues we face.  Standards such as ISO/IEC 27000 are extremely valuable in formally defining terms that are bandied about yet often have subtly if not grossly different meanings.  Distilling disparate definitions down to such succinct, specific and generally-accepted wording is a difficult task for the standards' authors, but we all benefit.

Secondly, a rant about the quality and utility of the ISO/IEC 27000-series standards.  I am speaking specifically here about the ISO27k standards since I don't know enough about others to comment on them.  Well-written standards such as ISO/IEC 27000, 27001, 27002 and 27005 have proven popular and are being widely used, whereas others have practically disappeared without trace.  ISO27k standards currently under development by SC27 fall across a similar quality spectrum.  Despite (and often because of) the rather bureaucratic processes used to develop standards, the quality and utility of the final products is distinctly variable.  Anyone with a commercial management background who looks dispassionately at the way ISO27k standards are developed would probably agree that there are some fundamental flaws in the process:

• ISO27k projects are sometimes (cynics would say 'often'!) initiated with no clear idea about what they are intending to achieve, nor how they are going to do it.  Sure, there are Study Periods that are presumably meant to consider and firm-up the requirements for new standards, but we are lucky if the terms of reference and other materials they generate are of any use at all, and it is pot luck whether the published standard (if it ever surfaces) bears any relationship to the original terms of reference.  Similar projects in the commercial world, at least, are far more carefully and explicitly specified than this.
  
  
• Outside of ISO/IEC, business cases are the conventional way to initiate major projects.  Given that almost every ISO27k standard is the product of literally hundreds, maybe thousands of man-hours of work from teams of international experts over several years, these are indeed major projects, although in some cases you could be forgiven for thinking otherwise if all you see is the end product!  Business cases are perhaps the most obvious expression of an extremely important management control, namely management's careful consideration of the proposals, seeking adjustments or clarifications where necessary, followed by approval of and investment in those projects that are deemed to be cost-effective and in the organization's best interests.
  
  
• Organizations that run their projects effectively manage the scope, schedule and resources carefully.  Most assign dedicated, full-time project managers, often trained and experienced professionals, to major projects.  Project managers, in turn, are usually supported by structures such as Project Offices, plus a raft of policies, procedures and guidelines concerning how projects are managed and tracked, and sometimes assurance functions such as Internal Audit.  The equivalent in SC27 at least consists of one or two editors per standard supported by an over-worked Secretariat whose main job seems to be organizing meetings and battling ISO/IEC's obtuse content management system.
  
  
• In  the commercial world, a senior manager is usually nominated as the owner or customer of a major project, and is held accountable by management for its delivery.  In other words, projects are governed as well as managed.  The SC27 equivalent of the project owner/customer is effectively SC27 itself, meaning the entire committee of (mostly) volunteers who also staff the projects (spot the lack of segregation).  To make matters worse, SC27 runs a substantial portfolio of projects (of which the ISO27k standards are only a part) and has very little time to oversee, consider, manage, direct or control each one.

ISO/IEC does document its processes formally, to some extent.  The "ISO/IEC Directives", along with a number of supporting standards, are meant to direct those developing International Standards (plus Technical Reports and Publicly Available Specifications).  Part 1 of the Directives titled "Procedures for the technical work" in fact concerns the initiation of projects developing standards.  Part 2 lays down the "Rules for the structure and drafting of International Standards". 

Part 1 of the Directives states an intriguing objective: "Within the framework of these procedures, the work may be accelerated and the task of experts and secretariats facilitated both by progressive introduction of new technologies and modern programme management methods."  I say intriguing because last year I was involved with an ad hoc ISO group exploring the possible use of collaborative working. In practice, the group was mired in bureaucracy and achieved very little except a rather lame proposal to spend another year looking into things. All its meetings were held by phone conference in the early hours of the morning, NZ time, and frankly I haven't had the energy let alone the inclination to attend. Collaborative tools such as email and Google Docs that would have really helped are evidently too cutting-edge for some of the members who would rather argue about the suitability of the tools than try them out. It's not that the people involved have nothing to offer, rather that the working practices and the ample opportunities to disrupt make it almost impossible for us to progress or contribute productively. The whole experience has been intensely frustrating. Guess I'm not cut out for this.