Confluence is where a lot of companies write their policies, and for good reason: everyone already has access, the editor is familiar, and every page keeps its history. But a page titled "Access Control Policy" is not yet a managed policy. This article is about the gap between the two, and how to close it.
What Confluence policy management needs beyond a wiki page
A wiki page is built so anyone can improve it at any time. A policy is the opposite: a commitment your company makes to its employees, customers and, for a SOC 2 report, its auditor. Good Confluence policy management keeps what helps (the editor, the history, the search) and adds what a plain page lacks:
- A single owner. One named person who is accountable for keeping the policy current. Not a team, not "Security".
- Controlled editing. Only the owner and the people running the program can change the text. Everyone else reads.
- Approval of a specific version. Someone with authority signs off on the exact text, and a later edit is not quietly covered by an earlier sign-off.
- A review cadence. Each policy has a next review date, usually a year out, and someone notices when it passes.
- Knowing who has read it. For the policies everyone must follow, a record of who read and accepted which version.
- Retiring old policies. A policy that no longer applies is marked as retired, not deleted, so its history stays available.
- An audit trail. A record of every approval, review and change that nobody can quietly rewrite.
If you are still deciding which policies to write in the first place, start with which SOC 2 policies you need. The rest of this article is about how to manage policies in Confluence once you have them.
How to set up a policy area in Confluence by hand
Confluence already offers most of what a small company needs to start.
Give policies their own home
Put every policy under one parent page, ideally in a space dedicated to policies or to your compliance program. Policies scattered across team spaces are hard to find, hard to permission and hard to hand to an auditor. If you are building a full SOC 2 program, how to run a SOC 2 compliance program in Confluence covers the wider space structure. For policies alone, a tree like this is enough:
- Policies (parent page: what lives here, who to ask, a link to the register below)
- Policy register
- Acceptable Use Policy
- Access Control Policy
- Information Security Policy
- Retired policies (a parent page for policies no longer in force)
Name pages consistently
Use the plain policy name as the page title: "Access Control Policy", not "Access Control Policy v3 (FINAL)". A stable title keeps links from runbooks and onboarding pages working. Version information belongs in the page, not the title.
Use the same structure in every policy
A common outline is Purpose, Scope, Roles and Responsibilities, Policy Statements, Exceptions, Enforcement and Related Documents. Write the policy statements as short "must" and "should" sentences that someone could check, because whatever you write is what you will be held to.
Lock editing with page restrictions
On Confluence Standard and above, you can add edit restrictions to a page so only named people or groups can change it. Restrict each policy page to its owner plus a small group of program admins. Leave viewing open to everyone who needs to read it. Confluence Free has no page restrictions, so on that plan anyone who can edit the space can edit every policy.
Add a header and a revision table
Start each policy with a short block of metadata and end it with a revision table. A header might look like this example:
| Field | Example |
|---|---|
| Owner | Head of Engineering |
| Approver | CTO |
| Status | Approved |
| Last approved | 2026-03-04 (page version 12) |
| Next review | 2027-03-04 |
| Audience | All employees |
The revision table at the bottom records each approved change: version, date, author, a one-line summary and who approved it. Confluence's page history already shows what changed and who edited it, and lets you compare and restore versions. The revision table adds why it changed and who signed off. Policy version control and approvals auditors accept goes deeper into what makes an approval record hold up.
Build a policy register with labels
Add the same label (for example policy) to every policy page. If you put the header block inside a Page Properties macro, a Page Properties Report macro on the register page can collect the owner, status and next review date of every page with that label into one table. That gives you a single list to check at the start of each month.
Tip: Avoid macros inside the policy text that pull in content from other pages, such as an included excerpt. They can change what readers see without creating a new version of the policy page, so the text people read may no longer match the text that was approved.
Managing policies in Confluence day to day
With the structure in place, the routine work is a handful of recurring tasks:
- Changing a policy. The owner edits the page, updates the status to "Changes pending approval", and asks the approver to review that specific page version. Once approved, they add a row to the revision table and set the status back to "Approved".
- Reviewing on schedule. Once a month, someone checks the register for review dates in the next 30 days and nudges the owners. A review with no changes still gets a row in the revision table and an approval date.
- Getting policies read. When a policy is first approved, when a change affects what people must do, and when someone joins, people read and confirm it, and someone tracks who has. Policy acknowledgement tracking for SOC 2 covers how to run this.
- Retiring a policy. Don't delete it. Add a "Retired" status with the date and reason, remove it from the register, and move it under the Retired policies page (or archive it). Its old approvals and read records are still evidence for the time it was in force.
Where manual document control in Confluence breaks down
The setup above works for many small teams, but it depends on people doing the right thing every time. The weak points are predictable.
Status in the page body creates noise
Every update to the Status or Last approved field creates a new page version. The history fills up with bookkeeping edits, and the approved version is no longer the latest even though the policy text did not change.
Approvals are typed, not recorded
"Approved by CTO, 2026-03-04" in a table cell is text anyone with edit access can type or change. Nothing ties it to the version that was actually reviewed, and nothing flags it when someone edits the policy the day after.
Restrictions drift
An owner changes teams and the restriction still names them. Someone removes a restriction to fix a typo and forgets to put it back. Nothing warns you.
Review dates depend on someone remembering
A Page Properties Report shows the review dates people typed in. It doesn't remind anyone, and it can't tell you that a date is wrong because the last approval was never recorded.
Read tracking ends up in a spreadsheet
Confluence has no acknowledgement step, and a page view is not a statement that someone read and accepted a particular version (see Confluence read confirmation for why). Most teams fall back on a form or a spreadsheet, which then has to be matched against the employee list and the current policy version by hand.
The audit trail is spread across tools
Approvals in email, reads in a spreadsheet, permission changes nowhere. Pulling that together for an audit is a project in itself.
Policy management in Confluence with Compliance in a Box
Compliance in a Box is a Confluence Cloud app that adds the missing records to policies that stay ordinary Confluence pages. People still write and edit policy text in the normal editor. The app keeps the status, approvals, review dates and acknowledgements outside the page body, so they never add versions of their own.
- Managed, locked policy pages. The app creates the policy pages in a dedicated compliance space, each with one owner. Only the owner and Compliance Admins can edit a policy page. When an admin changes the owner, the lock moves with it, and if someone removes a restriction by hand, the app's daily check puts it back and records the change in the audit log. (Locking needs Confluence Standard or above.)
- Owners and approvers in one list. Compliance Admins assign each policy's owner and one to ten approvers under Settings, Owners & approvers. The list flags problems such as a policy with no approver.
- Version-bound approvals. The owner selects Submit for approval with a What changed? summary, and every approver approves that exact page version. If the page is edited before they decide, the submission is cancelled. Once approved, an edit doesn't touch the approval: the policy shows Changes pending until the new text is approved too.
- Status on the page. A byline under each policy's title shows its state, such as Approved v7 · 2026-03-01 or Changes pending approval, and people can submit, approve or acknowledge from there.
- Review dates. SOC 2 policies have a 12-month review cadence counted from the latest approval. Policies are flagged Review due 30 days ahead and Overdue after the date, and the owner sees them in My Tasks. When nothing needs to change, Mark as reviewed sends a no-changes review to the approvers. See Periodic reviews.
- Acknowledgements. Each policy has an audience: all employees or specific groups. When a policy that requires acknowledgement is first approved, or a version is approved as a Material change, everyone in the audience is asked to acknowledge that version, with a due date. The app records the version each person acknowledged.
- Importing existing policies. If your policies already live in another Confluence space, Compliance Admins can copy their text into the app's policy pages with an import wizard, or bring them in as custom policies. Imports never carry over approvals: each policy goes through approval as usual, and the wizard warns about anything that won't copy cleanly, such as attachments.
- Retiring custom policies. A custom policy can be retired with a written reason. Nobody is asked to acknowledge or review it any more, and it stays on the Policies tab with a Retired label while its approvals, acknowledgements and history stay as evidence. See Retire a custom policy.
- An audit trail. Every submission, approval, acknowledgement, review and permission change goes into an append-only audit log, and a generated Policy Approval Log page links each approval to the exact page version it covers.
The Policies tab lists every policy with its status, owner, approved version and next review date. The full walkthrough is in Policies and approvals.
Note: The app's SOC 2 policy templates are a starting point, not legal or audit advice. Tailor them to how your company works and have them reviewed by your auditor.
FAQ
Can Confluence be used for document control?
Yes, with discipline. Confluence gives you version history, page restrictions (on Standard and above) and labels. You add the rest: an owner per document, a record of who approved which version, review dates someone checks, and a log of reads and changes.
Should old policies be deleted?
No. A retired policy's approvals and read records are evidence for the period it was in force. Mark it retired with a date and reason, and move or archive the page instead.
How often should policies be reviewed?
Annually is the common expectation, and it is what most policies state. Whatever cadence you write into the policy is the one you will be held to, so pick one you will keep.