SOP change control process flowchart
A SOP change control process flowchart with Requester, Process owner, Safety or QA reviewer, Approver and Trained operators lanes: safety-critical routing, QA-gated approval and mandatory hands-on retraining before go-live.
How it works
Rename the lanes to your real roles
Replace Requester, Process owner, Safety or QA reviewer, Approver and Trained operators with the roles you actually have. If the same person assesses impact and grants approval on non-critical changes, merge those lanes rather than pretending they are separate; keep Safety or QA reviewer distinct if your operation expects an independent safety sign-off.
Define what makes a step safety-critical
Write the threshold next to the "Safety-critical step affected?" decision: a step is safety-critical if getting it wrong risks injury, a nonconforming product, an environmental release or a regulatory breach. Give two or three examples from your own operation so the reviewer is not making the call from a blank page every time.
Set the evidence a hands-on sign-off requires
At the hands-on training and competency checklist step, decide what counts as proof: a supervised run-through, a practical assessment, a trainer's signature, or all three. Record the SOP version the operator was trained against, since a competency record with no version number cannot prove they were trained on the current one.
Decide when read-and-acknowledge is enough
For the standard track, set the bar for what qualifies as a non-safety-critical change, for example clarifying wording, reordering steps with no change in method, or correcting a reference number. Store acknowledgements somewhere you can pull a completion list from, not an email thread.
Name who can reject and where the loop lands
Both approval decisions route a rejection back into the assessment or review step rather than closing the request. Confirm who has authority to reject on each track, since a QA-gated rejection on a safety-critical change should carry more weight than a rejection on the standard track.
Frequently asked questions
How is this different from a general change control process?
A general change control process is written for IT and engineering changes: it routes through a change advisory board, plans a rollback, and verifies a deployed system. This chart is written for a change to a written work instruction, and its distinguishing step is retraining: a safety-critical change cannot go live until the affected operators have completed hands-on training and signed a competency checklist, not merely acknowledged that a new version exists.
How is this different from the document control process?
The document control process is the general lifecycle every controlled document follows, draft, review, approval, versioning, issue, withdrawal of superseded copies and periodic review, and it applies to policies and forms as much as to SOPs. This chart assumes that machinery exists and adds what is specific to an SOP: a safety-critical gate that decides whether rollout requires supervised hands-on retraining with a signed competency checklist, or a lighter read-and-acknowledge.
Why does a safety-critical change need a signed competency checklist instead of just a read receipt?
A read receipt proves someone opened the document; it does not prove they can still perform the step correctly. For a step where a mistake risks injury, a nonconforming product or a regulatory breach, most quality and safety systems expect demonstrated competency: a supervised run-through, a practical check, or an equivalent sign-off recorded against the specific SOP version the operator was trained on.
Who decides whether a change is safety-critical?
Route the call to a safety or QA reviewer who is independent of the person requesting the change, not the requester or their direct manager. Write the threshold down next to the decision so the call stays consistent across reviewers, and default to the safety-critical track whenever it is genuinely unclear.