Document revision control ensures that changes to QMS information are evaluated, authorised and applied appropriately. A version number helps identify content, but the control also needs to address who uses it, when it applies and what happens to superseded information.
The documentation guide explains the wider lifecycle. Revision is an operational change when it affects methods, criteria or responsibility, not merely an administrative update to a file.
Identify the reason and effect of the change
A revision may correct an error, clarify wording or change a process requirement. Distinguish these cases. A typographical correction and a changed acceptance criterion can require different levels of review and communication.
Identify affected processes, forms, systems, training and external commitments. A local instruction can depend on information owned elsewhere. Changing one file without evaluating the relationship can create inconsistent controls.
Record enough reasoning to support the decision. The purpose is not a lengthy justification for every edit, but a reliable understanding of consequential changes.
Choose a usable version method
Numbers, letters, dates or system-managed identifiers can distinguish versions. Choose a convention users can apply consistently. Do not assume one format is universally required by ISO 9001.
A modification timestamp may help administration without proving approval or applicability. Users need to know which version is authorised for the work, not simply which file was edited most recently.
| Revision question | Decision needed |
|---|---|
| What changed? | Identify meaningful content differences |
| Why? | Explain the requirement or improvement basis |
| Who reviews it? | Assign suitable technical and operational evaluation |
| When does it apply? | Define release and transition conditions |
| What becomes obsolete? | Identify affected copies and references |
| What history remains? | Preserve necessary context for earlier work |
These fields can be implemented through a workflow or another proportionate arrangement.
Review and approve the changed content
Evaluate accuracy, requirements, practical usability and interfaces. An earlier approval does not automatically authorise substantially revised content. Preserve a reliable relationship between the decision and the version approved.
The approval process article explains why signatures alone are insufficient. A reviewer should understand whether the revision changes the way work is performed or evidence is captured.
Avoid treating revision control as a substitute for actual process approval. If a change affects customer commitments or another obligation, identify and fulfil the relevant decision requirements.
Plan effective dates and work in progress
Decide when the new version becomes applicable and how existing work will be handled. A changed specification may apply to new orders only, to all open work or according to another authorised arrangement.
Make that decision clear to users. A current repository can still cause errors if people apply the newest instruction to work governed by an earlier agreed condition.
Coordinate supporting actions before release where needed. Training, equipment configuration or system changes may be prerequisites for using the revised instruction reliably.
Communicate through actual distribution routes
Identify who needs the information and how it reaches them. A new file in a shared folder may not inform people using printed or offline copies. Email notification may be insufficient if the approved source remains unclear.
Explain consequential differences in a form users can understand. Requiring acknowledgement can provide one kind of evidence, but it does not automatically establish understanding or practical capability.
Review external copies and linked references where relevant. A revised internal document should not leave a customer-facing instruction promising an incompatible arrangement.
Preserve history and withdraw obsolete use
Retain superseded versions when needed to interpret earlier records or meet obligations. Mark or restrict them so they are not mistaken for current instructions.
Do not overwrite historical evidence to match the new version. Earlier completed records should preserve what happened under the applicable conditions, with corrections handled transparently where necessary.
The obsolete document article explains how withdrawal must consider copies beyond the master repository.
Test the revision process
Follow a recent consequential change from request through use. Ask an affected employee which version applies and how they learned about the difference. Examine whether related forms or system settings were updated.
If users repeatedly choose old copies, investigate access, usability and distribution. More reminders may not solve a repository that makes the obsolete version easier to find.
Review urgent or temporary changes as well as routine ones. Temporary instructions need clear status and review arrangements so they do not become uncontrolled permanent practice.
Revision control works when users can apply the right information to the right work and later reviewers can understand the history. Its effectiveness is shown through those decisions, not through the complexity of the version code.
Where the organisation keeps several authorised variants, identify which scope each serves. A site-specific instruction should not be mistaken for the global default merely because its revision number is higher. Applicability and version identity need to be understandable together.
If users need a summary of changes, distinguish that explanatory note from the approved content. The summary should help understanding without becoming an inconsistent alternative instruction. Check that it identifies consequential differences accurately and points to the authoritative version.