← All postsHow-to

Review date: the field that stops documents going stale

A review date turns a document from permanent into reviewable. Where to put one, how to choose the interval, and why "review when it changes" never happens.

How-toR

Almost every document an organisation writes is correct on the day it is approved and decays quietly from then on. A review date is the smallest possible defence: a field stating when somebody will look at this again, attached to the thing itself rather than living in an intention. Without it, documents are not permanent — they are simply unexamined, which is worse, because people keep following them.

What needs a review date

  • Policies and procedures, which describe how work is done and therefore go wrong whenever the work changes.
  • Risk assessments, where the controls assumed may no longer exist.
  • Supplier and customer records with commercial terms attached.
  • Access lists and permissions, which drift with every joiner and leaver.
  • Templates, which accumulate fields and lose relevance.
  • Anything stating a figure — a threshold, a rate, a limit — because those age fastest and most invisibly.

Choosing the interval

Risk-based rather than uniform. Annually is a sensible default for most documents; quarterly for anything where being wrong is expensive or where the underlying thing changes often; every two or three years for stable material that nobody benefits from re-approving. The common mistake is setting everything to twelve months, which produces an unmanageable pile in one month of the year and teaches people to approve without reading — a review that rubber-stamps is worse than none, because it creates a record of diligence that did not happen.

Put the review date on the face of the document, not only in a register. A reader who opens a procedure should be able to see at a glance whether it was last examined three months ago or four years ago, because that changes how much they should trust it.

Why "review when it changes" fails

Because nobody notices the change. The supplier is replaced, the threshold is raised, the system is retired — and the document describing the old arrangement does not announce itself. Event-based review works only where the event has an owner who will remember the document, which is rare. A date is crude and it fires without anybody being clever, which is exactly why it works.

Making reviews actually happen

  1. Name a person, not a department. A review owned by everybody is owned by nobody.
  2. Diary the date in the owner's calendar rather than only in the document.
  3. Spread dates across the year deliberately instead of defaulting to January.
  4. Record the outcome, including "reviewed, no change" — that is a valid and useful result.
  5. Treat a missed review as a finding rather than as housekeeping, because an overdue review is a known unknown.
  6. Shorten the interval for anything found wrong at review; the gap was evidently too long.

Ettex Records holds the review date as a field alongside the owner and the document itself, which makes the overdue list a filter rather than an exercise. Sorting by that date is the whole mechanism — it turns a stack of documents nobody has read since approval into a short list somebody is accountable for this month.

Frequently asked

How often should a policy be reviewed?

Annually as a default, quarterly where being wrong is expensive, longer for stable material. Uniform intervals are the usual mistake because they pile up in one month.

What if nothing has changed?

Record "reviewed, no change" with the date. That is a legitimate outcome and it evidences that the question was asked.

Should the review date be visible on the document?

Yes. A reader needs to know how current the material is before deciding how far to trust it, and a date buried in a register does not tell them.

MI
Written by Maria I.

Part of the Ettex team — writing about product, engineering and the future of work.

More posts
Get the best of the Ettex blogProduct news, guides and tips — straight to your inbox, no spam.