What Confluence version history records
Every time someone publishes or updates a Confluence page, Confluence version history saves a new numbered version of it. Old versions stay available, so you can see what the page said on any date, compare two versions, and put an earlier one back. For most teams that is a safety net. For anyone keeping policies or audit evidence in Confluence, it is also part of the record an auditor may look at.
This guide covers the mechanics first, then the details that matter for evidence, then what page history proves in an audit. It is about pages: Confluence's live docs have no drafts and no version history, so keep policies and evidence on ordinary pages.
How to open page history in Confluence Cloud
- Open the page.
- Select More actions (•••) at the top right.
- Select Version history.
The list shows each version with its number, its date, who made the change, and the version comment if one was added. Select a version to open the page as it was at that point.
How to compare versions in Confluence
- Open Version history.
- Tick the check boxes beside the two versions you want to compare.
- Select Compare selected versions.
The comparison view highlights what was added and removed. Long stretches of unchanged text are collapsed into an ellipsis, so the differences stand out. This is the quickest way to answer "what exactly changed between the version we approved and the one on the page now?", which is the question behind most policy evidence problems.
Tip: if a policy was approved at version 6 and the page is now at version 11, compare 6 with 11 directly instead of stepping through each edit.
How to restore a Confluence page version
- Open Version history.
- Select Restore this version beside the version you want (or at the top of the page if you have that version open).
- Adjust the default change comment if you want to say why, then select OK.
Restoring doesn't rewind anything. Confluence copies the old version and publishes it as a new, latest version, and every version in between stays in the history. If version 9 restores version 6, you get a version 10 with version 6's content. Nothing disappears, and the restore itself is on record. You need permission to edit the page to restore a version.
Version comments: the field that explains why
A version comment is a short note attached to a version, saying what you changed and ideally why. It is recorded in the page history, and you can send it to the page's watchers in the update notification.
- First publish: the publish dialog has a version comments field.
- Later updates: select the arrow next to Update, then Adjust update settings, and add your comment there.
Version comments are optional, and the default update flow doesn't prompt for one, so most pages end up with a history full of blank entries. For controlled documents, make them a rule: "Offboarding: access removed within 24 hours instead of 3 days" tells an auditor more than any diff.
What creates a new version, and what doesn't
| Action | New page version? |
|---|---|
| Publishing a page for the first time | Yes, version 1 |
| Updating a published page | Yes, one version per update |
| A collaborative editing session with several editors | One version when the changes are published, not one per person or keystroke |
| Restoring an old version | Yes, a new latest version with the old content |
| Autosaved edits that haven't been published | No. They are unpublished changes until someone selects Update |
| Comments and replies on the page | No. Comments are separate items with their own history, not edits to the page |
Two consequences: unpublished changes are visible to anyone else who opens the page in the editor, and changes discarded with Revert to previous version are gone for good and never appear in the history.
Can old versions be deleted?
Yes, and this is the detail that matters most for evidence integrity. From Version history, a Delete option sits next to older versions. Atlassian's documentation is clear about what happens next:
- It is permanent. A deleted version doesn't go to the trash and can't be restored.
- The other versions are renumbered. Delete version 2, and version 3 becomes the new version 2. The deleted version's changes are folded into the next one, so the current text is unaffected.
- The current version can't be deleted, only older ones.
Who can do it is less tidy: Atlassian's help says the Delete option appears only if you have permission to delete the item, and its API lets anyone who can update the page delete an old version. Assume that people who can edit a page may be able to remove its versions.
Renumbering is the real trap. If your approval record says "approved version 7" and someone later deletes version 3, the page's version 7 is now different text, and nothing in the numbering shows a gap. Two habits protect you: limit who can edit controlled pages, and record the date alongside the version number in any approval record, so a mismatch is noticeable.
How page history behaves when you move, duplicate, archive or trash a page
| What you do | What happens to the history |
|---|---|
| Move the page (within a space or to another space) | It is the same page, so its history goes with it, along with attachments, comments and child pages. Links to it are redirected. |
| Duplicate the page | The copy starts with no history. Duplicating copies attachments, labels and restriction settings, but not comments or version history. |
| Archive the page | Editing and commenting are switched off, but anyone who can view the page can still view its history. |
| Delete the page | It goes to the space's trash with its history. A space admin can restore it, but it comes back at the root of the space and loses inherited permissions. |
| Purge it from the trash | The page, all its versions and its attachments are gone for good. |
The practical rule: never "move" a policy by duplicating it and deleting the original. The copy's history starts at version 1, and the approval trail stays behind on the old page.
What version history proves in an audit, and what it doesn't
| Question | Does page history answer it? |
|---|---|
| What did the page say on a given date? | Yes. Open the version that was current then. |
| Who changed it, and when? | Yes, for each published version. |
| What changed between two versions? | Yes, with the comparison view. |
| Why did it change? | Only if someone wrote a useful version comment. |
| Who approved this version? | No. Editing is not approving, and there is no approval field on a version. |
| Is the text on the page today the text that was approved? | Only if you know which version was approved, from a separate record. |
| Who read or accepted this version? | No. Page views aren't tied to a version and aren't acceptance. |
| Was anything removed from the history? | Not reliably. Deleted versions leave no gap in the numbering. |
Page history is a strong record of edits and a weak record of decisions. Auditors generally rely on it for "what the text was", then ask for something else to show who approved and who acknowledged it. The approval side is covered in more depth in policy version control and approvals auditors accept, and the reading side in Confluence read confirmation.
Filling the gaps by hand
You can close most of these gaps with discipline and a few conventions.
Require a version comment on every controlled page
Agree a format, for example "what changed; why; who asked for it", and spot-check your policies' history for blank entries.
Keep a revision table on the page
A short table at the end of each policy records the decision that page history can't. An example:
| Page version | Date | Summary of changes | Approved by |
|---|---|---|---|
| 4 | 2026-02-10 | Initial approved version | CTO, 2026-02-12 |
| 7 | 2026-06-03 | Offboarding: access removed within 24 hours | CTO, 2026-06-05 |
There is a catch: adding the approval row is itself an edit, so it creates a new version after the one that was approved. Record the version number that was approved, not the one that contains the table, and expect the approved version and the current version to differ by one.
Record approvals outside the page
An approval email, ticket or signed record should name the page, the version number and the date. A link to the specific version in page history is better than a link to the page, because the page link always shows the latest text.
Limit who can edit
Fewer editors means fewer surprise changes and fewer people who could delete a version. Restrict editing to the policy owner and whoever runs the compliance program.
Snapshot the approved version
Export the approved version when it is approved and store the file with your evidence, so a later deleted version can't change what you hand over. See SOC 2 evidence collection.
Version-bound approvals with Compliance in a Box
Compliance in a Box is a Confluence Cloud app that runs a SOC 2 program in one Confluence space. Its policies are ordinary Confluence pages with normal page history. The app adds the decision record that history lacks, tied to a specific version.
- Approvals bound to a version and a fingerprint. When an owner selects Submit for approval, the app records the exact page version and a fingerprint (a hash) of its content. An approver's decision is accepted only if the page is still at that version. If anyone publishes an edit first, the submission is cancelled and the owner resubmits, so nobody approves text they haven't seen.
- A required change summary. Every submission needs a What changed? summary, and the owner ticks Material change when employees must acknowledge again.
- Edits after approval are visible. Publishing an edit to an approved policy changes its status to Changes pending. The approved version still stands, and the Policies tab links to exactly that version, even after the page has moved on.
- Acknowledgements bound the same way. Employees acknowledge the approved version, and the app records which page version that was and a fingerprint of its content.
- The app doesn't add versions to your policies. It never edits a policy or evidence page after creating it, except for a policy import that a Compliance Admin starts on purpose, so the page history shows only the people who changed the text.
- Locked pages. Only the policy's owner and Compliance Admins can edit a policy page, using Confluence page restrictions (Confluence Standard or above).
- Reports that link to the exact version. The generated Policy Approval Log lists each submission with its linked page version, change summary, each approver's decision and the outcome. Each "Version N" link in the reports opens that version from the page history, and the links still work in an exported PDF for anyone with access to the site. A refresh only rewrites a report page whose content changed, so unchanged reports don't collect extra versions.
The details are in the user guide: why edits cancel a submission, what you acknowledge and why the evidence holds up.
FAQ
Does restoring an old version delete the newer ones?
No. Restoring publishes a copy of the old version as the newest version. Every version in between stays in the page history.
Can I get a deleted page version back?
No. Deleting a version is permanent and it doesn't go to the trash. Deleting a whole page is different: the page goes to the space's trash with its history and can be restored until it is purged.
Is Confluence page history enough evidence for a policy approval?
On its own, usually not. It shows who edited the page and when, but not who approved which version or who read it. Pair it with an approval record that names the exact version and date.