Document change control workflow flowchart
A document change control workflow flowchart covering minor/major classification, reviewer impact assessment, approval, version stamping, distribution list updates and formal supersession of the previous version.
How it works
Rename the lanes to your real roles
Replace Requester, Document owner, Change reviewer, Document controller and Distribution list holders with the roles you actually have. In a small team the document owner and change reviewer are often the same person for anything but a major change; merge those lanes rather than drawing a review that never happens independently.
Write down what counts as minor versus major
The classification decision is only as good as the rule behind it. List examples: typo and formatting fixes, updated contact details and broken links are minor; anything that changes a requirement, a responsibility, an approval limit or a referenced control is major. Put the rule next to the decision so a requester can self-classify before it reaches the document owner.
Fix your version numbering scheme
At "Update version number and distribution list", decide the convention: for example a whole number for a major, approved revision and a decimal for a minor, fast-tracked one. State what has to appear on every page: document number, version, effective date and who approved it, so the number alone tells a reader whether they are looking at the current version.
Define the distribution list and who maintains it
Name the list this workflow updates: who is on it by role rather than by name, how someone is added when they join a team that uses the document, and how they are removed when they leave it. Decide whether notification is a broadcast or requires the acknowledgement this chart draws at "Distribution list holders acknowledge the withdrawal".
List every place a superseded copy could survive
"Withdraw and mark previous version superseded" is only executable if there is a checklist behind it: shared drives, printed copies at the point of use, intranet pages, induction packs, supplier or customer copies. Keep one archived copy marked superseded for your retention period rather than deleting it outright.
Decide what triggers the full impact assessment
At "Record impact on related documents and forms", list the categories a change reviewer must check: referenced procedures, linked forms, training materials and any other controlled document that quotes the section being changed. Each one that is affected needs its own change request rather than being fixed quietly inside this one.
Frequently asked questions
What is document change control?
It is the procedure that runs specifically when a document already approved and in use needs to change: how the change is requested, classified as minor or major, reviewed at a depth that matches that classification, approved, stamped with a new version, pushed to the people who hold a copy, and how the version it replaces is formally withdrawn. It is a sub-procedure of the wider document control lifecycle, not a replacement for it; document control also covers the first-time drafting and approval of a document before any change has happened.
How is document change control different from IT change management?
They share a shape, request, assessment, approval, implementation, but not a subject. IT or ITIL-style change management governs changes to systems and services: it needs a Change Advisory Board, a risk and downtime assessment, a scheduled change window and a rollback plan, because the thing changing is running infrastructure that can fail during the change. Document change control governs changes to a written artefact: a policy, procedure, work instruction or form. There is no downtime window and no rollback plan, because a document revision does not go live in the sense a deployment does; it replaces a superseded copy. The two are documented separately for the same reason a factory keeps its equipment change log apart from its procedure change log: different risks, different reviewers, different evidence.
How do you decide whether a document change is minor or major?
By what the change does to the document's requirements, not by how large the redline looks. A typo fix, a formatting correction, an updated job title or a broken link is minor, however many lines it touches. A change to what the document requires someone to do, who is responsible for a step, an approval threshold, a referenced standard or a safety instruction is major, even if it is a single word. Write the rule down next to the decision rather than leaving it to judgement on the day, so the same kind of change gets the same classification whoever raises it.
Why update the distribution list at the same time as the version number?
Because a version number that changed and a distribution list that did not is exactly how a controlled copy goes stale in someone's hands. The distribution list is the record of who is entitled to hold a current copy of the document; if it is updated separately from, or later than, the version stamp, there is a window where the new version exists but the people who need it have not been added, or someone who has left the role that uses it is still receiving it. Treating both as one step is what keeps the version on the document and the list of who holds it from drifting apart.