JSJidoSeal

Does ISO 9001 require periodic document review?

What ISO 9001:2015 and ISO 9001:2026 actually require, where the annual-review habit came from, and how to record your own review cycle in markdown frontmatter. Last reviewed 23 September 2026.

The short answer

No. ISO 9001 sets no interval for reviewing documents. What it does require is narrower:

  • Review and approval when you create or update a document. Clause 7.5.2 c) asks for appropriate "review and approval for suitability and adequacy" whenever documented information is created or updated.
  • Documents that are fit to use. Clause 7.5.3.1 a) requires controlled documented information to be "available and suitable for use, where and when it is needed".
  • Your own procedure, followed. If your document-control procedure says every document is reviewed yearly, an auditor can hold you to that. Only commit to a cycle you will actually run.

ISO 30401, the knowledge-management standard, sets no review interval either. Its clause 4.4.2 asks a knowledge-management system to cover, among other things, the handling of outdated or invalid knowledge. A review date in each file is one reasonable way for a knowledge base to evidence that it does.

So a review date in your frontmatter is a commitment you choose and then have to keep. No clause requires it.

What the clauses say

From ISO 9001:2015:

  • 7.5.2 c): when creating and updating documented information, ensure appropriate "review and approval for suitability and adequacy".
  • 7.5.3.1 a): documented information is "available and suitable for use, where and when it is needed".
  • 7.5.3.1 b): it is "adequately protected (e.g. from loss of confidentiality, improper use, or loss of integrity)".
  • 7.5.3.2 c): "control of changes (e.g. version control)".

(For how the rest of clause 7.5.2 maps onto frontmatter keys, see ISO 9001 clause 7.5.2 as markdown frontmatter.)

None of them names a frequency. Staleness can still become a finding: a document that is wrong is not "suitable for use", whatever its date. But age alone breaks no ISO 9001 requirement. An old document that is still accurate is only a problem if your own procedure promised a review that didn't happen.

Where the annual-review habit came from

Earlier editions said something different. In ISO 9001:2000 and ISO 9001:2008, clause 4.2.3 b) required organizations "to review and update as necessary and re-approve documents". An Elsmar Cove training slide on that clause noted: "With some QS registrars the requirement is a minimum yearly review of procedures." It went straight on: "But the ISO document does not say that nor does it give an 'appropriate' timeframe for such review."

The 2015 edition rewrote document control as clause 7.5, and that sentence is gone. ISO 9001:2026, published on 16 September 2026, adopts ISO's latest Harmonized Structure, whose clause 7.5 sets no review interval either, and published comparisons report that clause 7.5 is unchanged apart from wording. The 2015 position still holds.

Yearly review survives as a habit. isoTracker, a vendor of document-control software, says many of its customers choose to review documentation about once a year, and adds: "While this isn't an ISO 9001 requirement, it is a good frequency for most businesses."

When an auditor calls an old document "outdated"

The question keeps coming up on quality forums. In a 2020 Elsmar Cove thread, a member described an internal audit in which the lead auditor called a work instruction dated 2013 "outdated", although the process it described hadn't changed. Asked which clause the auditor had cited, the member reported ISO 9001:2015 clause 7.5.2. Replies pushed back on the clause:

  • "I see nothing in 7.5.2, or all of 7.5 period, that requires a document be updated at any specified interval."
  • "Review is only required when creating or updating the document."

Two practical points from that thread are worth keeping:

  • Your own procedure binds you. That company's own procedure did say documents were to be reviewed periodically. That, not clause 7.5.2, is where a finding could legitimately come from: a promise the organization wrote for itself.
  • "Reviewed, no change" is a legitimate outcome. One member described recording "REVIEWED and No change" in the revision history, keeping the revision level and noting the date of the review. Another suggested a line on the internal-audit report where each process owner signs that the current revisions of their documents are adequate.

Set a cycle you can keep

Set the cycle by risk rather than by calendar. Ask how much harm a wrong version would do, and how fast the underlying process changes. An illustrative split (a suggestion, not from any standard):

Kind of document Review whenever it changes, plus…
Safety-, legal- or customer-critical procedures a scheduled check at least yearly
Stable reference material every two to three years
Fast-moving how-tos, including instructions your AI tools read every three to six months

Google's engineering book describes the same mechanism for internal documentation. "At Google, we often attach 'freshness dates' to documentation." These record when a document was last reviewed, and "metadata in the documentation set will send email reminders when the document hasn't been touched in, for example, three months." The same chapter insists that "documents should also have owners. Documents without owners become stale and difficult to maintain."

Record the cycle in frontmatter

---
title: Calibration of torque wrenches
owner: Metrology Lead
status: stable
review_policy: yearly                # or a pointer to the procedure that sets it, e.g. QP-07-05
reviewed_at: 2026-09-18              # the last time a person actually checked it
next_review_at: 2027-09-18           # when it is due again
stale_after: 2027-10-18T00:00:00Z    # optional: when tools should stop trusting it
---
  • review_policy states the rule. A pointer to your procedure works as well as a cadence word, and it keeps the rule in one place.
  • reviewed_at and next_review_at are independent dates. Set next_review_at from the policy when you review, and don't let a tool recalculate it silently.
  • status comes from the Open Knowledge Format (OKF v0.2 §5.4), an open specification published by Google Cloud. It takes draft, stable or deprecated, and a missing status means stable. Retire a document by marking it deprecated instead of deleting it, so links and history survive.
  • stale_after is also from OKF (§5.5): the instant after which the document counts as stale. Write it as a full timestamp with a UTC offset. OKF's reference implementation ignores a date-only value rather than guess which midnight you meant.

If you review a document and nothing needs to change, update reviewed_at and next_review_at, leave the content and version alone, and say so in the commit message ("Reviewed, no change"). That is the digital form of the "REVIEWED and No change" entry described above.

One thing not to do: let a script or an AI assistant stamp reviewed_at: today across files nobody read. That creates a record of a review that never happened, which is worse than an honest gap, and an auditor who samples files can ask who did the review. For the other fields that should stay human-only when AI tools edit documents, see A defensible audit trail for AI-edited documentation.

Find what's due

#!/usr/bin/env python3
"""List markdown files that are due for review, or that have no review date.

Usage:  python3 review_due.py path/to/docs
"""
import datetime as dt
import sys
from pathlib import Path

import yaml  # pip install pyyaml


def frontmatter(path):
    lines = path.read_text(encoding="utf-8-sig").splitlines()
    if not lines or lines[0].strip() != "---":
        return {}
    for i, line in enumerate(lines[1:], start=1):
        if line.strip() == "---":
            try:
                data = yaml.safe_load("\n".join(lines[1:i]))
            except yaml.YAMLError:
                return {}
            return data if isinstance(data, dict) else {}
    return {}


def as_date(value):
    if isinstance(value, dt.datetime):  # check datetime first: it is a subclass of date
        return value.date()
    if isinstance(value, dt.date):
        return value
    try:
        return dt.date.fromisoformat(str(value).strip()[:10])
    except ValueError:
        return None


today = dt.date.today()
for path in sorted(Path(sys.argv[1] if len(sys.argv) > 1 else ".").rglob("*.md")):
    fm = frontmatter(path)
    due = as_date(fm.get("next_review_at"))
    if due is None:
        print(f"{path}: no next_review_at")
    elif due <= today:
        print(f"{path}: review due since {due} (owner: {fm.get('owner', 'not set')})")

Run it weekly or in CI and send the output to the owners. That is Google's freshness-date mechanism, minus the email.

Why AI agents need this more than people do

A person who opens a three-year-old procedure will often notice how old it is. An AI tool such as Claude Code, GitHub Copilot, Cursor or a local model has no reason to, unless the file says so. With status, next_review_at and stale_after in the frontmatter, you can tell an agent to skip or flag anything deprecated or past its review date, instead of hoping it notices. For the knowledge-management side of the same question, see What ISO 30401 asks of a knowledge base.

Where JidoSeal fits

JidoSeal's Gold tier requires status, review_policy, reviewed_at and next_review_at on every file in a folder. That is stricter than ISO 9001, on purpose: it is JidoSeal's way of evidencing a review discipline, not something ISO requires. Pick a folder, scan it, and the free Self-Check lists every file missing a review field. Where one is missing, it pre-fills a suggestion (yearly, today's date, a year from today) that you can accept file by file or for a whole group at once, and it writes nothing until you confirm. Accept today's date only for files someone has actually checked: the tool fills in the date, but the review is yours to vouch for. The scan and the fixes are free, and your files never leave your machine; only a certificate costs money.

Sources