Version
Tells you which copy of the policy you are holding. It is the field that stops two live versions of the same document from circulating at once.
Set when: drafting begins
Example format: 1.0, 1.1, 2.0
Document control guide
Document control: who wrote it, and when
Document control answers a short list of questions about any policy file: who wrote it, when it was approved, who owns it now, and when it is next due for review. This guide covers the fields that record those answers, where to place them, and how to keep them accurate as staff and structures change.
The four fields that matter most
DPC's policy template guidance names version, review date, policy owner, and approval date as the core document control fields, and that list is a good working minimum. Everything else is optional detail you can add later.
Review date
The date someone must look at the policy again. An honest review date is what keeps a document set from quietly going stale.
Pick it when you approve
Common cycle: 12 months
Policy owner
The person accountable for the policy staying correct. The owner is not always the author, and this is where most review findings start.
Name a role or a person
Check it at every staffing change
Approval date
When the policy was formally accepted by whoever holds that authority. It is not the same as the date staff start following it.
Set when: signature lands
Separate from the effective date
If your template only has room for a handful of fields, start here. Four fields applied consistently beat a long metadata table nobody fills in. Our policy templates ship with the block already built in.
A policy with a clear version, an owner and a review date can be understood by someone who was not there when it was written. That is the standard worth aiming for.
Where the control block goes
Document control information is typically placed at the start or the end of a policy, and both placements have defenders. A header block puts status in front of the reader immediately, which suits documents people consult in a hurry. A footer or closing block keeps the opening clean, which suits formal documents with a cover section.
The important thing is consistency across your whole policy set. Pick one placement, record the decision in your own style guide, and hold every document to it. Mixed placement is how readers learn to stop checking.
See documentation UX patternsHeader block
Status visible before the first clause. Good for field-use policies staff check mid-task.
Closing block
Keeps the opening page clean. Suits formal documents that already carry a cover sheet.
Both ends
Some organizations repeat the block. That is fine as long as the two copies never disagree.
Revision history
A short list of what changed and when. One line per release is enough for most offices.
Whichever placement you choose, the same four fields appear on every document in the set — that repetition is the point.
Version numbers without a system
You do not need version-control software. A simple decimal scheme works: 1.0 for the first approved release, 1.1 for a minor correction, 2.0 for a substantive revision. Record the change in a short revision history line so a reader can see what moved.
When you publish a new version, retire the old one or mark it clearly as superseded. Two live versions of the same policy is the failure this field exists to prevent.
Version history, as a reader sees it
2.0
Substantive revision to the escalation route
1.1
Minor correction, contact role updated
1.0
First approved release
Rule of thumb
If a reader cannot tell which copy is current after ten seconds, the numbering scheme is doing too little work.
Tick rail scaled to the review interval — one rule, read at register scale.
Naming the policy owner
The owner is not always the author. Authors change; the owner is the role accountable for the policy staying correct. Name a position where possible, such as Director of Operations, and a person where the organization is small enough that roles are individual.
An owner who has left the organization is a common finding during review, and it is usually the first sign that a policy set has stopped being maintained. Fixing the field costs a minute; discovering it during an audit costs more.
Approval date versus effective date
These two are not the same, and confusing them causes real problems. The approval date is when the policy was formally accepted by whoever has that authority. The effective date is when it starts applying to staff. A policy can be approved in March and take effect in April to allow for training.
If your template has room for only one date, use the approval date and note the effective date in the purpose section. That way the control block never contradicts the body of the policy.
Two dates, one field
Approval is a governance event: someone with the authority signed off. Effect is an operational event: staff are now expected to follow it. Recording both — or recording approval and citing effect in the purpose line — removes the ambiguity that causes disputes later. It also answers the question auditors actually ask, which is when the current version became the current version.
Read the policy writing standardsKeeping the record accurate when staff change
The control block decays the moment someone leaves or changes roles. A light process fixes this: review the owner and approver fields whenever there is a staffing change, and treat the review date as a hard prompt rather than a suggestion.
If your organization has a small team, tie the check to something that already happens, such as an annual operations review, rather than creating a separate ritual. The maintenance only survives if it rides on a habit you already keep.
Document control for digital preservation practice
The field set in this guide follows the pattern used in digital preservation policy practice, where a document must remain interpretable years after it was written. That context is stricter than most offices need, but it makes the value obvious: a policy with a clear version, owner, and review date can be understood by someone who was not there when it was written.
That is the standard worth aiming for, even if your organization never needs the full apparatus. You are not building an archive; you are making sure the next reader is not guessing.
Common document control failures
The failures repeat. Each one is cheap to prevent and expensive to discover during an audit. The fix is almost always the same: put the fields in the template so they appear by default.
No review date on the document
Nothing gets revisited. The policy stays on the intranet long after the process it describes has changed, and staff quietly stop trusting it. Put a review date in the template and give someone the job of honouring it.
An approver who has retired
The name on the approval line no longer works here, so no one is sure who can amend the document. Name the approving role in the template, then confirm the current holder at each review.
Version numbers that restart every year
Two documents both called 1.0 circulate in the same office and no one can tell which came first. Keep the sequence continuous and let the revision history carry the dates instead.
A policy marked final with no way to tell which final
The word final is not a version. Replace it with a number and an approval date, and move the previous release to a superseded folder or mark it plainly in the header.
Put the fields in the template once, and they appear on every policy after that
Threnova Digital publishes plain-English policy templates and document control guidance for U.S. organizations. If you are deciding how much control structure your policy set needs, the review-cycle guide is the natural next read.