Document Control: Process, Policy and Version History

Almost every article on document control opens by describing a place to store files. That is document management, and it is a different problem. Document control is the discipline that decides who may change a document, which version is authoritative, who has been told about the change, and how you prove any of it six months later in front of an auditor.

Document control is not document management

The distinction is worth being precise about, because it decides what you actually need to build.

Document management is about storage and retrieval. Where does the file live, who can find it, is it backed up, can I search it. A shared drive does some of this. A proper platform does it much better.

Document control is about authority. Which version is the one people must work from, who is allowed to approve a change, who had to be notified when it changed, and what happened to the copy that is now out of date. None of that is a storage question.

You can have excellent document management and no document control at all.

That is, in fact, the normal state of affairs: everything is neatly filed, everything is searchable, and three departments are working from three different revisions of the same procedure because nobody owns the question of which one is current.

The reverse also happens, and is less dangerous. A small workshop with a single controlled binder, signed and dated, has document control and almost no document management. It is inconvenient. It is not an audit finding.

Everything that follows is about the second discipline. Most published document control best practices quietly assume you have already made this distinction, which is why they so often fail to fix anything: they optimise the filing while the authority question stays open.

What a document control process actually contains

A complete document control process has seven stages. Most organisations have three or four of them working and have never written down the rest, which is where the gaps appear.

1. Identification. Every controlled document gets a unique identifier and a title that means the same thing to everyone. This sounds trivial. It is the stage most often skipped, and skipping it makes every later stage ambiguous.

2. Numbering and classification. The identifier encodes something useful — document type, owning function, sequence. See the next section; this is where a document control numbering system either helps for a decade or becomes a thing people work around.

3. Review and approval. Before a document becomes effective, named roles review it for technical accuracy and approve it for use. The two are different jobs and are frequently collapsed into one signature, which is how documents that are correct but unusable get issued.

4. Distribution and access. The people who need the document can get the current version, and know that what they are holding is current. This is also where you decide who may only read and who may edit.

5. Revision. Changes are made under the same review and approval discipline as the original, the revision is identified, and the nature of the change is recorded. "Updated" is not a description of a change.

6. Withdrawal and obsolescence. Superseded versions are removed from the point of use. If an obsolete copy is retained for legal or knowledge reasons — and often it must be — it is marked so that nobody can mistake it for the live one.

7. Retention and disposition. How long each class of document is kept, and what happens at the end of that period. This is a decision with legal input, not an IT default.

Written as a document control process flow, those seven stages form a loop rather than a line: revision feeds back into review and approval, and every pass through the loop produces a new authoritative version and a new obsolete one.

A document control numbering system that survives contact with reality

Numbering schemes fail in two opposite ways. They are too thin, so everything is DOC-001 through DOC-4000 and the number tells you nothing. Or they are too clever, so the number encodes department, site, process, sub-process, author and year, and it breaks the first time somebody reorganises the departments.

A workable middle looks like this:

QP-PRD-014 Rev 3

• QP — document type. Quality Procedure. A short, closed list: policy, procedure, work instruction, form, register.
• PRD — owning function. Production. Also a short, closed list.
• 014 — a plain sequence within that combination. Not meaningful, and deliberately so.
• Rev 3 — the revision. Separate from the identifier, because the identifier must never change.

Three rules make the difference between this working and not:

The identifier is permanent. Once QP-PRD-014 exists, that string refers to that document for as long as the document exists, including through revisions, retitling and reassignment to another owner. If the number changes, every reference to it in every other document is now wrong.

Numbers are never reused. When a document is withdrawn, its number retires with it. Reissuing QP-PRD-014 for something else two years later guarantees that somebody, eventually, will pull the wrong record.

Encode only what will not change. Document type is stable. Function is fairly stable. Site is sometimes stable. Project code, cost centre and the author''s initials are not, and putting them in the identifier means either a wrong number or a renumbering exercise.

If you are inheriting a numbering system that already breaks these rules, do not renumber everything. Freeze the old scheme, start the new one alongside it, and let the old documents age out through normal revision. A big-bang renumbering creates exactly the confusion the system exists to prevent.

Writing a document control policy

The document control policy is itself a controlled document, which is a useful test: if you cannot apply your own process to it, the process is not finished.

A serviceable policy answers these questions and stops:

• Scope. Which documents are controlled. Just as importantly, which are not — if everything is controlled, nothing is, because the overhead collapses the discipline.
• Roles. Who authors, who reviews, who approves, who issues. Named roles, never named people; people leave.
• The numbering and revision convention. Stated once, here, and referenced everywhere else.
• Approval authority by document class. A form does not need the sign-off a policy needs, and pretending otherwise is why approvals get rubber-stamped.
• Distribution and acknowledgement. How people are told, and whether they must confirm they have read it. Acknowledgement is expensive; require it only where it matters.
• Retention periods by class, with the legal basis noted.
• How external documents are handled — customer drawings, supplier specifications, the standards themselves. These are controlled but not authored by you, which makes them the most commonly mishandled category.

We have deliberately not published a fill-in-the-blank policy template here. A template that nobody owns goes stale, gets copied into a live management system, and quietly contradicts the standard it was supposed to satisfy. The structure above is more useful and cannot rot in the same way.

Version control, and why final_v3_FINAL.docx is an audit finding

Everyone recognises the filename. It is worth being clear about why it is a genuine problem rather than an office joke.

A filename is not a version control policy. It carries no approval, no effective date, no record of what changed and no indication of what it superseded. When two people each have a copy, nothing in the file resolves which is authoritative.

And critically, the information an auditor asks for — show me that the person doing this job was working from the approved revision on the day they did it — simply is not present.

A version control policy worth having states four things:

What a revision is. Draw the line between a correction that does not change meaning and a change that does. Typo fixes and formatting should not consume revision numbers, or people stop reading revision notices. Anything that changes what someone must do is a revision.

How revisions are identified. Sequential and separate from the document identifier. Decimal schemes such as 1.1, 1.2, 2.0 work if you define what makes a change major, and are pure decoration if you do not.

What the revision history records. At minimum: revision, date effective, what changed, who approved. "What changed" is the field that gets left blank and the field an auditor reads first.

What happens to the old version. Removed from the point of use, retained in the record. Both, not either.

The practical test is a question you can ask yourself this afternoon. Pick a procedure that changed in the last year.

Can you produce, in under five minutes, the version that was in force in March, evidence of who approved the change, and confirmation that the affected team was told? If yes, your document control is real. If it takes an afternoon of searching, it is aspirational.

What ISO 9001:2015 actually requires

ISO 9001:2015 handles this under clause 7.5, Documented information. It is worth reading the actual structure, because the 2015 revision changed what is being asked for in a way many organisations still have not caught up with.

7.5.1 General covers what the management system must include: the documented information the standard requires, plus whatever the organisation itself determines is necessary for the system to work. That second half is the part people miss. The standard is explicitly asking you to make a judgement, not to produce a fixed list.

7.5.2 Creating and updating covers identification and description, format and media, and review and approval for suitability and adequacy. Those are the first three stages of the process above.

7.5.3 Control of documented information is the clause that carries document control in a quality management system proper. It requires that documented information is available where and when it is needed, and adequately protected.

It then lists the activities to be addressed:

• distribution, access, retrieval and use;
• storage and preservation, including preservation of legibility;
• control of changes, such as version control;
• retention and disposition.

It also requires that documented information of external origin is identified and controlled, and that anything retained as evidence of conformity is protected against unintended alteration.

Two things about the 2015 revision are worth stating plainly, because they change how much work this is.

First, the term "documented information" replaced the older split between "documents" and "records". They are now handled under one clause, with the distinction expressed as whether the information is maintained (a procedure you keep current) or retained (a record of something that happened).

Second, ISO 9001:2015 does not require a quality manual, and it does not require the six documented procedures that the 2008 version mandated — including the documented procedure for control of documents itself. This surprises people.

It does not mean document control is optional: clause 7.5.3 still has to be satisfied and you still have to be able to demonstrate it. What it means is that the standard no longer dictates the form. If your control is genuinely effective and evidenced, you have met the requirement without a procedure document titled "Control of Documents".

In practice most organisations write one anyway, because it is the easiest way to show an auditor the whole picture at once. That is a reasonable choice. It is just no longer a requirement, and knowing the difference stops you building paperwork for its own sake.

If your document control sits inside a wider quality system — inspections, non-conformances, corrective actions — the controls need to be the same ones. Running quality control management software on one revision discipline and your procedures on another is how the two drift apart between audits.

Where software takes over from procedure

Here is the honest part, and it is the reason to trust the rest of the article.

A small organisation with a disciplined naming convention, a single controlled folder, a revision-history table at the front of each document and one person who genuinely owns the process does not need a document control platform.

It will pass an audit. We have seen it pass audits. If that describes you, the right next step is to write the policy down and keep doing what you are doing.

That approach stops scaling at fairly predictable points:

• More than one site. The moment a second location holds its own copies, "remove obsolete versions from the point of use" becomes a manual task that someone will eventually not do.
• Approvals that need to be evidenced, not remembered. An email thread is evidence of a sort, until the approver has left and the mailbox is gone.
• Acknowledgement at scale. Confirming that 40 people read a revised procedure is a spreadsheet. Confirming that 400 did is a system.
• Retention that has to actually happen. Disposal schedules that depend on someone remembering do not run.
• Audit frequency. Once you are being audited more than annually, the cost of assembling evidence by hand starts to exceed the cost of a system that assembles it continuously.

Treating document control and management as a single purchase is where budgets go wrong, incidentally. They are separate capabilities with separate costs, and plenty of organisations need the storage side long before they need the control side.

The trigger is not headcount, it is how many of those five apply. Two is manageable. Four means the procedure is being held together by one person''s diligence, and that is a single point of failure with a notice period.

When it does become a software question, the thing to look for is not storage — every option stores files.

It is whether the platform enforces the seven stages: whether it can stop an unapproved revision becoming visible, record who acknowledged what, and produce the March version on demand. A document management system that only files things has solved the easier problem.

Document control is one discipline inside a much wider set of records an organisation has to keep current and evidenced — contracts, employee files, policy acknowledgements, training records. HCM software applies the same revision and approval logic to the people side of that record set.