A Document Control Procedure for Small Manufacturers (No Software Required)
A no-software document control procedure for small manufacturers: a shared folder, a naming convention, a sign-off rule, and a revision log that still holds up in an audit.
Here is the failure that document control exists to prevent: an operator is running Rev 1 of a work instruction while Rev 3 sits on the server. The change you made three months ago, the one that was supposed to stop the burr complaint, never reached the floor. The operator is doing exactly what is taped next to the machine. The taped copy is wrong. Nobody is being careless. The system just never made sure the current version was the one in their hands.
That is the whole problem. Document control is not a filing hobby. It is the discipline of making sure the version someone is working from is the version you actually approved, and that old versions are gone from the point of use. Everything else is paperwork around that one idea.
Most advice on “document control procedure” assumes you are a 2,000-person company buying a quality management system, with talk of controlled repositories, electronic signatures, and document lifecycle modules. If you have 40 people and no QMS software, that advice makes you feel like you need to spend money before you are allowed to control your own documents. You do not. A shared folder, a naming convention, a one-line revision history, and a sign-off rule will hold up in front of an auditor, and it will keep the wrong rev off the floor. Here is how I build it.
What document control actually has to do
Strip away the enterprise framing and a document control system has four jobs. If yours does these four things, it works. If it skips one, that is where it will bite you.
- Tell you which version is current. Anyone should be able to look at a document and know it is the latest approved one, without asking around.
- Show who approved the change and when. A document that changed itself is not controlled. Someone owns each revision.
- Get the current version to the point of use, and pull the old one. This is the job everyone skips. A perfect rev on the server does nothing if the laminated old one is still at the station.
- Keep a history of what changed. So that six months from now you can answer “when did we change the torque spec, and why” without guessing.
None of those four require software. They require a convention everyone follows and one person who owns the process. Let me give you the convention.
A naming and version scheme you can run from a folder
Pick a scheme and use it without exception. The exception is what kills you, because the moment one document is named differently, your “current version” rule breaks. Here is the one I use.
Every controlled document gets three things in its name: a document ID, a revision letter, and the effective date.
DOC-ID _ Rev letter _ YYYY-MM-DD _ Title
WI-014_RevC_2026-06-11_Line3-Torque-SettingA few rules that make this hold up:
- Document ID is permanent. WI-014 is WI-014 forever. Revisions change, the ID does not. Use a short type prefix so the ID tells you the document kind: SOP for procedures, WI for work instructions, FORM for forms, POL for policy.
- Revision is a letter, not a number, for released documents. Rev A, Rev B, Rev C. Letters read cleanly and do not get confused with version numbers inside the document. For in-progress drafts, use the next letter with a draft tag (RevD-DRAFT) until it is signed, then drop the tag.
- The date is the effective date, the day the revision goes live on the floor, not the day you typed it. That date is what an auditor cross-checks against your revision log.
- One current file per document, period. When Rev C goes effective, Rev B does not stay in the live folder. It moves to archive. There is exactly one WI-014 in the live folder at any time, and it is the current rev.
That last rule is the one that does the heavy lifting. If your live folder only ever contains current revisions, then “grab the file from the live folder” is the same as “grab the current version.” You have designed the mistake out instead of relying on people to check.
If you are building the documents these control, the SOP from-scratch walkthrough and the work instruction template operators will follow cover the document side. This post is about controlling them once they exist.
Where to store it
A shared network folder or a shared drive folder is fine. The structure matters more than the platform:
- A Live (or Released) folder, organized by document type or by area. This is the single source of truth. Only current revisions live here.
- An Archive folder for superseded revisions. You keep old revs, you just keep them out of the live folder so nobody can accidentally pull one.
- A Drafts folder for in-progress changes that have not been signed off. Nothing here is allowed at a point of use.
Set the live and archive folders to read-only for the floor and editable only by the document owner. That single permission setting prevents the most common uncontrolled change: a well-meaning person editing the live file directly. If only the owner can write to Live, every change goes through the owner, which is exactly the control you want. No software module required, just folder permissions you already have.
Who approves a change, and how you record it
A change is controlled when a named person with the authority to approve it signs off before it goes effective. Keep this simple or people will route around it.
For a small shop, one approver per document type is usually right. Work instructions get approved by the area supervisor or lead. Cross-department procedures get approved by the quality manager or plant manager. Anything tied to a customer spec or a safety requirement gets a second sign-off from quality. Write down who approves what, once, so there is no debate in the moment.
How you record the sign-off depends on whether you are paper or digital, and both are valid:
- Paper: a printed sign-off line on the document or a change form, wet-signed and dated, scanned into the file. A signature on paper is still a perfectly good control.
- Digital: an approval recorded in the revision log with the approver’s name and date, where only the owner can edit the log.
You do not need certified electronic signatures. You need a record that ties a specific person to a specific revision on a specific date, and proof the floor never saw a revision that had not cleared that step.
Getting the current rev to the floor and pulling the old one
This is the step that separates a real document control procedure from a folder full of good intentions. Approval is not the finish line. The finish line is the current version in the operator’s hands and the old version in the trash.
When a revision goes effective:
- Replace every printed copy at the point of use the same day. Walk the floor. Pull the old laminated sheet off the wall, off the machine, out of the binder. A controlled document and a stale printout at the station cannot both be true, and the operator follows whatever is physically in front of them.
- Control your printouts. Treat any printed copy as uncontrolled the moment it leaves the printer unless you mark it. A small footer like “Verify current rev before use, see Live folder” tells anyone holding paper that the server is the authority. The printed copy is a convenience, not the source of truth.
- Retrain when the work changed. If the revision changes what the operator actually does, a sign-off that they were trained to the new rev closes the loop and ties the person to the rev.
If you do nothing else from this post, do this one. Rev 3 on the server with Rev 1 at the station is the single most common document control failure I see, and it is entirely a point-of-use problem, not a filing problem.
A one-line revision history on every document
Every controlled document carries its own short history block, near the header, so the document tells its own story without you opening a separate log. One line per revision:
| Rev | Effective date | Change summary | Approved by |
|---|---|---|---|
| A | 2026-01-15 | Initial release | M. Reyes |
| B | 2026-04-02 | Added deburr step after milling | M. Reyes |
| C | 2026-06-11 | Updated torque spec to 18 Nm per customer change | T. Okafor |
Keep the change summary to one honest line. “Updated torque spec to 18 Nm per customer change” is worth more than “various edits.” When something goes wrong eight months from now, this block answers what changed and when, on the document itself.
The artifact: a master document register
The one central thing worth maintaining is a document register, sometimes called a master document list. It is a single spreadsheet that tells you, at a glance, every controlled document, its current rev, and whether it is current. This is what you hand an auditor first, and it is what tells you which documents are overdue for review. Here is a layout that does the job:
| Doc ID | Title | Type | Current rev | Effective date | Owner | Approver | Next review | Status |
|---|---|---|---|---|---|---|---|---|
| WI-014 | Line 3 torque setting | Work instruction | C | 2026-06-11 | T. Okafor | Quality | 2027-06-11 | Active |
| SOP-006 | Incoming inspection | Procedure | B | 2026-04-02 | M. Reyes | Plant mgr | 2027-04-02 | Active |
| FORM-003 | Changeover checklist | Form | A | 2026-01-15 | M. Reyes | Supervisor | 2027-01-15 | Active |
Sort it by Doc ID. The “Next review” column is what keeps documents from quietly rotting: when the date comes up, the owner confirms the document is still right or revises it. The “Status” column lets you retire documents cleanly (Active, Under revision, Retired) instead of deleting them and losing the history. This register plus the per-document revision block is your entire control system. Two artifacts, no platform.
Put it together
A document control procedure that holds up does five things: one permanent ID per document, a revision letter and effective date in the name, a named approver who signs off before a change goes live, the current rev put at the point of use with the old one pulled, and a one-line history on the document backed by a master register. That is a real system. It runs out of a shared folder and a spreadsheet, and it does not require buying software to be in control of your own documents.
A clean system like this helps you walk an auditor through your documents without scrambling, and more to the point, it keeps the right rev in the operator’s hands day to day. It does not on its own guarantee any particular audit result, no system does that, but it removes the failure mode that causes most of the pain.
This is part of how I think about building systems that do not collapse the first time the person who knew everything goes on vacation, which is the throughline of my Systems work. I keep a free document register and revision log template, laid out with the columns above and a per-document history block, so you are filling in your documents instead of designing the layout from a blank page. You can grab it along with the field notes list at the bottom of this page. If you want the longer treatment, that is what my books on manufacturing systems are for, and you can find those over on the books page.
Start with the register. Once you can see every document and its current rev on one page, you already control more than most shops your size.
Related notes
Liked this? Get the free SOP Writing Cheat Sheet.
The 6-step SOP format on one page. Free.