SOP revision history template
An SOP revision history template: how a proposed change to an SOP becomes a dated log entry, is checked against pending changes, reviewed, approved and finalized with the version it replaces.
How it works
Rename the lanes to your real roles
Replace Process owner, SOP author, Reviewer, Approver and Document controller with the titles you actually use. In a small team the SOP author and the process owner are often the same person — merge those lanes rather than keeping an empty one; if a quality lead does both the review and the sign-off, merge Reviewer and Approver instead.
Fix the safety-critical test
Write down what routes a change to expedited review rather than leaving 'Change affects a safety-critical step?' to individual judgment: a change to a lockout step, a critical control point or a regulatory-mandated check should always qualify, and everything else defaults to the standard cycle.
Set the fields every log entry must carry
At the drafting step, fix the exact fields your register needs: entry date, SOP number, a plain-language change summary, author, and the version number being superseded. Keep the fields identical for expedited and standard entries so the log stays consistent regardless of which route produced it.
Decide how a duplicate entry gets resolved
Set the rule behind 'Revision history log already has a pending entry for this SOP?': does the second change wait for the first to close, get merged into the same entry, or get logged separately with a note cross-referencing the other? Any of the three works as long as the log never ends up with two entries claiming the same version number.
Set your version numbering and effective-date rule
Fix how version numbers increment — whole numbers for issued revisions and decimals for drafts is common — and how much lead time the effective date needs so the document controller can update the master register and retire the superseded copy before it takes effect.
Frequently asked questions
What is an SOP revision history log?
It is the dated register that lists every version of an SOP and what changed between them: the date of the entry, who proposed the change, a summary of what changed, who reviewed and approved it, and the version number it replaced. It is separate from the SOP's own approval sign-off — the SOP records who approved the current version, the revision history log records the sequence of versions that got it there.
How is this different from the SOP's own approval workflow?
The controlled SOP template at /templates/sop-controlled-sop-template routes the procedure's content itself through drafting, review and approval and produces one current, signed-off version. This chart is the register that workflow writes to every time it produces a new version — the append-only history of dates, authors, summaries and superseded version numbers, kept as its own artifact so the sequence survives independently of the document.
Why check for a pending entry before drafting a new one?
Because two people can propose changes to the same SOP within the same review cycle without knowing about each other, and if both entries reach approval independently, the log ends up with two rows each claiming to supersede the same version. Checking at the start, before drafting, means the second change is coordinated into the first entry rather than discovered as a conflict during approval.
Does every SOP change need to go through the expedited path?
No. The expedited path exists for changes to safety-critical steps, where the interval between identifying the change and it taking effect has to be short. Everything else — clarifications, formatting, non-critical procedural changes — should go through the standard review cycle, since routing everything as expedited defeats the purpose of having two tracks.