Every SOP starts accurate and becomes gradually less so. A tool gets renamed, a price changes, a step disappears, and the document people trust quietly becomes advice from the past. Version control exists to make that drift visible — and it does not require a document management system or an audit department. A version number, a date, an owner, and a change note cover most of it.
The four fields that do the work
- Version — a simple counter (1.0, 1.1, 2.0). Bump the minor number for clarifications and the major number for a change in how the work is actually done.
- Last reviewed — a real date, not "reviewed annually". If the date is old, the reader knows to be cautious.
- Owner — a role, not a person's name. Owners change; the responsibility should not.
- Change note — one line explaining what changed and why. This is the field people actually read when they wonder whether their printed copy is current.
Review on a cadence tied to risk
Not every SOP needs the same attention. A useful pattern is to sort documents into three groups: customer-facing or safety-critical procedures reviewed quarterly, operational procedures reviewed twice a year, and stable back-office procedures reviewed annually. Put the review date in the header so it is impossible to miss, and treat an overdue review as a small task rather than a failure.
Event-driven reviews matter more than calendar reviews. Any time a system changes, a supplier changes, or a serious mistake happens, the related SOP gets reviewed immediately. A calendar reminds you; an incident tells you exactly where the document is wrong.
Keep the history small and readable
You do not need a diff of every word ever written. Keeping the previous version plus a one-line summary of each change is enough to answer the two real questions: what did this used to say, and why did it change? Storage is free; clarity is not. A version history nobody can read provides no protection.
Watch for silent forks
The most dangerous version problem is not an old file — it is two files. A printed copy on the shop floor, a shared document in a folder, and a message thread with a corrected step are three versions of the truth. Consolidating to one published location prevents most of the maintenance work before it starts.
Retire documents deliberately
When a process disappears, the SOP should be archived rather than deleted. Deleting it destroys the record of how the work used to be done, which is often needed later for audits, disputes, or rebuilding a workflow. Archive with a clear "no longer in use as of" note so nobody follows a retired procedure by accident.
The goal of version control is not perfect documentation — it is knowing whether the document in front of you can be trusted. A dated, owned, versioned SOP answers that question in the first five seconds, and that confidence is what makes a documentation library worth having.