Policy Version Control: Moving Your Library Off the Shared Drive
If your current handbook is called Handbook_v3_FINAL_revised.docx, you don’t have version control yet. Here is how to set it up: one master location, clear version rules, defined roles, and a clean migration.
In short
Policy version control means every policy has one master copy, each approved change becomes a new numbered version, and older versions are kept but clearly marked as no longer in force. To move off a shared drive, pick a single system of record, agree what counts as a new version, separate who edits from who publishes, migrate one confirmed current copy per policy, and freeze the old folders read-only.
This guide covers the setup and migration. For what each version record should contain, see policy version control in PolicyTrak and what to include in a policy change log.
Why file names stop working
Naming conventions work while one careful person owns every file. They break the first time two people save a copy, someone emails an attachment, or a folder gets reorganised.
Copies multiply
Every download, attachment and “save as” creates another candidate for the current version.
“FINAL” means nothing
A file name records what someone hoped at the time of saving. It does not record whether the document was approved, by whom, or when it took effect.
History is lost on overwrite
When someone edits the file in place, the previous wording is gone unless a backup happens to exist. You cannot show what the policy said last spring.
Old versions keep circulating
Superseded copies sit in team folders, intranet pages and inboxes. Staff follow whichever one they find first.
Set the rules before you move anything
Agree these first, in a one-page procedure approved like any other policy.
Rule 1
One master location
Choose a single system of record for policies. Intranet pages and binders link to it; any other copy is a reference, not the policy.
Rule 2
Material change vs correction
A material change alters what someone must do, may do, or will be held to. That needs approval and a new published version. A correction fixes a typo, broken link or formatting without changing meaning; record it, but it need not go back through full approval.
Rule 3
A simple numbering convention
Use whole numbers for material changes (2.0, 3.0) and a decimal for corrections (2.1, 2.2). Show the number and effective date in the document header so anyone holding a printout can check it against the master.
Rule 4
Edit is not publish
Policy owners and drafters can edit. Only named approvers can publish a version as in force. Keep the lists short and separate so a draft never goes live just because someone saved it.
Write the rules down once. When people disagree later about whether a change was “just a tweak”, the written definition of a material change settles it. If in doubt, treat it as material.
What to do with superseded copies
When a new version takes effect, the old one should stop being used but should not disappear. You may need to show what the policy said on a given date, for an investigation, a claim or an audit. How long to keep superseded versions depends on the policy’s subject and the rules that apply to you; ask counsel.
Three habits keep old versions from causing trouble:
- Mark, don’t delete. Keep the old version on record, labelled superseded, with the date it stopped applying and the version that replaced it.
- Remove it from circulation. Take it down from intranet pages, shared folders and onboarding packs. Replace links with a link to the master.
- Tell the people affected. Send the new version to the staff it applies to and record that they received and acknowledged it.
Migrating an existing library
Treat the migration as a one-off project with a fixed end. If your library has grown out of control, run a policy sprawl consolidation first or alongside, so you are not carefully migrating policies that should be retired.
- 1
Inventory every policy
List each policy once, with its owner and every place a copy lives: shared drives, intranet, email attachments, binders.
- 2
Pick the current copy for each policy
Where several copies exist, the owner confirms which one is actually in force. If nobody can confirm it, treat that policy as needing review and approval before it goes live in the new system.
- 3
Record its approval date
Note who approved the current copy and when, from minutes, emails or sign-off sheets. If no evidence exists, say so rather than guessing a date.
- 4
Load it as version 1
Bring the confirmed copy into the new system as its first version, with the original approval date noted. Don’t recreate the history of old drafts; keep the old files as an archive.
- 5
Freeze the old folder read-only
Once a policy is live in the master location, make the old folder read-only and add a note pointing to the new home.
How PolicyTrak supports the setup
In PolicyTrak, every save creates a numbered version with the author’s name and date and time, and nothing is overwritten. An audit log, kept separately from the version history, records each change to content, delivery method or status with a timestamp. PolicyTrak numbers saves automatically, so use the change log to record your own published version numbers and whether a change was material or a correction.
For the migration itself, PDF import with AI extraction can help bring existing documents in. The extracted draft still needs a person to check it against the confirmed current copy before approval.
Version control
Numbered versions with author and timestamp. Open any earlier version in full, compare two side by side, and roll back if needed; the rolled-back version stays on record.
Approval workflows
Custom approval chains by category, department or sensitivity, with status tracking and approver reminders. Status changes are captured in the audit log.
Policy management
Draft from Smart Templates or AI generation, import existing PDFs with AI extraction, then route, publish and distribute from one place. Drafts still need human review.
Note“Superseded” here describes general practice for labelling old versions. Check how status labels are set up in your own PolicyTrak account.
Give Every Policy One Master Copy
Numbered versions, side-by-side comparison, approval chains and an audit log in one place. Sign up and see plans without booking a call.
A checklist for the first 90 days
- 1
Days 1–30: rules and high-risk policies
Approve the version control procedure, name editors and approvers, and migrate the policies with the most legal or safety exposure first.
- 2
Days 31–60: the rest of the library
Migrate the remaining policies, freeze each old folder as you go, and replace intranet copies with links to the master.
- 3
Days 61–90: test and tidy
Pick a few policies and check you can show the current version, who approved it and when. Search shared drives for stray copies and remove them from circulation.
