How to manage SOP revisions
How to manage SOP revisions: fix a numbering scheme before you need it, set review intervals by risk instead of one blanket date, name an owner for the whole register, and record a no-change review as evidence.
Managing SOP revisions means governing the register those revisions live in (its numbering scheme, its review cadence and its owner) not just describing what changed in any one entry.
The short version
- Fix the numbering scheme before the register's first entry: renumbering a live library later breaks every cross-reference and training record that cited the old number.
- Set review intervals by risk, not by one blanket anniversary date for every SOP regardless of what it governs.
- Name one owner for the whole revision register, distinct from any single SOP's author or approver.
- Record a review that found nothing to change as its own dated entry: an auditor samples for evidence of review, not evidence of change.
- Catch duplicate open entries before they collide, or the same SOP ends up with two candidate version numbers.
- QueryChart's own Change Log and Compare Versions view, at /features/version-control, give the register itself the same kind of history it's asking every SOP to keep.
The register is bigger than any single entry
A revision history log can show eleven flawless entries and still be the reason an audit finding gets written, because entry twelve never got a number when two SOP authors opened it at once, or because nobody can say whether last March's scheduled review actually happened. Organisations that write SOPs are usually good at describing what changed in a given entry. What goes wrong is the register around those entries: the numbering scheme, the interval each SOP is due for review, and who is accountable when either one slips.
The terms get used loosely, and it's worth separating them before going further. A revision is one dated entry: a change to an SOP's content, logged with an author and a reason. Its version is the number that entry produces, the one stamped on the current issued copy. Revision control is managing that sequence of entries over time; it sits inside the wider practice of document control, which also governs distribution and withdrawal. This page is about running the register as a whole; for the mechanics of logging one individual change, see /guides/how-to-track-changes-in-an-sop.
The chart below is one revision moving through that register, from the moment a change is identified to the moment the SOP is reissued, across five lanes: Process owner, SOP author, Reviewer, Approver, Document controller. QueryChart keeps its own charts under the same kind of governance: every save writes to a Change Log with a per-field diff of who changed what, a Compare Versions view sets any two revisions side by side, and a stale one restores in a click: all covered at /features/version-control.
One entry, from identification to reissue
A single revision request moves through five lanes (Process owner to Document controller) becoming the register's next numbered entry.
A change is identified and triaged by risk
The Start is an occurrence, "Change to an SOP identified", followed by "Describe the proposed change and the reason for it" before anyone drafts an entry. "Change affects a safety-critical step?" is the register's own risk triage, deciding whether this entry gets an expedited review or the standard cycle.
Routing, a duplicate check, then the draft
"Flag the entry for expedited review" or "Route the entry through the standard review cycle" sets the pace, then "Revision history log already has a pending entry for this SOP?" catches a second open entry before it collides with the first. Only then is "Draft the revision history entry: date, change summary, author, version superseded" written and submitted.
Reviewer and approver both check the number
"Reviewer checks the entry against the current SOP content" can send the draft back on "Comments to resolve before approval?"; "Approver checks the entry against the SOP master and the version it supersedes" is a second, independent check against that same superseded number, and a rejection loops back to the same update row as a reviewer comment.
The register owner finalizes and reissues
"Record the approved entry as final in the revision history log" locks the row before "Update the SOP's version number and effective date" and "Withdraw or archive the version referenced as superseded" run, ending at "SOP reissued at the new version," all four owned by the Document controller.
How it works
Fix the numbering scheme before the first entry
Decide once whether issued revisions get whole numbers (1, 2, 3) or a major.minor scheme that separates drafts from issued copies, and write the rule down. Never renumber a live register to fix an old inconsistency: a renumbered sequence invalidates every cross-reference, every training record and every prior audit trail that cited the old number.
Set review intervals by risk, not by one blanket rule
A safety-critical SOP earns a shorter interval than a low-risk one; the chart's own "Change affects a safety-critical step?" branch is the same triage applied to an individual change, and the review cadence deserves the same logic. Write the interval into the SOP header itself, as a due date, so it doesn't depend on someone remembering a policy.
Name an owner for the whole register
An SOP's author drafts its entry and its approver signs it, but neither is accountable for the register as a whole: for the entry that's three weeks overdue, or the SOP whose review date nobody set. Give that job to one named role, typically a document controller or quality manager, and let them chase what's late.
Record a no-change review as its own entry
When a scheduled review confirms an SOP is still correct, write that finding into the register with the date and the reviewer's name, the same way an actual revision would be logged. A log that only grows when content changes reads, to an auditor, as a document nobody has looked at since it was written.
Catch duplicate entries before they collide
Before drafting a new entry, check whether the SOP already has one pending: the register's "Revision history log already has a pending entry for this SOP?" question exists because two authors working from the same master copy is common enough to route around. Merge the changes or sequence the entries so the log never has to reconcile two candidate version numbers for one document.
Mistakes to avoid
Renumbering to fix an old inconsistency
Once revision 4 has been cited in a training record or a supplier pack, changing it to 4.1 to fit a cleaner scheme now means the same date range answers to two different numbers. Decide the scheme once, then govern exceptions instead of restructuring the sequence to accommodate them.
A blanket 12-month review date for every SOP
Reviewing every procedure on the same anniversary produces a stack nobody has time to read carefully, and review becomes a rubber stamp. Stagger intervals by risk, the way the chart's safety-critical branch does for an individual change, so a reviewer actually has time for each one.
No entry for the review that changed nothing
A register with entries only where content changed looks, to an auditor, like a document nobody has opened since it was issued. Log the review date and the "no change needed" finding as its own line, distinguishable from an actual revision but no less real.
A register with no single owner
When any SOP author can open a new entry and nobody is watching the register as a whole, duplicate drafts and missed review dates both go unnoticed until an audit finds them. The full document lifecycle around this problem (including who owns the master register) is covered at /templates/document-control-process.
Related QueryChart feature
Build your own SOP revision register
Start from this chart and QueryChart tracks every save in a Change Log you can compare and restore.
Related guides
Frequently asked questions
What's the difference between an SOP's revision and its version?
A revision is the dated entry: a change to the SOP's content, logged with an author and a reason. Its version is the number that entry produces, the one stamped on the current issued copy. In practice the words get used for the same thing, but the register itself is organised around revisions: each row is one, and the version is the state the SOP is in after the latest one is approved. QueryChart's own version history, at /features/version-control, uses "version" the same way: a numbered, comparable snapshot produced by a save.
How often should an SOP be reviewed?
There's no single interval that fits every procedure: the right answer depends on how much a step's failure would cost. A safety-critical or regulator-facing SOP typically gets reviewed annually or sooner; a low-risk administrative one can safely run two to three years between reviews. What matters more than the exact number is that every SOP has one, written into its header as a due date rather than left to whoever happens to notice it's overdue.
Who should own the SOP revision register?
Someone distinct from any single SOP's author or approver: usually a document controller or quality manager, the role the chart above puts in its own lane finalizing every approved entry. The author and approver are each accountable for one revision; the register needs one person accountable for the set: chasing overdue reviews, catching duplicate entries, and keeping the numbering scheme stable.
Does a review that finds nothing to change still count?
Yes, and it needs its own record to prove it. An auditor sampling a revision register is looking for evidence that a review happened on schedule, not evidence that the SOP changed: a procedure that's correct as written should stay unrevised for years. Log the review date and the "no change required" finding as a dated entry, or the gap between revisions reads as neglect instead of stability.
How is this different from tracking each individual change to an SOP?
Tracking an individual change is entry-level: what changed, who changed it, and what it replaced, which is the subject of /guides/how-to-track-changes-in-an-sop. Managing SOP revisions is register-level: the numbering scheme every entry has to follow, the review interval each SOP is due against, and the named owner accountable when either one lapses. A register can log every individual change perfectly and still be badly managed if nobody owns the schedule. For the fuller set of governance practices beyond this page, see /guides/sop-version-control-best-practices.
