Document review cycles for ISO-style audits in Confluence
If your quality manual, security policies or procedures live in Confluence, sooner or later an auditor will pick one and ask two questions: when was this last reviewed, and how do you know? The first is about a date. The second is about evidence. Confluence is good at the first kind of record when the page was edited, and silent when it was checked and left alone, which is the most common outcome of a good review.
This article explains what the two standards most teams meet actually ask for, what an auditor usually wants to see, and how to set up review cycles with what Confluence Cloud already gives you. One paragraph at the end is about our own app; the rest is meant to be useful without it.
A note on sources. ISO standards are sold by ISO and national bodies, and we have not quoted the standard text. What follows summarises clause titles and requirements as consultants and training providers quote them, linked inline. Your certification body and your own copy of the standard are the authority; this is not compliance advice.
1. What the standards ask for
ISO 9001 (quality). Clause 7.5 covers documented information. Clause 7.5.2, on creating and updating it, is commonly summarised as: documents are reviewed and approved for suitability and adequacy before release, and reviewed and updated as necessary (Core Business Solutions on 7.5.2, ISMS.online on clause 7.5). Clause 7.5.3, on control, asks that documented information is available and suitable where it is needed, protected, and that changes are controlled, which in practice means version control and knowing which version is current (Auditor Training Online on 7.5.3).
ISO 27001 (information security). Annex A control 5.1 in the 2022 edition is quoted as requiring that the information security policy and topic-specific policies are defined, approved by management, published, communicated, acknowledged, and reviewed at planned intervals and if significant changes occur (ISMS.online on A.5.1, High Table on A.5.1).
Two things are worth noticing. First, neither standard, as quoted, sets a fixed interval: you choose it. An annual review of policies is the usual practice, and many teams review procedures that change often on a shorter cycle. Second, "planned intervals" means the plan is part of what gets audited. Writing "reviewed annually" in a policy and then not doing it is worse than choosing a longer interval and keeping to it.
2. What an auditor usually wants to see
Across the consultant guides above, the same three pieces of evidence come up:
- A plan. Which documents are under review control, how often each is reviewed, and who is responsible. A register (a table of documents, owners and intervals) is the classic form.
- A record of each review, including the ones that changed nothing. Guides on A.5.1 stress that a review must be evidenced even when no change is made (High Table). "The page was not edited, so we must have looked at it and been happy" is not evidence.
- Change control. When a document did change, who changed it, when, and which version was in force on a given date.
Confluence covers the third piece well out of the box. The first two take some set-up.
3. Change control: page history already does most of it
Every Confluence page keeps its version history: each version with its author and date, a comparison view between any two versions, and restore, which copies an old version back as the newest one without deleting what came after it (Create, update, and manage written content). The change history macro shows version number, author, date and the version comment inline on the page itself (Insert the change history macro), which is a neat way to put a document's revision table where an auditor expects it.
Two habits make this history far more useful: write a short version comment whenever you publish a controlled document ("Annual review: updated section 4, retention period"), and restrict editing on controlled documents to the people responsible for them. Atlassian's documentation also describes deleting individual versions from the history, so treat the history as a good record, not as a tamper-proof one; if your auditor needs the latter, that is a question for your whole platform, not for one page.
4. The plan: a register in Confluence
The simplest register is a page with a table: document, owner, review interval, last review, next review. Link every row to the document. Set the page owner of each controlled document to the person in the register (Transfer content item ownership), so that the page itself says whom to ask. Add a page status such as "Approved" to documents in force (Add a status to your content).
This works, and for a dozen documents it is enough. It has one weakness: the register is a separate page that somebody has to keep in step with reality. The "next review" column does not turn red by itself, and nobody is told when it passes.
5. Reminders: automation, with one gap
Confluence automation can run on a schedule, filter pages with a CQL condition and act on them, for example by changing their status (Confluence automation, Triggers, Conditions, Actions). A monthly flow that finds controlled pages last updated more than a year ago and sets their status to "Review needed" is a reasonable baseline; in Confluence the Scheduled trigger takes no query, so the pages are found with the Lookup pages action or a branch (the same idea as a lastmodified search in CQL). Check Atlassian's pages for which plan you need and how many runs it includes.
The gap is the one section 2 warned about. Automation sees edit dates. A policy reviewed last month and found correct was not edited, so it still looks a year old, and it is flagged again at the next run. The workaround teams use is to make a small edit on every review, such as updating a "Last reviewed" line in the page, so that the edit date and the version comment become the review record. It works, and it has a cost: every review creates a new version whose only change is the date, and the record depends on everyone remembering the ritual.
6. Recording a no-change review
Whatever tools you use, decide in writing how a review that changes nothing is recorded, because that is the record auditors ask for and Confluence does not keep by default. The common options, from lightest to heaviest:
- a version with the comment "Annual review, no change" (the ritual edit above);
- a comment on the page by the reviewer, dated by Confluence, saying what was checked;
- a row in the register with the date and the reviewer's name;
- a document-management app with review states and approvals, where the review is an action that the app logs.
If you need formal approvals with sign-off chains before a document is released, the last option is the right one, and it is a larger product with a larger price. If your procedure only needs a date, an owner, a reminder and a list of what is overdue, the lighter options cover it.
What we make
Northwick Apps makes Review Due, a Confluence Cloud app for the lighter end of that list. On any page it adds a review date, a reviewer and a cycle (30, 90 or 180 days, or a year); a daily check comments on the page and mentions the reviewer when the date is near or past; Mark as reviewed records today as the last review and moves the next date forward without editing the page, so a no-change review no longer looks like neglect; and one dashboard lists every tracked page with its status, due date and last review, filtered to what each person may read. Honestly, for audits: it keeps the date of the latest review, not a history of every past one, and it has no approvals. Keep a reviewer comment or a register row if your auditor wants the full trail. It is submitted to the Atlassian Marketplace, and this paragraph will carry the listing link the day it is public; the FAQ and the Security page say exactly what it does and stores.