Auditable for Confluence · Rethought Systems

Documentation

Auditable answers the three questions an auditor asks about every controlled document: who approved it, when it was last reviewed, and whether it is still the version that was approved.

What it does

Auditable answers the three questions an auditor asks about every controlled document:

  1. Who approved this?
  2. When was it last reviewed?
  3. Is this still the version that was approved?

Confluence can answer none of them on its own — its audit log does not record content edits.

Getting started

1. Create a control set

Open Auditable from the Confluence sidebar → Control sets → fill in:

FieldMeaning
Namee.g. "ISMS Policies"
SpaceThe Confluence space holding the documents
StandardISO 27001:2022, NIS2, ISO 9001, ISO 13485, SOC 2, or Custom
Review intervalDays between required reviews (365 is typical)

The standard you pick sets a sensible default review cadence. It does not restrict anything.

2. Enrol documents

Enrol every page in this space places all current pages under document control at once. Alternatively, open any page and use the Document control panel under the title to enrol that page alone.

3. Approve

On a controlled page, the Document control byline panel shows current status. Click Approve current version. Auditable records:

The next review date is set automatically from the control set's interval.

4. Export evidence

Auditable → Evidence pack produces, for any date range:

content hash, and next review date

Both are CSV, ready to paste into a spreadsheet for your auditor.

Understanding the five states

StateMeaning
ApprovedThe live page is byte-for-byte the approved version, and review is not yet due
Review due soonApproved and unchanged; review date within 30 days
Review overdueApproved and unchanged; review date has passed
Changed since approvalThe live page is NOT the approved page. Someone edited it after sign-off
Awaiting first approvalUnder control, never approved

"Changed since approval" always outranks "overdue." A document edited after sign-off is never reported as merely late — it is reported as not being the approved document. That ordering is deliberate.

How change detection works

At approval, Auditable hashes the page's storage-format body with SHA-256 and stores the digest. Whenever the page is updated, the app re-hashes and compares. A mismatch flips the state and writes an entry to the audit trail recording both the old and new hashes.

CRLF line endings and trailing whitespace are normalised before hashing, so simply re-saving a page without editing it does not raise a false alarm. Any change to the rendered document does change the hash.

Approver permissions

A control set with no named approvers allows anyone who can view the page to approve — the sensible default for a small team.

Once approvers are named, only they (and the control set owner) may approve. This is enforced on the server, not in the interface — a user cannot bypass it by editing the page or calling the API directly.

Data and privacy

Auditable runs entirely on Atlassian Forge. Your content never leaves your Atlassian cloud tenancy, and the app requests read-only Confluence permissions — it never creates, edits or deletes a page. See the privacy policy for detail.

Limits

Support

See the support page, or email tanzeel@rethought.to.