Policies
Policy management software with acknowledgement tracking
Policy management software proves that the right people read the right version. DocumentMS holds one controlled library, supersedes old versions without losing them, schedules the next review before the current one lapses, and records acknowledgement per named user with a timestamp you can export.
What goes wrong without controlled policies
Policy management fails in a specific, testable way: an auditor asks which version of a policy was in force on a given date and who had read it. Most organisations can answer the first question with some digging and cannot answer the second at all, because "the policy was circulated by email" is not evidence that anyone read it.
The underlying issue is that a policy has two lifecycles and most systems only handle one. The document has a version history — drafted, reviewed, approved, superseded. The obligation has a separate one — published, acknowledged, re-acknowledged when it changes, evidenced on demand. A shared folder handles neither, and an intranet page handles the first badly and the second not at all.
The third failure is silent lapse. A policy with a two-year review cycle passes its review date and remains in force, unreviewed. Nothing breaks, no one notices, and the finding arrives at the next audit — by which time several policies are overdue and the remediation is a project rather than a task.
The symptoms you will recognise
- Policies distributed by email attachment, with no record of who opened them
- Two versions of a policy in circulation, both looking current
- Review dates that have passed with the policy still in force
- No way to produce, per named employee, which version they acknowledged and when
- A new starter acknowledging a policy set that includes a superseded version
- Acknowledgement tracked in a spreadsheet maintained by one person
Configuration
Folder structure
Policy library (controlled)
- Governance and conduct
- Information security and data protection
- Health, safety and environment
- People and employment
- Finance and procurement
Supporting documents
- Procedures and work instructions
- Guidance notes and FAQs
- Forms and templates
Acknowledgement records
- Attestation records by policy version
- Exception approvals
Superseded
- Retired versions retained for evidential purposes
Configuration
Metadata that makes a policy library governable
| Field | Type | Mandatory | Why it exists |
|---|---|---|---|
| Policy owner | User | Mandatory | A named accountable person, not a department. Ownerless policies are the ones that lapse. |
| Approver | User or role | Mandatory | Establishes who has authority to bring the version into force. |
| Effective date | Date | Mandatory | Answers "what was in force on this date" — the question an auditor actually asks. |
| Next review date | Date | Mandatory | Raises a review task in advance. A policy past its review date is a finding regardless of content. |
| Acknowledgement required | Yes / no | Mandatory | Distinguishes policies people must attest to from reference material they need not. |
| Applies to | Multi-select (role, department, entity) | Mandatory | Scopes the acknowledgement population, so the outstanding list is meaningful. |
Configuration
Approval and acknowledgement chain
Step 1: Draft and review
The owner drafts a new version. It routes to subject-matter and compliance reviewers in parallel, each recording approval or change requests with comments.
Step 2: Approve and set effective date
The approver locks the version and sets its effective date. The previous version is marked superseded and retained — never deleted, because it is the evidence of what applied before.
Step 3: Publish and require acknowledgement
Everyone in the "applies to" scope receives an acknowledgement task. Completion is recorded per named user against this specific version, and the outstanding list is visible as names rather than a percentage.
Step 4: Schedule the next review
The next review date is set before the current version lapses, and a task is raised ahead of it. Reviewing on time is a smaller job than explaining an overdue policy.
Configuration
Retention rule
What starts the clock
The trigger for a policy version is the date it ceased to be effective, not the date it was written. For acknowledgement records the trigger is usually the end of employment, since their evidential value is tied to the individual rather than the document.
Outcomes
What changes
- "Which version was in force on this date" is answered from the effective-date field rather than reconstructed
- Outstanding acknowledgements are a list of names that a manager can act on, not a completion percentage
- A policy change reissues the acknowledgement requirement, because attestation to version 3 says nothing about version 4
- Review dates raise tasks in advance, so overdue policies are prevented rather than discovered
- New starters acknowledge the current set, because superseded versions cannot be presented as current
FAQ
Policy management: common questions
How is an acknowledgement different from an email read receipt?
A read receipt says a message was opened. An acknowledgement records that a named user attested to having read a specific version of a specific document, at a timestamp, in their own authenticated session. The distinction matters the moment someone disputes that they were told.
Do we have to re-collect acknowledgements for every change?
That is your judgement, and the system supports either. A material change — a new obligation, a changed threshold — should reissue the requirement, because an attestation against the previous version proves nothing about the new one. A typographical correction reasonably should not.
Can we see who has not acknowledged a policy?
Yes, as a list of names scoped by the "applies to" field. A percentage is not actionable; a list a line manager can work through is. That is also what an auditor asks for when they sample acknowledgement.
What stops a policy quietly passing its review date?
Next review date is a mandatory field, and a task is raised in advance of it. Overdue policies then appear on a report rather than in an audit finding — which is the entire difference between managing a policy library and owning one.
Should procedures live in the same library as policies?
In the same system, in a separate branch. Policies state obligations and usually require acknowledgement; procedures describe how to comply and usually require training instead. Mixing them means either over-collecting attestations or under-controlling the procedures.
Dernière revue: 2026-09-01. See all seven use cases.