90 Day Policy Version Control Template for Compliance Teams

Policy version control in one sentence

Policy version control means you can show, for any date, which version of a policy was in force, who approved it, what changed, and which employees acknowledged that exact version. Get two things right first: one source of truth for every policy, and acknowledgements tied to a version number. Numbering schemes matter far less than most teams think.

This post gives you the fields a controlled policy needs, a change process you can run with three people, a sample version table, and a 90-day plan to get from scattered Word files to something an auditor will accept.

Why auditors ask for the chain, not the document

An auditor rarely asks “show me the policy”. They ask “show me the policy that applied on 14 March, who signed it off, and proof your warehouse team read it.” The IRS’s internal change management policy (IRM 2.125.1) is a good model of that thinking, even for a business with no tax angle. It says approved changes “shall result in updates to configuration baselines and associated configuration records, including version control.”

Without that chain, things go wrong in predictable ways:

• A shift supervisor follows last year’s lockout procedure because the old PDF is still pinned in the team channel.
• HR and Operations quote different versions of the same leave policy in an employment dispute.
• You can’t prove which version applied on the date of an incident.
• Your acknowledgement records say “Code of Conduct” with no version number, so they prove nothing about the current rules.

Five things every controlled policy needs

A date in the footer doesn’t make a policy controlled. It needs a small set of fields that make its history readable by someone who wasn’t there when it was written.

Start with numbering, and keep it boring. The University of Aberdeen’s version control guidance uses a pattern most teams can adopt as is: drafts run 0.1, 0.2, 0.3; the first approved release is 1.0; minor fixes like spelling corrections become 1.1 and 1.2; and changes that need re-approval jump to 2.0.

Watch the difference between approval date and effective date. The effective date decides when the new rules apply, and if you give staff 30 days’ notice of a change, the two will be a month apart.

Then add these to every policy:

1. A version control table on the front page. Aberdeen’s guidance puts it there too, with version, author, date and changes as the core columns. We’d add status, approver, effective date and the version it supersedes.
2. A plain-language change summary. Two or three sentences on what changed and why. Nobody reads a 12-page redline.
3. File names that match the header. If the file is called Remote_Work_Policy_v2.1.pdf, the front page should say 2.1 as well.
4. A status flag. The moment 2.1 is approved, 2.0 becomes read-only and is marked superseded.
5. A retention rule. Write down how long superseded versions stay available, and match it to the longest lookback your regulators or insurers use.

Never delete a superseded version. Archive it with a reference number. If you’re ever asked what your harassment policy said in 2023, the answer should take two minutes, not a week of digging through old email.

Sample version control table

Here’s what the front page of a remote work policy might look like after a year of changes. The dates and names are made up.

Keep this table in step with whatever your repository records automatically. Decide in writing whether you keep drafts once a version is approved. Some audit scopes want proof of the review, others don’t care. Either is fine, as long as it isn’t decided by whoever happens to be tidying folders that week.

Run every change through the same six steps

Small changes are where conflicting versions sneak in, so every change takes the same route, however minor it looks. Here’s the sequence:

1. Someone flags a needed change: a new regulation, an incident, a gap found in an internal review.
2. The policy owner works out who it affects and which training or forms need updating.
3. A reviewer who didn’t draft the change checks it for errors and clashes with other policies.
4. Someone with real authority approves it. Ideally not the author.
5. The new version goes live in the single source of truth, and the old one is marked superseded.
6. Someone tracks acknowledgements from the people affected until they’re all in.

That split between drafter, reviewer and approver is the bit most teams skip. The IRS policy is blunt about it: “No individual shall have end-to-end control” of a change, and closure “shall be performed by an authorized role independent of implementation where practicable.” For policies, that means someone other than the author confirms the new version is live and the old copies are gone.

Ask for re-acknowledgement whenever a change affects what employees must do. A typo fix doesn’t need it. If the acknowledgement rate on a new version is still low two weeks after publication, look at how you’re notifying people before you look at the policy.

Emergency changes can skip the full review, but not the follow-up. The same IRS policy says emergency changes “shall not be closed until PIR activities are completed”, PIR being a post-implementation review. Set a window, say 10 working days, to review any emergency edit properly.

Pick tools by how many policies you manage

For a team managing 20 policies, a well-run shared drive can work. At 200 policies across three countries, it won’t. Whatever you use has to do the same jobs: one controlled location, a version history, and permissions that stop people editing retired copies.

Structured file shares are the cheapest option and the easiest to get wrong. They work if the folder structure and naming rules are strict and people actually follow them.

Document management systems add automatic version history. They timestamp each save, log who changed what, and let you roll back without hunting through attachments. That starts to matter once more than two or three people touch the same policy library.

Dedicated policy software goes further, with approval workflows and attestation tracking built around proving who acknowledged which version.

Whichever you choose, check for these:

• Single sign-on, so the access log points to a real person and not a shared login.
• Audit logs you can export in a format your auditor will accept.
• Retention settings that match your legal hold and archive rules.

Co-editing in Teams or Google Docs speeds up drafting, and that’s useful. But a live document isn’t a controlled version. Keep a formal approval step between “we’ve finished editing” and “this is policy”.

The real risk is the acknowledgement gap

The time between “we published version 2.0” and “everyone has acknowledged 2.0” is where most of your exposure sits. If someone breaks the rule in that window, you’ll struggle to show they knew it.

Treat acknowledgements like any other deadline. When a version is published, every affected person gets a task with a due date. Reminders go out on a schedule. After, say, 14 days, anything outstanding escalates to that person’s manager. At the end you can export a report showing who acknowledged which version and when.

This matters most in a few situations:

• Annual re-attestations on a fixed compliance calendar, like a yearly code of conduct sign-off.
• Policies tied to a certification, where a missing acknowledgement can look a lot like a lapsed credential to an auditor.
• Rollouts across departments, where HR, legal and operations each need proof of sign-off on the same document.

If you track acknowledgements in a spreadsheet, you know the pattern. Nobody chases the stragglers until the audit is two weeks away. ExpiryEdge treats each acknowledgement as a dated item: it reminds the employee by email, SMS, WhatsApp, Slack or Teams, escalates overdue ones to their manager, collects the signed document, and keeps an audit trail you can export.

A 90-day rollout plan

Ninety days is enough to go from scattered documents to a working system, as long as you go in order.

1. Weeks 1 and 2: list every policy, note where each copy lives, and choose the single source of truth.
2. Weeks 3 and 4: agree the numbering convention and add a version table to your riskiest policies first.
3. Weeks 5 to 8: set up the repository and the approval route. Name who reviews, who approves and who closes each change.
4. Weeks 9 to 11: pilot on two or three policies and collect real acknowledgement data.
5. Weeks 12 and 13: check your numbers (acknowledgement rate, open drafts, average days to close a change) and adjust before rolling out everywhere.

Keep watching those numbers after the pilot. A falling acknowledgement rate is the first sign the process is slipping.

Fix acknowledgements before numbering

Most advice on this topic argues about decimals versus whole numbers. That’s the wrong fight. A policy with perfect version numbers still fails an audit if nobody can prove who agreed to the current rules. You can fix a numbering scheme in an afternoon. You can’t rebuild six months of missing sign-offs.

If you’re starting from nothing, don’t try to fix every policy at once. Pick the three or four with the highest regulatory exposure, often health and safety, data protection and anti-bribery. Build the version table and acknowledgement routine for those, then copy what works. For the evidence side, our guide to audit trail requirements covers what a usable log should record.

Sources

• IRM 2.125.1, Change Management Policy, Internal Revenue Service
• Version Control guidance, University of Aberdeen (2017)

Related reading

• Benefits of Automated Compliance Tracking for Teams
• How to Set Up a Property Compliance Calendar That Works
• How Supplier Compliance Tracking Works for Procurement Teams
• Contract renewals 90 to 180 days out: stop missed deadlines for legal and ops

Frequently asked questions

What is a version control policy?

A version control policy is your written rulebook for changing controlled documents. It says how drafts and approved versions are numbered, who must review and approve a change, where the current version lives, and how long superseded versions are kept. The aim is that anyone can trace a change back to its author, its approver and its effective date.

How do you do version control on a document?

Give each revision a number and an effective date. Record the author and approver, and write a two-sentence summary of the change in a table on the front page. Store the file in one place, mark the current version clearly, and archive the old ones instead of deleting them. Then ask affected staff to acknowledge the new number.

What is the best software for document version control?

There isn’t one best tool; it depends on scale. With 20 policies, a shared drive and strict file names can work fine. Once you’re regulated, or past a few hundred documents, you’ll want a document management system that keeps version history for you, or policy software that tracks who signed what. Insist on single sign-on and audit logs you can export.

What is a document control policy?

A document control policy covers the whole life of your controlled documents: how they’re created, reviewed, approved, distributed, revised and finally retired. Version control is one part of it. The goal is simple. Only the current approved version is in use, and you can prove what was in force on any past date.

Why do acknowledgement gaps matter for audits?

Auditors want proof that staff acknowledged the current version of a policy, not an older one. If weeks pass between publishing a new version and people signing it, that gap looks like a control weakness, even when the policy itself is fine. It also weakens your position if someone breaks the new rule during that window.

Can employees e-sign a policy acknowledgement?

In most cases, yes. In the US, the federal ESIGN Act and state UETA laws give electronic signatures legal effect, and the EU’s eIDAS regulation does the same in Europe. Tie the signature to the policy’s version number and date, so an auditor can see exactly which rules each person accepted. Check local rules for anything unusual.