A controlled document under ISO 9001 moves through nine distinct states between the moment someone requests a change and the moment the record is legally allowed to disappear: request, draft, review, approval, publication, controlled distribution, uncontrolled distribution, superseded or withdrawn, and retention-to-disposal. An automated quality system doesn't skip any of these — it mirrors each one in a system of record so nothing gets lost between a paper form and a shared drive folder.
Most document control breaks down not because people don't know the steps, but because the steps live in different places: a paper change-request form in a drawer, a Word doc on someone's desktop, a distribution list in someone's memory. This article maps all nine steps as they actually function in a working QMS, and shows where automation belongs and where it doesn't.
Why nine steps, not five or twelve
ISO 9001:2015 clause 7.5.3 requires that documented information be controlled for distribution, retrieval, storage, protection, change control, and retention or disposal. Different QMS practitioners slice this into anywhere from five to fifteen steps. Nine is the number that matches what actually happens on a factory floor, because it separates two steps that are commonly merged and cause real problems when they're not:
- Controlled distribution and uncontrolled distribution are different states, not one "distribution" step — a controlled copy is tracked and recalled on revision; an uncontrolled copy (a PDF handed to an auditor, a printout for a customer visit) is explicitly not tracked and must be labeled as such.
- Approval and publication are different steps — approval is a human decision; publication is the clerical act of making the approved version the current one everywhere it needs to exist.
Collapsing these causes real failures. Teams that don't separate approval from publication end up with an approved document sitting in someone's inbox for two weeks while the old revision stays live on the floor.
The nine steps in order
| # | Step | What happens | Who owns it |
|---|---|---|---|
| 1 | Request | Someone identifies a need for a new document or a change and submits a request | Requester (any employee) |
| 2 | Draft | The document or revision is written | Document owner / process owner |
| 3 | Review | A reviewer checks content adequacy — is this technically correct and complete | Reviewer (Gate 1) |
| 4 | Approval | An approver signs off that the document is fit to release | Approver (Gate 2) |
| 5 | Publication | The approved version becomes the current controlled version, numbered and dated | QMR / DCC |
| 6 | Controlled distribution | Copies go to the departments on the distribution matrix, tracked by copy number | DCC |
| 7 | Uncontrolled distribution | Copies issued for reference only (audits, customers, regulators), explicitly marked uncontrolled | DCC |
| 8 | Superseded / withdrawn | The prior revision is pulled from circulation when a new one publishes | DCC |
| 9 | Retention and disposal | The record is kept for its defined retention period, then disposed of on schedule | QMR / records owner |
Where each step happens in an automated quality system
We built this exact nine-step lifecycle for a Thai manufacturer's document-control workflow, mapping it onto real Google Drive folders — moving a document between folders is the human decision, a reviewer or approver acting on it; the automation only reacts to that folder move, it never initiates one. A person decides. The system watches for that decision and does the paperwork that follows it.
Steps 1 through 4 in that build are governed by the four human decision gates — reviewer and approver sign-offs that no automation touches. Steps 5 through 9 are where clerical automation earns its keep: once a document clears Gates 3+4, the combined master sign-off, the system writes the fields that used to be retyped by hand into three or four different registers.
Step 5: publication is where numbering bugs live
Publication is the step most Thai manufacturers get wrong without knowing it, because it's where a revision number, an effective date, and a document code all get typed by hand into multiple places — the document itself, the amendment record, the master document list. Every place that number gets typed by hand is a place it can get typed wrong, and a wrong revision number on a controlled document is a nonconformance waiting to be found.
Step 6: controlled distribution needs a real matrix, not a memory
A controlled copy has to reach every department that's supposed to have the current revision, and the old revision has to be pulled from those same departments. This only works reliably against an explicit distribution matrix — in the build referenced above, a ten-department matrix updated as one of the automated writes once a document publishes. Without a written matrix, "who has a copy of this" becomes a question someone has to answer from memory during an audit.
The eight things that happen automatically after step 4
Everything from step 5 onward is repetitive, rule-based, and doesn't require judgment — exactly why it's worth automating and exactly why it's risky to do by hand under time pressure. In the reference build, once a document clears final sign-off, the system writes eight fields a DCC previously retyped by hand across separate registers: revision number, effective date, amendment-record entry, the master document list row against the ten-department matrix, the change-register entry, a year-keyed request number, page count, and a calculated retention/disposal-due date. Read the full breakdown of what those eight fields are and why each one matters on its own.
Every one of those eight writes is individually logged to an activity log, and the workflow is idempotency-keyed, so replaying the same approved event never duplicates a register entry — a real risk when someone re-runs a step after a network hiccup or resubmits a form they're not sure went through.
Step 9: retention and disposal is the step everyone forgets
Clause 7.5.3.2 requires you to define retention periods and disposal methods for controlled documents, and most factories do define them — on paper, in a procedure nobody re-checks. The gap is operational: nobody is tracking, in real time, which documents are approaching their disposal-due date. A working system calculates that date the moment a document is approved and carries it forward as a field on the record, not a note in a procedure someone has to remember to check.
How this differs from just buying a DMS
Plenty of factories already own a document management system — SharePoint, a QMS module bolted onto an ERP, or a dedicated tool. A DMS gives you version control and storage. It does not, by itself, give you the nine-step lifecycle, because a DMS doesn't know your distribution matrix, doesn't calculate your retention date against your specific procedure, and doesn't log every clerical write for audit traceability unless someone configures it to. The lifecycle is a workflow that runs on top of storage, not a feature you get from storage alone. That's the gap between "we have a shared drive" and "we have a controlled document lifecycle" — and it's the gap most factories discover during an external audit, not before one.
What to check before you automate any of this
Get honest answers to three questions before mapping your own nine steps onto a workflow tool. Where does each step currently live — paper form, email, shared drive, someone's head? Which step has the most manual retyping — usually steps 5 through 7. And who currently owns the retention/disposal calculation, if anyone does? If the answer to that last one is "nobody, we check when we remember," step 9 is where to start.
FAQ
Does automating steps 5–9 mean the system approves documents?
No. Automation in this model only starts after a human has already approved a document through Gates 1–4. It never evaluates content adequacy — that judgment stays entirely with your reviewer and approver.
What's the difference between controlled and uncontrolled distribution?
A controlled copy is tracked, numbered, and recalled when superseded — the recipient is expected to always have the current revision. An uncontrolled copy (for an audit, a customer visit) is explicitly marked as not tracked and not guaranteed current.
Can this nine-step model work with a paper-based system, or does it require full automation?
The nine steps describe what clause 7.5.3 requires regardless of tooling. You can run all nine on paper. Automation doesn't change the steps — it removes the manual retyping between steps 5 and 9, where transcription errors and missed updates actually happen.
How is the retention/disposal date calculated?
It's derived from your defined retention period, set in your procedure, applied against the document's approval or effective date, so the due date is calculated once, correctly, rather than computed manually each time someone audits the register.
Does this require replacing our existing Google Sheets or Drive setup?
No. A well-built ISO automation layer runs on top of tools you likely already use — the reference build runs on n8n with Google Sheets as the register backend and real Google Drive folders as the lifecycle mirror.
There's no generic checklist that captures your specific nine steps — your distribution matrix, your gate structure, your retention rules are all different from the factory next door. If you'd rather walk your actual document list against this lifecycle than read a template, book a free consultation with 1% EVO: we go through it with you on the call, against your own SOPs.