Review cycle & maintenance
Set a review date and keep it current
A published policy is not finished. It is maintained, or it decays. The review cycle is the part of document control that puts an obligation on the calendar: a named owner, a review date, and a decision at that date to keep, revise, or retire the document.
What this page covers: how to choose an interval, who owns the review, how to track dates in a shared register, and how to retire a policy that no longer applies.
- Typical interval
- 12 or 24 months
- Review outcomes
- Keep, revise, retire
- Reminder lead time
- A few weeks
Why stale policies are worse than missing ones
A missing policy is a gap people can see. A stale policy looks authoritative while describing a process that no longer exists, which is harder to catch. It gets cited in meetings. New staff follow it. The review date field exists precisely to pull these documents back into view before someone acts on outdated instructions.
The cost of a silent drift
Drift is rarely dramatic. A role is renamed, a form number changes, a step moves to a different team. Each edit is small on its own. Six months later the document reads as a set of instructions that only the people who wrote it could still follow, and the people who wrote it have moved on.
Catching that state is the whole job of a scheduled review. Nothing on the page has to look wrong for it to be wrong; the review date is what forces a second pair of eyes back onto the text while the change is still small enough to fix in one sitting.
A review is only useful if someone opens the file. Placing the review date next to the owner keeps that person one click away from the document they are responsible for.
Choosing a review interval
Match the interval to how quickly the facts change, not to how much the team enjoys reviews. Use the register below to pick a starting point, then adjust it once you have watched a cycle run.
Stable operational policy
Handbooks, house style, and internal conventions that change slowly. A two-year cycle is honest here, and it keeps the annual slot free for the documents that need it.
24 months
Owner: function head
Regulated or safety-linked
Anything tied to a filing requirement, a safety procedure, or an external rule set. Shorter intervals suit the pace at which the underlying requirement can move.
Owner: compliance lead
Systems and tooling
Access rules, escalation paths, and anything that names a tool, a field, or a screen. These tend to change with every platform migration, so plan for a shorter loop.
6 to 12 months
Owner: systems owner
Annual reviews of documents that never change waste the time you need for the ones that do. If a policy has survived two cycles untouched, that is a signal to lengthen the interval, not to keep the ritual.
What a review actually involves
A review is a decision, and it has three outcomes. The decision should take minutes for a stable policy and longer for one that has drifted. What matters is that someone with authority makes the call and the date is recorded.
Keep
The text is still true. Record the review and move the date forward. Do not re-approve what has not changed.
Revise
Something has drifted. That means a new version, a new approval, and a version note that names what changed.
Retire
The policy no longer applies. Mark it superseded, archive it, and remove links from the places staff actually look.
The owner-drives-the-review model
Assign the review task to the policy owner rather than to a central administrator. The owner is closest to whether the content is still true. A central administrator can track dates in a register, but only the owner can say whether the policy still reflects reality.
If no owner is named, the review will wait for someone to volunteer, which usually means it waits indefinitely. Naming a single person at the time of approval costs one line and prevents that outcome.
The ruler marks the owner’s review window. Reminders should fire a few weeks before the date so the owner can read the policy and book the decision.
A working register
- Title
- Policy, procedure, or standard name
- Owner
- One named person, not a team inbox
- Approved
- The date the current version took effect
- Review date
- The next scheduled decision point
Sort by date
Sorting by review date puts the urgent work at the top of the list. A register is a queue, not a filing cabinet, and the queue should reorder itself every week.
Overdue rows are visible at a glance, which is what makes the register easier to trust than a calendar invite that gets declined.
Read the document control guideTracking review dates without dedicated software
A shared spreadsheet with columns for title, owner, approval date, and review date is enough for most organizations. Sort by the review date, and the top of the list is your work queue.
- Data retention policy Records lead Overdue
- Remote work procedure People operations Due this month
- Vendor review checklist Procurement Due in ten months
Add a reminder lead time of a few weeks so the owner has room to act. This approach costs nothing and is far more likely to be maintained than a system that requires training to use.
Handling policies that are still correct
A visible record of regular review is itself evidence that the document is maintained.
Not every review ends in a revision. When a policy is still accurate, record the review and move the date forward. Some teams mark this as a reviewed, no change entry in the revision history. It is worth doing. It stops the same policy from being re-examined from scratch every time someone wonders about it.
Keep the entry short. The date it was reviewed, the person who signed off, and the new review date are enough. If the next reader can see that a decision was made and when, the record has done its job.
For the versioning conventions that sit behind this habit, see the Policy Writing Standards page.
Retiring a policy cleanly
Retirement is the outcome people skip. When a policy no longer applies, mark it superseded, move it to an archive, and note what replaced it if anything did. Remove links to it from the places staff actually look.
A retired policy left in circulation causes the same confusion as a stale one, and it is harder to spot because nothing on its face says it is obsolete. If a replacement exists, link the archived copy to the current version so anyone who lands there is redirected by the document itself.
-
Step 01
Mark the copy
Stamp the document superseded and note the date
-
Step 02
Archive it
Move the file to the archive folder so it stays out of the working set
-
Step 03
Name the replacement
Add a line saying what replaced it, and link to that version
-
Step 04
Update links
Remove the retired copy from intranet pages, handbooks, and shortcuts
-
Step 05
Record the decision
Log the retirement in the register so the next reviewer sees why
Review cycles during organizational change
Restructuring, mergers, and leadership changes reset assumptions across a policy set. These are the moments to run an out-of-cycle review rather than wait for the scheduled date.
A short pass at the right moment prevents a year of documents that reference roles which no longer exist.
Check owners and approvers
These fields change most often. A review date is only useful if the person named next to it still works on the policy.
Sweep scope changes
Work through any policy whose scope shifted, even if the wording still reads well.
Retire what the change removed
Policies tied to a merged team or a discontinued process should not stay in the live set.
Reset the calendar
Once the sweep is done, set new review dates from the day the change took effect, not from the old schedule.
If the sweep is too large for one pass, use the register to prioritize by consequence: policies that govern access, safety, or money first.
How long should a policy review take?
A stable policy should be decided in minutes if the owner already knows the answer. The meeting exists to record the decision, not to read the document aloud. If a review regularly takes an hour, the policy is probably too large for one owner or the wrong person owns it.
What happens if a review date passes with no decision?
Nothing physically breaks, which is why overdue rows are easy to ignore. Treat an overdue review as a signal that the interval is wrong, the owner has changed, or the policy no longer belongs in the live set. All three are worth fixing, and each fix takes one line in the register.
Do we need a new approval when nothing changes?
No. If the text is unchanged, there is nothing new to approve. Record the review, note who confirmed it, and move the review date forward. Re-approving unchanged text adds ceremony and trains people to treat the register as noise.
Can a review cycle run on shared drives alone?
Yes, provided the register lives in one place and the file names carry a version marker. The failure mode is not the drive; it is having three copies of the register where only one is edited. Pick one, link to it, and stop emailing attachments.
Start with one policy and one date
Pick the policy that would hurt the most if someone followed an outdated version. Name its owner, set a review date, add the reminder lead time, and note it in the register. One working row teaches the habit faster than a plan for the whole set.
Threnova Digital publishes policy templates and document control guidance for U.S. organizations. If you would like help setting up a register, writing the first review schedule, or checking an existing one, our team is available Monday to Friday, 9:00 AM to 6:00 PM Eastern Time.