Make content versions immutable by preventing deletion

Question

In Confluence Cloud only: Can an organization administrator, site administrator, space administrator, or content administrator configure Confluence so that historical versions of pages cannot be deleted, while users can still edit those pages and create new versions?

I am specifically looking for an append-only version history: users may create new page versions, but nobody except perhaps an organization/site administrator may delete an existing historical version.

Please distinguish Confluence Cloud from Data Center/Server and cite the current Cloud documentation describing the applicable permissions or configuration.

Trevan Householder_Isos-Tech-Consulting_ · Answer

Hi @Timothy Black, @Martin Runge and  @Anwesha Pan are right that Cloud has no append-only setting .

The Cloud doc says the version Delete option only appears if you have permission to delete that item, and it's permanent.

Data Center is narrower: only space admins can delete versions.

The closest native control in Cloud is removing the space Delete permission from everyone but a small admin group, so editors still create versions. It isn't airtight, since space admins can regrant themselves and the REST API can delete versions too.

There's an open suggestion for exactly this, CONFCLOUD-34041, worth a vote. For real compliance-grade immutability, an external archive or an app like the ones Kris mentioned is the way to go.

Lucas Brictson · Answer

Hey @Timothy Black

You can't get append-only history natively in Confluence Cloud, as Martin and Anwesha said. Whoever holds the delete permission in the space can remove a historical version, and the organization audit log only tells you afterwards.

For an audit, though, the question is usually not "can a version be deleted" but "can you prove what was approved and whether the current page still matches it". You can answer that without immutable history:

* Record the version number at approval. The version history panel no longer shows numbers, but the REST API still returns them (/wiki/rest/api/content/{id}/version). Write the number and the date into your approval record (a comment, a database row, a register page).
* Record a fingerprint of the content. Export the approved version to PDF (or copy the storage format) and keep a hash of it with the approval record. If a version is later deleted or the page edited, you can still show what was approved and whether the live page matches.
* Keep the approval record somewhere the page editors can't touch. A restricted page or space, so the record and the content have different delete permissions.
* Restrict delete in the space to admins, and review the organization audit log on a schedule rather than hoping to notice.

That gives an auditor a verifiable chain even though Confluence itself can lose a version.

If this is for a compliance program (SOC 2, ISO 27001) and you have many policies, Compliance in a Box does steps 1 to 3 automatically: each approval and each employee acknowledgement is stored against the page version and a hash of the content, the page byline shows when the page has moved since approval, and the approval log is a generated page in the compliance space, restricted to compliance admins. https://compliance.auralitesolutions.com/guide/policies.html

Disclosure: I'm with Auralite Solutions, the vendor of Compliance in a Box. The native steps above work without it.

Kris Klima _K15t_ · Answer

Hi Timothy Black

You can solve it by

* synchronizing two spaces
* publishing one space into another 
* versioning Confluence spaces

The idea is that you're using Space A to work in and - upon saving (Publish/Update) a page, the page is automatically synced to Space B.

If a page exists in Space B, it will be overwritten by the updated version of the page - this will keep your page versions in Space B.

The crucial for this approach is restricting access to Space B, thus preventing unauthorized users from messing up with page history.

With versioning, you can create immutable versions of the entire space (1.2, 1.3 etc. or January, February…, as you please). Again, you will restrict access to published spaces/versions.

* Space Sync for Confluence by Ricksoft - for space syncing
* Scroll Content Manager by K15t - for space to space publishing and versioning. This app is often use in compliance-heavy environments to create immutable versions of documentation.

Disclaimer: I work for K15t having joined after being a customer (active user) of K15 apps for over a decade.