Plenty of quality systems run on Confluence. Procedures are written there, people read them there, and the wiki is genuinely better at that than a folder of Word documents on a shared drive. Then the first audit arrives and the questions get specific.
This page sets out what those questions usually are, which of them Confluence already answers, and which it does not. It is written for the person who has to produce the evidence, not for a certification body.
What the standards actually require
ISO 9001:2015 deals with this in clause 7.5, Documented information. Two parts matter here:
- 7.5.2 requires that documented information is reviewed and approved for suitability and adequacy before use.
- 7.5.3 requires that it is controlled: available where it is needed, protected from loss of integrity, and subject to control of changes — which in practice means version control.
ISO 13485:2016, for medical devices, is more explicit in clause 4.2.4. It requires that documents are reviewed and approved before issue, that they are reviewed, updated as necessary and re-approved, that changes and current revision status are identified, that relevant versions are available at the point of use, and that obsolete documents are prevented from unintended use.
Read that last sentence again, because it is the one that catches wiki-based systems. A standard does not only ask whether a document was approved. It asks whether the thing people are reading now is the thing that was approved.
The six questions an auditor asks
Stripped of the clause numbers, an audit of a controlled document comes down to this:
- Who approved this, and were they the right person to approve it?
- When was it approved?
- Which version was approved? Not "was this document approved" but "was this content approved".
- Has it changed since, and was it re-approved?
- When is it next due for review, and is anything overdue?
- Can somebody change it without going through that again?
Question 3 and question 6 are where wikis get uncomfortable, and they are related. A wiki is designed so that anyone with permission can improve a page at any moment. That is the feature. It is also the thing a quality system has to constrain.
What Confluence gives you out of the box
| Question | Native Confluence |
|---|---|
| Who approved it | Not really. There is no notion of approval. You can record it in a table on the page, but then the evidence is content, editable like any other content. |
| When | Same problem. Page history shows who edited and when, which is not the same as who approved and when. |
| Which version | Yes. Page history keeps every version and you can compare them. This part Confluence does well. |
| Changed since, and re-approved | No. Nothing links an approval to a version, so nothing notices when that version is superseded. |
| Next review due | No. There is no review period and no overdue state. Calendar reminders and a spreadsheet are the usual workaround, and they drift. |
| Can it be changed | Partly. Page restrictions exist and work. But they are applied by hand, and nothing lifts them when the document genuinely needs revising or re-applies them afterwards. |
So Confluence is strong on history and adequate on permissions, and has no concept of approval at all. That is not a criticism — it was never built to be a document control system.
Closing the gaps without buying anything
It is worth saying plainly that you can run a defensible system on stock Confluence, if you are disciplined. What it takes:
- A fixed page template with an approval block: approver, approval date, version number, next review date. Same place on every controlled page.
- A labelling convention, for example
controlledandobsolete, so a search can produce the list of governed documents. - Page restrictions applied by hand after approval, and lifted by hand when revision is needed.
- A register kept outside Confluence — usually a spreadsheet — with review dates, and a calendar reminder to check it.
This works. Auditors accept it. Two things tend to go wrong over time, and both are human rather than technical: somebody edits an approved page and forgets to update the approval block, and the review register stops matching reality because maintaining it is nobody's actual job.
A reasonable middle ground: if you have a handful of controlled documents and one person who owns them, the manual approach is fine and costs nothing. The arithmetic changes when you have dozens of documents across several spaces, or more than one person editing them.
What to look for if you do buy something
Whatever tool you consider, including ours, these are the questions worth asking before you commit:
- Does the approval attach to a version, or to the page? If it attaches to the page, an edit leaves a stale approval and you are back to question 3.
- What happens when somebody edits an approved page? The honest answer should be that the approval is withdrawn automatically, not that somebody gets an email asking them to remember.
- How is a workflow applied to many spaces? If the answer involves configuring each space, find out what happens when you have two hundred of them. This is the most common complaint about tools in this category.
- Where does the data live? For a regulated customer this matters twice over: data residency, and whether approval records leave your instance at all.
- Can you export the audit? Evidence you cannot get out is evidence you do not really have.
Document Control for Confluence, our app, is built around those answers: approvals bound to a page version and withdrawn the moment it changes, edit locking applied to the approvers, workflows targeted by rule rather than copied per space, scheduled re-review, and an audit view of every governed page. It runs entirely on Atlassian infrastructure, so no page content or approval record leaves your instance.
One caveat
Nothing here is certification advice, and no software makes an organisation compliant. A tool can make the evidence easy to produce and hard to falsify; the system, the training and the discipline are still yours. Any auditor worth having will look at all three.