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 worked example, stage by stage
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.
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.