SOP revision history template

What the sop revision history process is

A revision history log is the register that answers one question for an SOP: what changed, when, who made the change, who approved it, and which version does the current one replace. It is a separate artifact from the SOP itself: the procedure describes how the work is done today, the revision history is the append-only record of every version that came before it. Auditors and new process owners read the log first, because it is the fastest way to establish whether the procedure in front of them is the controlled current version or something a reviewer forgot to update.

This chart models the log as its own workflow rather than as a footnote to SOP approval. A proposed change is checked against safety criticality to decide whether it goes through expedited or standard review, then checked against the log itself: if another entry for the same SOP is already open, the two changes are coordinated so the log never has to reconcile two entries claiming the same version number. Only after that does drafting produce the actual log entry (date, change summary, author and the version number it supersedes) which is why the drafting and finalizing steps use the File shape rather than Process: they are the moments something is written to the register, not just moved along.

This is not the SOP document's own approval workflow, which is the controlled SOP template at /templates/sop-controlled-sop-template: that page routes the procedure's content through drafting, review and sign-off. It is the register that workflow writes an entry to every time it produces a new version. It is also narrower than general document control, which governs drafting, issue, distribution and periodic review for every kind of controlled document at /templates/document-control-process; this chart covers only the log itself, the artifact that names what changed and which version it replaced.

What this flowchart covers

In this template

• Five phases across the top (Change identified, Log entry drafted, Review, Approval and Log finalized) matched to five lanes for the roles that touch a revision history entry: Process owner, SOP author, Reviewer, Approver and Document controller.
• Intake and routing: a change is identified and described, then a 'Change affects a safety-critical step?' decision sends it to expedited or standard review before drafting starts.
• A duplicate-entry check before drafting: 'Revision history log already has a pending entry for this SOP?' routes to coordinating with the owner of the open entry, so two changes to the same SOP are never logged as two competing revisions.
• The entry itself, drafted and later finalized with the File shape rather than Process: date, change summary, author and the version number it supersedes, submitted for review and then for approval.
• A review loop: 'Comments to resolve before approval?' sends the entry back to the SOP author for updates and re-review rather than forcing the approver to reject it outright.
• Approval and closure: an 'Approved?' decision either returns the entry to rework on Rejected or lets the document controller record it as final, update the SOP's version number and effective date, and archive the version it replaced.

When to use this template

• You are setting up a revision history log for SOPs and want a structure that separates intake, drafting, review, approval and finalization rather than one open-ended 'append a row' step.
• Two people can propose changes to the same SOP at once, and you need a checkpoint that catches a duplicate entry before it reaches approval as two competing revisions.
• You need to show an auditor how a specific line in the revision history log came to exist: who proposed the change, who reviewed it, who approved it, and which version it replaced.
• You are separating the revision history log from the SOP approval workflow itself, because the same log has to record changes proposed against one SOP by more than one owner over its lifetime.

How it works

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.