Which Version Applies? Controlling Documents Without Bureaucracy

Why the wrong version is so often used in a company

Almost every company knows the situation. A quote goes out with the payment terms from two years ago. A new colleague works by an inspection instruction that was changed long ago, because the printed version is still on the wall. On the shared drive there are Checklist_final, Checklist_final_new, and Checklist_final_new2, and nobody knows which one applies.

The obvious answer is order. Many owners, however, associate document control with forms, signature routes, and the manual maintained for an audit. That leads to the guiding question of this article: which documents does a small company need to control, and how can it do so without creating bureaucracy? To answer it, we first clarify the terms and an important distinction, then present the life cycle of a controlled document as a thinking model, look at the findings, weigh two perspectives, and finally describe a one-page register.

A document with two valid versions in truth has none.

What is document control, and what needs to be controlled?

Document control refers to the rules by which a company defines which version of a document applies, who reviews and approves it, where it is accessible to everyone, how changes become traceable, and how outdated versions are taken out of circulation. The term comes from quality management. The ISO 9001 standard today speaks of documented information. As the article on quality management without certification bureaucracy describes, it requires documented information to the extent a company needs for its processes to be effective, and no manual.

In practice, one distinction matters more than any regulation. There are two kinds of documents. Specifications define how work should be done: process pages, work instructions, checklists, templates, price lists, inspection plans. Records capture what was actually done: completed inspection reports, delivery notes, acceptance protocols, training records. The standard separates the two in its wording by speaking of maintaining specifications and retaining records.

This leads to the principle of this article. Control in the narrower sense applies to specifications, because an error in a specification multiplies with every order. Records need no approval and no version number, but a fixed storage location and protection against later changes.

The thinking model: the life cycle of a controlled document

Every specification passes through the same stations, whether it is on paper or in software. Here the model is called the life cycle of a controlled document. It shows where errors arise. Most problems are not in creating the document, but at stations four and five: changes are not incorporated, and old versions remain in circulation.

1. Create

   The person who knows the process best writes the specification. It carries a title, owner, version, and date.

2. Review and approve

   A second person reviews the content and approves it. In small companies a note with name and date is enough.

3. Make available

   The specification is in exactly one place that everyone knows. Where printing is necessary, the printout carries version and date.

4. Change

   Changes go to the owner. They incorporate them, increase the version number, and note in one sentence what has changed.

5. Withdraw

   The old version is moved to the archive, printouts are collected. Only then is the new version considered introduced.

An everyday analogy shows why the last station matters. A train timetable is only useful if the current one is posted on the platform. A new timetable that is printed but hung next to the old one makes the situation worse than before, because travelers now see two contradictory pieces of information. The same happens in a company when a new checklist is put on the shared drive but the old one stays in the folder next to it.

What studies show about documents and errors

How much document control actually contributes to results was examined by Villegas Pérez, Navas González, Serrano, and colleagues (2024) in a strictly regulated setting. They evaluated the official audits of 18 laboratories in the Spanish provinces of Córdoba and Seville over six years. The laboratories test meat for Trichinella and work under a quality management system based on the laboratory standard ISO 17025. Each deviation was classified by type and content and related to the laboratory's risk level.

The result is revealing. Deviations in carrying out the test, such as incorrectly performed tests or technical specifications not followed, clearly increased the risk. Deviations in records and forms, meaning incomplete forms or missing and illegible data, had no significant overall influence. At the same time, the detailed analysis showed that laboratories without findings on technical instructions and on document control had markedly lower risk levels. Controlled specifications therefore mattered, the completeness of individual forms hardly at all. The authors look at very specific laboratory work. What transfers is the pattern, not the number.

A second study shows that a controlled specification alone is not enough. Jerry, Cranmer, Gopalan, and colleagues (2026) checked in an acute hospital whether ultrasound probes were disinfected according to the applicable work instructions. After a bundle of training, equipment, and feedback, compliance improved in all six areas that took part. In the one area whose staff did not attend the training, it declined. The authors conclude that an available work instruction and suitable equipment are not sufficient on their own.

The third number comes from research on shared filing, described in detail in the article on digital filing. In folders created by others, search failed in 28 percent of cases, in self-created folders in 5 percent (Bergman, Israeli, and Whittaker 2020). For document control this means: one valid version only helps if its location is also predictable.

Control everything or only what is necessary? Two perspectives

There are two readings of how strictly a company should control its documents. The first focuses on completeness: every document gets a number, every change an approval, every distribution a list. In its favor: nothing slips through and every version is traceable. In industries with liability risks or customer audits, this is partly also required.

The second focuses on effect: what is controlled is whatever steers other people's work, and as simply as possible. The laboratory findings speak for this. Where the specification is right and followed, risk falls, while the completeness of individual forms changes little. Added to this is an argument from the article on writing work instructions: specifications that are tedious to change soon no longer describe the actual work and are bypassed.

For small companies I consider the second reading the right one, with one exception. Where a customer, an authority, or a certification body requires certain records, their rules apply. Everything else gains from simplicity. Document control that makes changes harder does not protect the right version, but the old one.

The one-page document register

The tool of this article is a document register: a table in which each controlled specification has exactly one row. It replaces distribution lists and manuals. In a company with 15 employees it usually has 30 to 60 rows.

• One row per specification: whatever is not in the register does not count as a specification.
• One owner: each specification has a responsible person who incorporates and approves changes.
• Version and date in the document: both also appear on the document itself, for example in the footer, so a printout remains recognizable.
• One place: the valid version is kept only there. Older versions go to the archive.
• Review date: each specification is reviewed after twelve months at the latest, or immediately when the process changes.
• Change within one week: whoever reports an error receives a revised version or a reason within one week.

These rules correspond to those the article on templates in the company describes for templates: one place, one owner, one version number, annual review. The register brings them together for all specifications. How process pages themselves are structured is described by the one-page method.

What follows in general

Document control is essentially a question of responsibility, not of filing. As long as nobody is responsible for a specification, nobody changes it, and as long as nobody changes it, the work drifts away from it. A register with owners makes this responsibility visible. That is also why it achieves more than a better shared drive.

The limits lie where specifications are not read at all. As the hospital study shows, a good specification needs instruction and feedback. And a controlled checklist only protects if it is used at a fixed checkpoint, as the article on checklists in the company describes.

Conclusion: which documents does a small company need to control?

The guiding question was which documents a small company needs to control and how this can be done without bureaucracy. The answer starts with a distinction. What is controlled are specifications that others work by: process pages, instructions, checklists, templates, and price lists. Records are filed completely and securely, but need no approval and no version. For the specifications, a one-page register with owner, version, location, and review date is enough.

As shown, the findings suggest that controlled specifications reduce errors while the completeness of individual forms changes little, and that a specification without instruction achieves little. This leads to a sober rule: control as little as possible, but control that consistently, and always take old versions out of circulation.

What you can do this week

1. List all specifications that work in your company is based on and enter them in a register.
2. Give each specification an owner, a version number, and a date.
3. Set a single location for each specification and move older versions to the archive.
4. Collect all printouts without a current version.
5. Agree that reported errors in a specification are dealt with within one week.

After a month you will see whether the register is alive: it should contain at least one changed version. A register without changes is not being used.