How to track changes in an SOP
How to track changes in an SOP: what a revision history entry has to record (what changed, who changed it, when, why, and which version it replaces) plus the safety-critical fast-track split.
A worked example, stage by stage
What gets recorded, before anything else
The chart starts at "Change to an SOP identified," then "Describe the proposed change and the reason for it" (the SOP, the step, what's changing, why, and the effective date) before "Change affects a safety-critical step?" decides which review path the entry takes.
The fast-track split and the duplicate check
A safety-critical change is "flagged for expedited review" while everything else is "routed through the standard review cycle"; both then hit "Revision history log already has a pending entry for this SOP?" before "Draft the revision history entry: date, change summary, author, version superseded" is written as a File row.
Two checks before an entry is trusted
"Reviewer checks the entry against the current SOP content" comes first; "Comments to resolve before approval?" loops an unresolved entry back through the SOP author for a re-review, and only then does the Approver check it against "the SOP master and the version it supersedes."
Finalized, then the old version is closed out
"Record the approved entry as final in the revision history log" locks the date, approver and version numbers before the SOP's own version number and effective date update, and "Withdraw or archive the version referenced as superseded" closes out the entry the new one replaced.
How it works
Record the five fields on every entry
Write down the SOP and step affected, what changed and why, the effective date, the author, and the exact version number this entry supersedes. An entry missing the superseded version leaves a gap in the log nobody can close after the fact.
Route safety-critical changes onto the fast track
Ask whether the change touches a safety-critical step before it goes to review. If it does, flag it for expedited review rather than letting it queue behind routine changes; if it doesn't, send it through the standard review cycle.
Check for a pending entry before you draft
Search the log for an entry already open against the same SOP before starting a new one. Two open entries against one procedure produce two candidate version numbers: coordinate with the other author or sequence the changes instead of drafting in parallel.
Lock the entry once it's approved
Record the approved entry as final, then update the SOP's version number and effective date and withdraw the version it replaces. An entry that stays editable after approval is not a record, it's a draft with an approver's name on it.
Let the Change Log do the recording for a chart-based SOP
If the SOP itself is a QueryChart flowchart, skip the manual log for anything captured on the chart: every edit is already tracked field by field. Open Version History, use Compare Versions to see what changed between two saved versions, and restore an earlier one in a click: see /features/version-control.
Frequently asked questions
Is "track changes" the same as version control for an SOP?
Not quite. "Track changes" is document-editor language for inline redlines and comments inside one file. Version control for an SOP is the practice of giving each approved state of the procedure its own identified version and keeping a record of what changed between them; a revision history entry is how that record gets written down. See /guides/version-control-for-sops for the fuller distinction.
What does a revision history entry need to record?
Five things regardless of who writes it: the SOP and step affected, a plain-language description of the change and the reason for it, the effective date, the author, and the exact version number the entry supersedes. Missing the superseded version is the single most common gap in a revision history log.
Do all SOP changes go through the same review?
No. A change to a safety-critical step takes an expedited review path rather than queuing behind routine changes, while everything else goes through the standard cycle. Both paths converge on the same duplicate check before drafting: is there already a pending entry open against this SOP?
How is this different from managing SOP revisions generally?
This page is about the mechanics of one entry: the fields it needs, the review split, the duplicate check. The numbering scheme, review interval and who owns the schedule across every SOP is the governance layer, covered at /guides/how-to-manage-sop-revisions.
Does QueryChart replace the manual log?
For a chart-based SOP, yes for anything captured on the chart itself: every field-level edit is recorded automatically in Version History, with a Compare Versions view and one-click restore: see /features/version-control. A manual log is still worth keeping where the SOP's content lives outside the chart, or where a standard names a revision history log as its own artifact, such as the fuller lifecycle at /templates/sop-controlled-sop-template.