Document change control workflow flowchart

What the document change control workflow process is

Document change control is narrower than document control and different in kind from IT change management, and it is worth keeping the three apart. The full lifecycle of a governing document, request through drafting, approval, issue and periodic review, is the document control process at /templates/document-control-process. The gates a proposed change to a system or a service goes through, impact assessment, CAB approval, a rollback plan and a deployment window, are the change control process at /templates/change-control-process. This chart is neither of those. It is the specific sub-procedure that fires the moment a document already in force needs to change: how the revision gets classified, reviewed, approved, versioned and pushed out, and how the copy it replaces is formally withdrawn. There is no CAB here, no rollback window, no deployment language, because a document revision is not a system change.

The decision most written procedures skip is right at the front: "Change classified as minor or major?" A wording fix, a formatting correction or a typo does not need the same scrutiny as a change to what the document actually requires, and treating every change identically either drags trivial edits through a full review cycle or lets a substantive change slip through on the fast track meant for typos. This chart draws the fork explicitly, so a minor change is prepared and approved quickly while a major one goes to the change reviewer for a recorded impact assessment before it reaches the same approval gate.

The two steps that most distinguish this workflow from a generic revision process are both about what happens after approval. "Update version number and distribution list" treats the version stamp and the list of who holds a current copy as one action, not two, because a document whose version changed but whose distribution list did not is exactly how someone ends up working from a copy that is one revision behind. And "Withdraw and mark previous version superseded" gives the old copy an explicit, recorded exit rather than letting it fade out of use on its own, with the distribution list holders acknowledging the withdrawal so there is a record of who was told.

What this flowchart covers

In this template

• Five lanes, Requester, Document owner, Change reviewer, Document controller and Distribution list holders, across five phases: Request, Assessment, Approval, Version & Distribution and Supersession.
• Intake: "Change to a controlled document identified" leads into "Submit document change request", which captures the document ID, current version and reason for change, then "Log the request against the document record".
• The classification fork: "Change classified as minor or major?" routes a minor change straight to "Prepare the fast-track edit", while a major change goes to "Change reviewer assesses the full impact" and "Record impact on related documents and forms" first.
• Both paths converge on the Approved? decision, whose Rejected branch returns to "Revise the draft and resubmit for review" and loops back into the reviewer stage rather than ending the request.
• The version and distribution phase, owned by the Document controller: "Update version number and distribution list", "Publish the new version to the controlled location", then "Notify distribution list holders of the new version".
• Formal supersession: "Withdraw and mark previous version superseded" and "Distribution list holders acknowledge the withdrawal", ending at "Document reissued under formal change control".

When to use this template

• You are writing the specific sub-procedure for how a single controlled document changes, and you want it separate from the broader document control lifecycle so the two do not get conflated in an audit.
• Superseded copies keep turning up alongside the current version, and you need an explicit versioning and withdrawal step rather than trusting that people will notice the old one is gone.
• Every change is currently routed through the same heavyweight review, and trivial wording or formatting fixes are backing up behind changes that actually alter a requirement.
• Your distribution list is a spreadsheet nobody remembers to update, and you want the version stamp and the list update to happen as one step rather than two that can drift apart.
• An auditor or certification body has asked how you know every holder of a controlled document was told about a revision, and you need that notification and acknowledgement drawn as a step, not assumed.

How it works

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

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

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

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

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

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