How to create a document control process
How to build a document control process that governs the superseded copy as well as the new one: an identifier and a revision, one authoritative location, a withdrawal step, and a dated periodic review.
A document control process governs a document from the request that starts it through to retirement, so that exactly one identified revision is in use and every copy it replaced has been withdrawn.
The short version
- Number and revision, printed on every page, or the document is not identified at all.
- Publishing the new revision is half the step; taking the old one out of use is the other half.
- Withdrawal needs a list of places the old copy lives: noticeboards, shared drives, supplier packs.
- Periodic review has three outcomes (keep it, revise it, retire it) and two are usually missing.
- Distribution and training sit inside document control, not downstream of it.
Control is what happens to the old version
Every organisation that writes procedures builds the same chain (draft, review, approve, publish) and then finds that almost no audit finding is ever about the chain. The findings are about the other half: an obsolete work instruction still pinned beside a machine, a form being filled in on a revision the register retired two years ago, a procedure nobody has opened since the site was reorganised. Issuing a document is not control. Accounting for the one it replaces is.
Four properties turn a published file into a controlled one: a unique identifier with a revision printed on every page, one authoritative location that every other reference links to rather than copies, a withdrawal step for the revision being replaced, and a review interval with a due date and a named owner. The third decides whether the other three mean anything, because a register can be immaculate while the old printout stays on the wall.
One document's whole life is drawn below across five lanes, from the Author to the End users. "Withdraw superseded copies from use" holds a row of its own in the Document controller lane rather than being left as an implication of publishing. The "Revise" exit from "Document still valid?" returns to "Raise a document change request", so a periodic review re-enters the process at the top instead of starting a second one alongside it.
The same chain, with the withdrawal in it
Requested, drafted, approved, issued, then the copy it replaces is pulled from use and a review clock starts. One document's whole life in five lanes.
A request before a draft
The Start is an occurrence rather than a task ("Document need or change identified"), and "Raise a document change request" comes before anyone opens the file. Only then does "Draft or revise the content" appear, with the reason for it already recorded.
The review loop is the schedule
"Comments to resolve?" sends the draft to "Update the draft against comments", which points back at "Carry out technical review" on a branch labelled "Re-review". The Approver's "Approve for issue?" rejects into that same row, so both kinds of rework share one path.
Issue, register, publish, withdraw
The Document controller lane fills with four rows: a version and an effective date, the master document register written as a File row, publication to the controlled location, then "Withdraw superseded copies from use". The last of the four is the one most processes leave out.
A document in use is not finished
Training or an acknowledgement, then use, then a scheduled review with three labelled exits. "Valid" records the outcome and the next date, "Revise" returns to the change request, "Retire" ends at "Document withdrawn and retired": an outcome this process can actually reach.
How it works
Decide which documents you will control
Controlling everything is the quickest route to controlling nothing. Write down the classes that carry an obligation (procedures, work instructions, forms, specifications, external documents) and the classes that do not, such as meeting notes and working files. Everything on the first list needs an owner, an identifier and an interval.
Fix the identifier and revision scheme
Whole numbers for issued revisions, decimals for drafts, and the identifier, revision, effective date and approver in the header of every page. The scheme matters less than its stability: renumbering a library later breaks every cross-reference, every training record and every audit trail that cited the old number.
Type the lifecycle into rows, request first
Open a chart and put each stage in the Box text column, beginning with the event that identifies the need and the change request that follows it. Join them using the Line to column, which takes the row number a step leads to. The layout is generated, so sequence is the only thing being decided here.
Give withdrawal and the register their own rows
The register row takes File in the Shape column, so the record it writes shows on the diagram, and withdrawal stays a separate row after publication. Use the Vertical lane column to put both in the document controller's lane. A withdrawal that shares a row with publishing is the step that gets skipped when publishing is rushed.
Label the three review outcomes
Set the review row's Shape to Decision and write its answers into the Line text column, one per number in Line to: valid, revise, retire. The revise number points backwards, at the change request near the top of the sheet. Connections are data, so that loop is simply a smaller number and it survives every later reorder.
Walk the withdrawal list before you trust it
Take the last revision you issued and go looking for its predecessor rather than reasoning about where it might be: search the drive, walk the floor, open the induction pack, ask the customer who holds your quality file. Every copy you find is a point of use to name in the withdrawal step, and the count is the finding to report.
Mistakes to avoid
The copy that left the building
A revision sent into a customer's quality file or a supplier's induction pack is beyond recall, and it is the copy an auditor asks to see. Record every external issue against its recipient, so a reissue is a list, not a memory test.
Printouts nobody has to account for
An uncontrolled printout outlives every revision issued after it. Either stamp and register the copies you permit, or forbid them and provide a screen. The third position, which is most organisations' real policy, is not a control.
Stamping a year's reviews in one week
Two hundred documents re-approved in a week have not been reviewed, they have had their dates refreshed. Stagger the intervals by risk so that a review is a piece of work somebody has been given time to do.
Retirement by deletion
Removing an obsolete document destroys the evidence of what the rule was when the work was done. Retirement is a state in the register, not an absence from it: the row stays and gains a withdrawal date and a name.
Related QueryChart feature
Create your own document control process
Take the document control example as your own chart, set your revision scheme, and list every place a superseded copy has to be pulled from.
Related guides
Frequently asked questions
What makes a document a controlled document?
Four things are true of it: it carries a unique identifier and a revision, it has an approval record naming who authorised that revision and when, exactly one location holds the authoritative copy, and it has a review interval with a named owner. Format is irrelevant: a spreadsheet, a diagram and a wiki page can all be controlled documents. What makes the control real is that an obsolete revision cannot be mistaken for the current one, which is why withdrawal belongs in the definition and not in the small print.
How should obsolete documents be handled?
Withdraw them from every point of use, then keep one archived copy marked as superseded for the retention period. Withdrawal is a listed activity rather than a note: name the noticeboards, workstations, shared folders, intranet pages and external packs the revision reached, and tick them off. Deleting the old revision is the common error, because an investigation a year later needs to know which rule was in force at the time, and the archive is the only place that answer survives.
Does ISO 9001 still require a document control procedure?
Not as a named procedure. ISO 9001:2015 dropped the six mandatory procedures in favour of clause 7.5, which requires documented information to be identified, approved before use, available where it is needed, protected from alteration, and controlled for distribution and disposition. That is a document control process whether or not one is written. Auditors sample it as they always did: take a work instruction at the point of use, check its revision against the register, and ask who withdrew its predecessor.
What is the difference between a document and a record?
A document says what should happen and is revised; a record says what did happen and is not. The difference decides the controls: documents need revision numbers, one authoritative location and withdrawal of what they supersede, while records need retention periods, protection from alteration and retrievability. The same file can be both: a blank inspection form is a controlled document and the completed one is a record. Conflating them produces records edited after the fact and documents kept forever.
How is this different from a document version control guide?
This guide covers the whole request-to-retirement process: intake, drafting, review, approval, issue, withdrawal and periodic review. Version control is the narrower mechanic inside it: the numbering scheme, the version metadata on every page, and deciding what makes a revision major versus minor. See /guides/version-control-for-documents for that mechanic on its own, /guides/document-version-control-best-practices for how to keep it trustworthy over years of turnover, and /guides/document-version-control-iso-9001 for the ISO 9001 clause 7.5 version-control angle specifically.