How a document control process actually runs
A process is a set of decisions, not a folder structure
Most first attempts at document control start by designing a folder tree and a naming convention. Both are useful and neither is the process. The process is the set of decisions a document passes through, who is allowed to make each one, and what each decision leaves behind as evidence.
The test is simple: if you can describe your document control by drawing a directory, you have described storage. If you have to name people and decisions, you are describing control.
The roles, and why separating them is the whole point
Author — writes the content and knows the work. Usually the person who requested the revision, and often the worst possible person to approve it, because they are too close to it to see what it fails to say.
Reviewer — checks that the content is correct and workable. There is normally more than one, drawn from the functions the procedure touches, and their job is technical rather than procedural.
Approver — accepts the document on behalf of the organization. This is an authorization, not an opinion, and it is the reason review and approval must not be the same permission. An organization where one person routinely does both has a review step in name only.
Document control — owns the register, the numbering, the states and the process itself. In a small organization this is somebody’s second job; it still needs to be somebody’s.
The sequence, and what each step has to leave behind
Draft. A revision creates a new version rather than editing the current one. What it leaves behind is the reason for the change, recorded at the time rather than reconstructed later from a diff.
Review. Assigned to named people as work, not circulated as an attachment. What it leaves behind is who reviewed what, and whether they asked for changes.
Approve. A separate, separately authorized decision. What it leaves behind is who accepted the document and when.
Sign. Where a signature is required, it attaches to the exact version and its content, not to the document in general. What it leaves behind is the signer, the meaning of the signature, and what they were looking at.
Effective. One version comes into force and the previous one is superseded rather than deleted. What it leaves behind is the pair of dates that lets you answer which version applied on any given day.
Retire. A document that is withdrawn rather than replaced is a different event from a supersession, and it needs a reason. What it leaves behind is that reason, and the document itself — retirement is not deletion.
Three things that sink a first rollout
Migrating the back catalogue first. The instinct is to get everything in before going live. The effect is months of unpaid archaeology on documents nobody is using, while the ones people follow every day stay on the shared drive. Start with the documents currently in force, and let the rest arrive as they are revised.
Numbering that encodes meaning. A number that contains the department, the year and the document type is a number that becomes wrong when the department is reorganized. A document number’s only job is to be permanent and unique.
Approving everything at the top. Routing every document to the same senior approver produces a queue, and a queue produces rubber-stamping, which is worse than no approval step because it manufactures evidence of a decision nobody made.
What to settle before the first document goes in
Which document types you have, and who owns each one. Types drive almost everything downstream — who reviews, who approves, how long between reviews — so a type list invented later is a migration.
What "effective" means to you. For some organizations a document is in force the moment it is approved; for others there is a gap while people are told. Decide which, because it changes what your records mean.
Who is allowed to approve, in writing, before anyone needs to. Working this out during an audit is how organizations discover that their approval authority was an assumption.