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.
A worked example, stage by stage
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.
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.