Normative content is content that supports requirements for compliance. It could be a requirement in the main body of a standard, a normative reference or a normative annex. What is important here is not location but how the standard identifies it and how it uses language. A normative part will normally include a ‘shall’ statement. There will be a definition of criteria. There might be requirements for records. All of these would be in scope for the document.
Informative content will help the reader to understand or use the standard. This might include notes, examples, clarifications or diagrams, or certain types of annex. The informative material might explain the rationale behind a requirement or provide one way to do something. However, it shouldn’t become a pass-fail point in an audit unless another normative part of the standard specifies that it has to be done in this way.
It’s easy to get confused when the informative content seems more practical than the actual requirement. For example, there might be a requirement that ‘the organisation shall control the revision of documents’. This might be accompanied by a note that suggests a particular form of revision log. The document revision control is the requirement. The suggested form of revision log is only one way to satisfy this requirement. If I copy the note as the revision control then I’m adding a requirement to my system that might not have been intended.
Here’s a little exercise. Take a short extract containing a requirement, a note, an example and an annex reference. Mark them as normative, informative or unclear. Explain why you’ve done so, using the document reference and the verb used in that reference and what it says about the relationship between clauses. When it’s not clear what something is, look at the introduction, the annex title, the normative references, the explanation of how the standard uses modal verbs.
This should be reflected in the traceability too. A traceability table could show that normative requirements map to processes, responsibilities, criteria and records. Informative content could be included separately as interpretation assistance or implementation options. The purpose of having this clear distinction is to make it obvious which internal actions are mandatory based on the requirement and which are optional because they are helpful to achieve a result.
So the next time you are tempted to turn an example or a note into a controlled list item, stop and check its status. Does the standard say that this is a requirement? Does it suggest a method? Does it just show one way of doing it? Doing this will ensure that guidance stays helpful and doesn’t turn into a hidden requirement.