ISO 22000 clause 7.5.2: review and approve information before use

What clause 7.5.2 requires in practice

Clause 7.5.2 covers what happens when documented information is created or updated. Three things need to be appropriate. The first is identification and description, for which the standard offers a title, date, author or reference number as examples. The second is format, for example language, software version or graphics, and media, whether paper or electronic. The third is review and approval for suitability and adequacy.

Review and approval address different questions. Review asks whether the content is right and usable for its purpose. Approval is the authorisation to use it. The standard does not prescribe who signs, how many signatures are needed or what software holds the information.

The requirement applies on first issue and on every update, so a quick edit to a live instruction is covered as much as a new document. The output is information that people can recognise, read and trust as the authorised version.

Make the information identifiable

People need to know what the information concerns and whether it is the relevant item. Identification may use a title, date, author, reference or other suitable details. The standard gives examples rather than demanding every possible identifier on every page.

Use enough context to prevent ambiguity. A monitoring instruction may need to identify the process or equipment to which it applies. A product-related document needs a clear relationship with the relevant product or specification. Similar filenames are not a dependable way to distinguish different operating arrangements.

Consider how information will be found and interpreted later. A record that makes sense only to its original creator can become weak evidence when someone else must investigate an event.

Choose a format suited to use

Language, layout, software format and media should support the work. A concise visual instruction may help at one workstation, while a technical evaluation needs a fuller explanation. The aim is accurate understanding, not uniform appearance regardless of purpose.

Consider the environment and access conditions. Electronic information needs a usable means of access; paper information needs to remain legible and current. If personnel cannot open the file or interpret its terminology, formal approval does not solve the practical problem.

Where several versions or languages are needed, define how consistency will be maintained. Translation and formatting changes can affect meaning, so include appropriate checks according to the significance of the information.

Review and approve suitability and adequacy

Review asks whether the content and presentation are right for the intended purpose. Approval establishes that the information is authorised for use. Both are required; an unchecked signature should not be treated as an adequate substitute for review.

Involve people with relevant technical and operational understanding. The standard does not prescribe one universal approval hierarchy or require a particular number of signatures. Assign arrangements that suit the information and preserve clear responsibility.

For updates, examine connected instructions, forms and system information. A changed criterion may affect how results are recorded or what action follows. Coordinate release of the related information so users do not face incompatible instructions.

Why reviewing and approving information matters to the business

Operating instructions and specifications translate food safety decisions into action. If an instruction is wrong, ambiguous or in the wrong format for the workplace, the effect repeats on every shift. Review catches technical errors before they are copied into daily practice, and approval makes clear who stands behind the content.

Practical benefits follow. Identification makes it easy to tell which version applies to which product or line, which is vital in an investigation. Sensible formats cut training time and reduce reading errors, especially for multilingual teams. A light but real approval step also helps prevent informal changes from creeping into live documents without consideration of what else depends on them, such as record forms or software settings.

How to implement clause 7.5.2

Make the creation and update route simple enough that people actually use it. The following steps fit most organisations.

1. Decide the minimum identification every controlled item needs, such as title, process or product, version and date, and apply it consistently.
2. Choose formats that suit the task and the reader, including language, layout, visuals and whether the user works on paper or a screen.
3. Name reviewers by subject, so technical content is checked by someone who understands it and usability is checked by someone who does the work.
4. Name approvers by role and make clear that approval follows review rather than replacing it.
5. When an item changes, check connected instructions, forms, software settings and training, and release related items together.
6. Keep a simple way to show what changed and why, appropriate to the importance of the information.
7. Spot-check recent updates to confirm the route was followed and that users have the authorised version.

Illustrative food-production example

Illustrative food-distribution example

A distributor creates a product-hold instruction for several depots. A trial shows that the document refers to a screen label used only in the central office application. The author revises the instruction to match the depots' actual interface and verifies its meaning with users before approval.

The organisation also identifies how later application changes will trigger review. An initially correct instruction can become unsuitable when the supporting system changes.

Evidence and common mistakes