How to version control an SOP
SOP version control means numbering every procedure revision, routing safety-critical changes through hands-on retraining and a signed checklist instead of read-and-acknowledge, and retiring the copy it replaces.
A worked example, stage by stage
A request logged against a revision
"SOP change proposed" starts the chain, then "Submit change request with reason" and "Log request against current SOP revision" tie the request to a specific version before "Assess operational impact of the proposed change" begins: nothing here has judged the change yet, only recorded what it is and what it replaces.
The fork that decides how demanding this gets
"Safety-critical step affected?" forks the process: a Yes answer routes into "Conduct documented safety impact assessment" and then "Submit change package for QA-gated approval", gated by a second "Approved?" decision that rejects straight back into the safety assessment rather than past it.
Hands-on retraining versus a standard review
Approved safety-critical changes move to "Schedule mandatory hands-on retraining" and "Complete hands-on training and sign competency checklist" (a supervised, signed-off run-through, not a read receipt) while the No branch runs "Complete standard suitability review" into its own "Submit change package for approval" and "Approved?" gate.
Both paths converge on one register update
The standard path still ends in "Distribute updated SOP for read-and-acknowledge" and "Read and acknowledge the new version", and both paths meet at "Update the SOP register and mark the previous revision superseded" before "Publish new revision as the current controlled version" makes it current.
How it works
Fix the SOP numbering scheme before the first revision
Assign each SOP an identifier and a whole-number revision, printed in the header of every page alongside the effective date and approver. Decide this once, because renumbering later breaks every retraining record and every audit trail that cited the old number.
Log the request against the revision it changes
Open a request with the exact step being changed and the reason (an incident, a near miss, a deviation) before anyone touches the draft. Type it into a chart's Box text column and use Line to to point it at the row that logs the request against the current revision, so the request is tied to a version rather than floating free.
Force the safety-critical decision explicitly
Give the workflow a Decision row asking whether a safety-critical step is affected, with two labelled branches in the Line text column. Route "Yes" into a documented safety impact assessment and "No" into a standard suitability review; never let a requester or approver skip the question by assumption.
Gate the safety-critical path on hands-on retraining, not acknowledgement
After approval, schedule mandatory hands-on training and require a signed competency checklist before the change can go live. A row that only says "read and acknowledge" belongs on the standard path, not the safety-critical one: keep the two as separate rows so the distinction survives a later reorder.
Converge both paths on one register update
Whichever branch a change took, route it into a single File-shaped row that updates the SOP register and marks the previous revision superseded, before publishing the new one as current. One convergence point means one place to check that every path actually reaches retirement of the old copy.
Confirm every affected operator, not just the rostered ones
Before publishing, check off retraining or acknowledgement against every shift and every contractor the step touches, not only the team that happened to be on site when the change was approved. A missed night shift is the finding that recurs every audit cycle.
Frequently asked questions
Is SOP version control different from generic document version control?
Yes, in one specific way: an SOP's version control has to answer who needs retraining before the new revision takes effect, not just which copy is current. Generic document version control (covered in /guides/version-control-for-documents) governs numbering, approval and withdrawal for any controlled document. An SOP adds a competency question underneath that: a bumped revision number does not stop an operator running the old method until they have been retrained on the new one, so the version-control record for an SOP has to carry a training or acknowledgement status alongside the usual approval trail.
How should a safety-critical SOP change be routed differently from a minor one?
A safety-critical change (one where getting the step wrong risks injury, a nonconforming product or a regulatory breach) needs a documented safety impact assessment, a QA-gated approval, and hands-on retraining with a signed competency checklist before it can go live. A non-safety-critical change can go through a standard suitability review, ordinary approval, and read-and-acknowledge. Routing both through the same lightweight path is how a wording tweak and a change to a lockout step end up held to the same evidence standard, which is too little for one and too much for the other.
Is a training record the same thing as version control for an SOP?
No: they answer different questions and an SOP process needs both. Version control tracks which revision is current, who approved it and what it replaced; a training record tracks who has demonstrated competency on that revision. QueryChart's version history at /features/version-control covers the first: a Change Log with per-field diffs, a Compare Versions view and restore. The signed competency checklist a safety-critical change requires, described above, covers the second, and the two need to reference the same revision number or an auditor cannot tell whether the person trained matches the procedure in force.
What is the minimum evidence an auditor expects for an SOP revision?
A revision number and effective date printed on the document, a record of who approved it and when, a documented reason for the change tied to the request that started it, and, for anything safety-critical, a dated, signed competency record naming who was retrained and on what version. For the routing and approval mechanics of the SOP document itself, see the controlled SOP template at /templates/sop-controlled-sop-template; for the narrower question of what changed between two revisions, see /guides/how-to-track-changes-in-an-sop.