ISO has an editing problem, in that they have consistently published standards that failed to undergo any actual editing. Two sources of mine claim that the organization has editors on staff, but neither could actually name any. A third source insists that the staffers, while technically hired and working for the ISO Technical Management Board (TMB), don’t actually edit standards, but instead perform other duties. A fourth source told me that ISO doesn’t have editors at all, and any editing is left up to the particular Technical Committee responsible for writing the standard. On its face, this appears most likely.

But it’s all moot. Whether they have editors or not, the quality of ISO standards has dramatically declined since about 2005 or so, when ISO flung open the doors and let the consultants take over nearly every standards development committee. (A fact which, by the way, violates ISO’s own rules on ensuring balanced participation by different stakeholder groups.) In an attempt to generate revenue more quickly, ISO then adopted policies for fast-tracking standards development, reducing the final quality of its products in order to get them to market faster.

As a result, nearly every major standard published from 2005 and onward has glaring content issues that result in real-world problems for standards users, putting certification and test results in jeopardy. This stuff matters.

ISO 9001

ISO 9001:2015 is the easiest one to pick on, and I won’t belabor the point since I’ve written an entire book on the subject. But here’s just one example:

Clause 4 of ISO 9001:2015 is called “Context of the Organization.” The first sub-clause, 4.1., is then titled, “Understanding the Organization and its Context.” We see the word “context” appear in both titles. Normally, the title of a book chapter indicates the content of that chapter. But in this case, it doesn’t.

The clause itself is comprised of two sentences, neither of which refer to “context” at all. Instead, the text discusses “issues” and at no point does the text tie the concept of “issues” to the title’s concept of “context.” A few notes at the end try to clarify this, but they fail. Worse, “notes” are un-auditable anyway, and cannot contain requirements.

The text of that clause wasn’t written by TC 176, the committee responsible for authoring ISO 9001, so they can be forgiven. Instead, it was written by the ISO TMB itself. The text, called “Annex SL,” was then put into every ISO management system standard, allowing its editorial gaffes to infect dozens of other ISO standards. ISO TCs are prohibited from editing — or correcting — the Annex SL text themselves.

But other editorial slips appear in text not written by the TMB. In ISO 9001’s clause 9.2, the authors refer to internal auditing as a “process” and then a “program” in the very same sentence. Elsewhere, the authors at times refer to “products and services” but later switch to “outputs” without any consistency. Clause 8.6 is titled “Release of Products and Services,” which sounds like it will discuss shipping, but is actually the clause on inspection and testing.

ISO 20000-1

If ISO 9001 is bad, the latest version of ISO 20000-1 is worse. This standard defines requirements for an IT “Service Management System,” and was ISO’s attempt to steal the ITIL framework for itself.

The latest version of this standard was published in 2018, and adopted the TMB’s Annex SL text, so the same editorial problems for that “core text” now appear in ISO 20000-1. But on top of that, the authors make repeated, glaring mistakes that make comprehension of key causes impossible. That, then, makes implementation and certification that much more difficult.

First, there’s the overt typo. Clause “Management of External Suppliers” includes this nugget, reproduced here verbatim:

For each external supplier, the organization shall agree a documented contract.

It’s not clear if they left a word out (“agree on a documented contract“) or if an entire portion of the sentence was deleted, possibly due to an errant backspace. Even if the word “on” is added, the sentence doesn’t make much sense as a requirement. The sentence should probably read “For each external supplier, the organization shall utilize a documented contract,” or something along those lines. The typo seems tiny and insignificant, but when implementing and auditing the clause, it quickly turns into a problem: you can’t implement the clause because you can’t be sure what the clause means.

Next, there’s the bizarre inclusion of a graphic inside a requirement. Clause 8.3.1 includes “Figure 2” within the actual requirements text, but without labeling it as a “note.” The clause itself doesn’t contain an actual shall clause, but instead says, “The organization may …“, making the entire thing optional. The inclusion of a graphic inside the requirement muddies this further. Is the graphic itself mandatory? If so, what does that mean? If it was just informative, why wasn’t it put into a note, or an annex?

In the end, clause 8.3.1 has no actual requirements, and is entirely informative; it has no reason to exist as a requirement. This was a rookie error, which is unforgivable given that ISO is supposed to be a professional publishing company.

The rest of the standard is filled with this sort of thing, as requirements go nowhere, text appears jumbled, and overall they clearly never had an actual editor look over the document.

Now keep in mind, ISO can publish an “errata” version that fixes these errors, but still hasn’t… and this version of ISO 20000-1 has been published in its defective form for four years now. Also, when ISO does publish such corrected versions, it has to do so for free, which is not something it likes to do.

Structuring Requirements

I’ve written standards, so I know how to do it. I provided sample text for ISO  9001 while I was working on TC 176 myself, although it never got past the “consultant army” led by Jack West and Lorri Hunt. I have worked on other committees, always behind the scenes (I’m banned from open participation in most cases), and have seen some of my text appear in AS9100, of all places. Of course, I was the chief standards developer for the entire line of Oxebridge Q001 standards, too. I was the founder of the M3 Development Council, which worked to develop a global management maturity model for various industries. So, again, I know what I’m doing.

ISO has rules on how standards should be written, too, although they’re overcomplicated and sometimes contradictory. What ISO needs is a simpler set of style guide rules, and then formal training on them by every TC participant. (Given that ISO has now announced they intend to reduce participant training, in order to fast-track standards publication even further, we shouldn’t get our hopes up.)

For example, a requirement within a clause must be constructed in a certain way, comprised of four standard elements, and then always written in that way, without exception. Here’s the model:

The first element is the subject of the requirement which, for ISO certification standards, will always be the intended user. Nearly always this should read “the organization,” except in cases where standards are aimed at persons (such as for credentialing) or other specific subjects. But if the rest of the sentence defines a requirement, the very first set of words must define who that requirement is intended for.

The second element is the “shall” phrasing. Nearly always this will simply be the word “shall,” but some obscure ISO standards do make distinctions between “shall,” “must,” and “may,” so may have another word here depending on context. Standards intended for certification should never use the word “may,” however, except in notes. Sticking with “shall” is the easiest thing to do here.

The third element is the action verb. Any certification requirement must direct the user to do something. Here, the “do” verb will be different depending on what is being demanded. This may mean verbs like “document” or “record” or “create a list” or “train” or even “ensure.” But the statement must tell the user what to do. It must be something that can be done, but also that can be proven later through evidence.

ISO has a huge problem here. In its attempt to dumb-down its standards to the laziest possible organization, and thus maximize sales, ISO has routinely used the verb “determine” to replace prior requirements to either document or record a thing. The problem is that “determining” cannot be verified without the use of mind readers or psychics. Every time you see the word “determine” in an ISO standard, you can recognize just how far off the rails ISO has fallen.

Finally, the fourth element is the actual requirement, the thing that must be done. The requirement must be worded in a way that meets the following rules:

  • It must be clearly understood
  • It must be actionable
  • It must generate some evidence, allowing it to be verified

As always, ISO standards can dictate what to do, but not how. This is not as hard as it sounds, but ISO struggles with this. In ISO 9001, for example, clause 5.2.1 on “Developing the Quality Policy” not only instructs the company what to do (“establish, implement and maintain a quality policy...”) but then commits the cardinal sin of telling the organization how to do it, and what exact text to include.

Likewise, AS9100 rev D’s clause 5.3 on “Organizational Roles, Responsibilities and Authorities” instructs the user organization to limit the role of management representative to a single person, ignoring the possibility that large organizations may have to split the duties between multiple persons. The standard then literally tells the user organization what to call that person, saying, they shall be “identified as the management representative.” This is an abusive overreach of authority by the AS9100 authors.

In other cases, such as ISO 9001’s clauses 6.2.2 “Quality Objectives,” 7.4 “Communication,” and 9.1.1 “Monitoring, Measurement, Analysis and Evaluation,” the standard suffers from the opposite problem: it doesn’t even define “what” must be done. Instead, the authors put this back on the reader, making the whole point of having a standard somewhat dubious.

Writing Standards Isn’t Hard

If every single sentence of a given ISO certification standard is crafted as shown above, problems disappear and things become much easier not only to implement but to audit. An auditor need only demand to see evidence of the fourth element (“description of the required action“) thus reducing — if not eliminating — auditor interpretations.

Consider this sentence from ISO 9001’s clause 4.2, which follows no such structure:

Here, the requirement starts with a massive, 26-word, editorial preamble (“Due to their effect or potential effect on the organization’s ability to consistently provide products and services that meet customer and applicable statutory and regulatory requirements“) before getting to who the requirement is intended for (“the organization.”) Then, it relies on the impossible-to-quantify action verb “determine.” To craft this clause properly, it should look like this:

The organization shall document:

(a) the interested parties that are relevant to the quality management system; and

(b) the requirements of those interested parties that are relevant to the quality management system.

Note: interested parties and requirements should be considered based on their effect or potential effect on the organization’s ability to consistently provide products and services that meet customer and applicable statutory and regulatory requirements.

This restructuring places the details in the correct order, replaces the vague “determine” with an actionable verb (“document“) that will result in some evidence for later verification, and then moves the editorial preamble into the Note where it belongs.

Or consider this other example, from ISO 9001’s clause 7.1.3 on “Infrastructure”:

The organization shall determine, provide and maintain the infrastructure necessary for the operation of its processes and to achieve conformity of products and services.

NOTE   Infrastructure can include:

  1. buildings and associated utilities;
  2. equipment, including hardware and software;
  3. transportation resources;
  4. information and communication technology.

Here, the authors make the opposite mistake of putting the requirement in the note. Instead, this requirement should read:

The organization shall determine, provide and maintain the infrastructure necessary for the operation of its processes and to achieve conformity of products and services. The organization’s infrastructure shall include, as applicable:

  1. buildings and associated utilities;
  2. equipment, including hardware and software;
  3. transportation resources; and
  4. information and communication technology.

This is because there are very few circumstances where an ISO 9001 user could claim the listed elements would not be part of their infrastructure.

The hardest parts of standards development are organizing the participants and getting consensus. But the dirty secret of ISO standards is that the text is written by less than a half-dozen actual people. Dick Hortensius (of the Netherlands) largely writes the Annex SL text, which can comprise more than 30% of a given ISO standard. Within the TC 176 committee, huge portions of ISO 9001 are written by a tiny handful of consultants, such as Nigel Croft and Jose Dominguez. So enforcing editing rules only requires getting to those half-dozen people. Simple, assuming they could shelve their egos for five minutes and agree to be edited.

The bulk of a TC’s work thereafter is theatrics and bureaucratic busy-work: convincing members to vote for it, processing their comments, and holding meetings in tropical locations to make it look like things are happening. But the text is nearly always pre-written and committee members have nearly zero influence on the half-dozen actual typists. While this makes “consensus” largely a performative thing, it does make editing easier.

Oxebridge Can Help

ISO is too far gone, but not every standards body is ISO. If you’re an industry organization that needs help in crafting standards, feel free to reach out. Oxebridge will have a formal service offering on this announced shortly, but in the meantime, know that there’s help available if you need it.

About Christopher Paris

Christopher Paris is the founder and VP Operations of Oxebridge. He has over 30 years' experience implementing ISO 9001 and AS9100 systems, and is a vocal advocate for the development and use of standards from the point of view of actual users. He is the author of Surviving ISO 9001 and Surviving AS9100. He reviews wines for the irreverent wine blog, Winepisser.


ISO 45001 Implementation