Document Control: A Practical Guide for Policies and SOPs

Someone on your team is following a procedure right now. Is it the one you approved last month, or a copy they saved to their desktop a year ago? If you can't answer quickly, you have a document control problem.
This guide explains what document control is, the six controls every policy and SOP needs, and how to set up a simple document control procedure your team will actually use. You don't need a quality department or special training to do it.
What is document control?
Document control is the set of rules that makes sure people use only the current, approved version of a document. Each controlled document has a unique ID and a version number. Someone approves it before release, and it has a clear effective date. Every change is recorded, and old versions are taken out of use.
Policies, standard operating procedures (SOPs), work instructions, and forms are the usual candidates. They tell people what to do, so a wrong or outdated version leads straight to wrong work.
Regulated industries have formalized this for years. The European Union's good manufacturing practice (GMP) guidance for medicines is one example. It says documents containing instructions should be approved, signed, and dated by authorized people. It also says they should have unambiguous contents, be uniquely identifiable, and have a defined effective date. You don't have to make medicines for those rules to be useful. They describe what any team needs to trust its procedures.
Which documents need to be controlled?
Not everything does. A good rule of thumb: control any document that tells people how to do their job, or that someone will check them against.
- Control: policies, SOPs, work instructions, checklists, forms, and templates people fill in
- Usually skip: meeting notes, drafts, brainstorms, and one-off emails
Also separate documents from records. The EU GMP guidance draws the same line between instructions (what to do) and records (evidence of what was done). A procedure is a document you keep current. A completed checklist is a record you keep as it is. You update procedures with new versions. You don't rewrite records, and any correction to one should leave the original entry readable.
The six controls every policy and SOP needs
These six controls are the core of document control best practices. If you get them in place, most of the work is done.
1. A unique document ID
Give every controlled document an ID that never changes, even when the title does. A simple pattern works: a department code, a document type, and a number, such as HR-POL-004 or OPS-SOP-112.
The same thinking applies to file names. The US National Archives recommends naming conventions that are descriptive, consistent, and meaningful. It also says each part of a name, such as a date or version, should always sit in the same position. It suggests using only letters, numbers, hyphens, and underscores, with no spaces.
2. A clear version number
Document version control answers one question: which one is this? A common document control numbering scheme looks like this:
- 0.1, 0.2, 0.3… for drafts under review
- 1.0 for the first approved release
- 1.1 for a minor approved change (wording, a fixed link)
- 2.0 for a major change (new steps, new responsibilities)
Whatever scheme you pick, write it down once and use it everywhere. Two teams using two schemes is how "final_v2_FINAL.docx" happens.
3. Approval before release
A controlled document goes live only after the right person signs off. Decide who that is for each document type. Your HR lead might approve HR policies, while a site manager approves safety SOPs. Keep a record of who approved what, and when.
For high-risk procedures, use more than one approver. You can ask them in sequence (legal, then operations) or in parallel (several reviewers at once).
4. An effective date
The approval date and the effective date are not always the same. A new policy might be approved on the 1st and take effect on the 15th, after training. Show the effective date on the document so nobody has to guess which rules apply today.
5. A record of every change
Document change control means every revision has a reason and an owner. The EU GMP guidance says a change should be signed and dated, the original information should stay readable, and the reason should be recorded where appropriate.
In practice, that means a short change log at the top or bottom of each document:
| Version | Effective date | Change | Approved by |
|---|---|---|---|
| 1.0 | Mar 3 | First release | Operations lead |
| 1.1 | Jun 10 | Updated escalation contact | Operations lead |
| 2.0 | Sep 1 | Added remote-site steps | Operations lead, Legal |
6. Retire superseded versions
When a new version takes effect, the old one must stop being used. This step fails most often, because copies spread through email attachments, shared drives, and printouts taped to the wall.
Archive superseded versions where auditors can find them, but out of reach of everyday users. Mark any printed copy as uncontrolled, so people know to check the live version.

Keep a master list of controlled documents
You can't control what you can't see. Keep one master list of every controlled document with its ID, title, current version, owner, effective date, and next review date. The EU GMP guidance asks for exactly this: an inventory of documents within the quality system.
The master list also shows you which documents are overdue for review. For setting review dates, see our guide on how often to review your policies and procedures.
Document control vs. document management
The two terms are often mixed up, but they answer different questions.
- Document management is about storing and finding files: folders, search, permissions, and backups.
- Document control is about trust: is this the approved version, who approved it, when did it take effect, and what changed?
A shared drive gives you document management. It doesn't, on its own, tell anyone which file is in force. You need both, and document control is the part that protects your team in an audit or an incident.
Modern guidance reflects this shift to digital. The ISO technical committee for quality management notes that ISO 10013:2021, its guidance on documented information, recognizes the move to digital documents. The guidance no longer prescribes a fixed document hierarchy. Your structure can fit how your team actually works, as long as the controls are in place.
How to write a document control procedure
Your document control procedure should be short. One or two pages is plenty. Cover these points:
- Scope: which document types are controlled.
- IDs and naming: your ID pattern and file-naming rule.
- Versioning: your numbering scheme for drafts and releases.
- Roles: who writes, who reviews, and who approves each document type.
- Release: how a document is published and how people are told.
- Changes: how to request a change and what goes in the change log.
- Retirement: what happens to superseded versions and printed copies.
- Review: how often each document type is checked. Our documentation governance framework can help here.
Treat this procedure as a controlled document too, with its own ID, version, and approver.
Make the approved version the only one people see
The simplest document control system is one where people can't find the wrong version. That means one published home for every policy and procedure, with drafts kept separate from what's live.
This is how Sonat works. Authors can draft in Google Docs or the built-in editor. Each change goes through your approval workflow, with sequential or parallel approvers. Only the approved version is published to readers. Every earlier version stays in the archive, so you can see what changed or restore it. Readers get one link, and it always shows the version in force.
Start with your ten most-used procedures
You don't need to control everything on day one. Pick the ten policies and SOPs your team uses most. Give each one an ID, a version, an owner, and an approver, then publish them in one place. Once those are under control, add the next ten.
Good document control means your team never has to wonder whether they have the right version.