What a Confluence read confirmation has to prove
A Confluence read confirmation is a record that a named person read a specific page and accepted what it says. People ask for one in many situations: an auditor sampling whether employees accepted the security policies, HR checking that new hires went through the handbook, a facilities lead who needs everyone on site to confirm a new safety procedure, or a manager rolling out a changed expense rule.
The question behind all of them is the same: can you show, for each person who should have read this page, that they did, which text they saw and when? Notice what that question doesn't ask. It doesn't ask whether the page is popular, or whether people engaged with it. It asks about specific people, a specific version and an explicit act of acceptance. That is where most quick fixes fall short.
Read receipts in Confluence: what the built-in signals tell you
Confluence Cloud gives you several signals around a page. Each is useful for something, but none of them is a read receipt in the sense an auditor or HR team means.
| Signal | What it tells you | Why it isn't a read confirmation |
|---|---|---|
| Page views and analytics | That the page was opened, and depending on your Confluence plan, possibly by whom | Opening a page isn't reading it or accepting it. Views aren't tied to a page version, and what you can see varies by plan. |
| Likes | That someone wanted to show approval or appreciation | Optional and informal. Nobody is asked to like a page, and a like doesn't say which version it was for. |
| Comments | That someone had something to say | Comments stay on the page as it changes, so a comment written against last year's text sits under this year's. |
| Watching | That someone gets notified when the page changes | Watching is a notification setting. It says nothing about whether the person read the page. |
The common gap is the version. Confluence keeps a full page history, which is good, but none of these signals is bound to a particular version in that history. If the page was edited after someone viewed or liked it, you can't tell from the signal alone which text they saw.
Ways to confirm employees read a Confluence page, and where they break
Teams that need real confirmations usually reach for one of these. They all work for a while.
Ask people to comment "I have read this"
Easy to set up, and every comment carries a name and a date. But a long comment thread is hard to turn into a completion list, nothing tells you who hasn't commented, and the comments don't record which version of the page the person read. Once the page is edited, every earlier comment becomes ambiguous.
Assign an inline task to each person
Confluence tasks can be assigned to people with a mention, and the assignee is notified. That makes this a better option than comments: you get a checkbox per person and a clear outstanding list. The weaknesses show up later. You have to build the list of names by hand, new joiners only get a task if someone remembers to add one, and ticking a task still doesn't record which version of the page was on screen. Adding the tasks is itself a page edit, so it creates new versions of the very page people are confirming.
Use an online form
A form linked from the page collects a name, a date and a checkbox. Identity is often whatever the person types, the form rarely captures the page version, and working out who is missing means comparing responses against a staff list by hand.
Keep a spreadsheet
Someone collects confirmations by message or email and records them in a sheet. It is flexible and free, but every row is hand-entered, anyone with access can change it, and the version column is the first one people stop filling in.
The four problems they share
- The version isn't recorded. You know someone confirmed "the page", not which text.
- Edits after confirmation go unnoticed. If the page changes in a way that matters, nothing tells you that earlier confirmations no longer cover the current text.
- New joiners are missed. The list of who should confirm is fixed on the day you sent the request. People hired or moved into the team later are invisible.
- Chasing is manual. Someone has to work out who is outstanding and message them, again and again.
What a good Confluence acknowledgement record holds
Whatever tool you use, a read confirmation you can defend answers these questions without anyone having to remember the context:
- Who. A stable identity, such as the person's Atlassian account, not a name typed into a box.
- Which page and which version. The page version number at minimum. Better still, something that proves the content of that version, so a later edit can't be mistaken for it.
- When. A timestamp you can compare with the date the version was published and with the person's start date.
- That they accepted it. An explicit action, such as ticking "I have read and understand this", not a side effect like opening the page.
- Who was supposed to. The audience for that version: everyone, or a named group. Without it, you can't say who is missing.
- Completion per audience. Required, done, outstanding and overdue, per page and version.
Two rules of practice sit on top of the record. First, decide in advance which edits require people to confirm again: a changed rule does, a fixed typo doesn't. Second, keep the history. When a new round of confirmations starts, the old records should stay, because they show what people accepted at the time. The policy acknowledgement tracking guide goes deeper on what SOC 2 auditors look for, and policy version control and approvals covers how to fix the version people should be confirming in the first place.
If you run read confirmations by hand
If you only have a few pages and a small team, a manual process can be good enough. These habits close most of the gaps above:
- Freeze the version first. Finish editing, note the page version number from the page history, and only then ask for confirmations.
- Put the version in the request. "Please confirm you have read version 12 of the travel safety procedure" makes every confirmation version-specific.
- Keep the audience list separate. Write down who must confirm (a group, a team, everyone on site) and check it against your joiners every week or month.
- Set a due date. Without one, "outstanding" never becomes "overdue", and nobody knows when to chase.
- Record edits that matter. When the page changes in a way that affects what people must do, start a new round and keep the old records.
Important: if you collect confirmations as tasks on the page itself, adding them is an edit that creates a new page version. Note which version holds the content people are confirming, so it stays identifiable in the page history.
Read confirmations on policy pages with Compliance in a Box
Compliance in a Box is a Confluence Cloud app that runs a SOC 2 compliance program in one Confluence space. Acknowledgements work on the policy pages the app manages in that space, and each one records the person, the approved version and the time. The policy acknowledgements chapter of the user guide has the full detail.
Click-through on the page or in My Tasks
When a policy page has something waiting for you, its byline (the Compliance in a Box item just under the page title) reads Please acknowledge. The same request appears in My Tasks in the app, with a link to the exact approved version and its due date. You read that version, select I have read and understand this policy and click Acknowledge. Afterwards the byline shows You acknowledged while the page matches the approved version, and the acknowledgement is listed under My history. See the byline on a policy page.
Bound to the approved version
People always acknowledge the approved version of a policy, not whatever is on the page right now. The app records the Confluence page version and a fingerprint of its content. If the page has edits that aren't approved yet, the panel points people to the approved version instead. If a newer version is approved while someone is reading, their click is refused and they are asked to read the new one.
Audiences, joiners and leavers
Each policy's audience is All employees (the default) or Specific groups picked from your Confluence groups. Once a day the app compares each open campaign with the current audience: people who joined are asked, due 30 days from that day, and people who left before acknowledging show as Left the audience. Acknowledgements already given are never removed.
Campaigns on material change
An acknowledgement campaign opens when a policy is first approved, and again each time a later version is approved as a material change. The policy owner decides with the Material change checkbox when submitting. A minor change, such as a typo fix, opens no campaign, and existing acknowledgements still count. Everyone in a campaign has 30 days, and earlier campaigns stay on record.
Reminders as Confluence tasks
Reminders are ordinary Confluence tasks on each person's private compliance tasks page, so Confluence notifies them through its own notifications. For acknowledgements, people are reminded when they are first asked, 3 days before the due date, then once a week after it (up to 4 times). Compliance Admins can also click Remind for everyone outstanding on a policy, or for one person. See how reminders work.
Tracking and reporting
Compliance Admins see progress on the Acknowledgements tab, by policy (audience, version, due date, outstanding and overdue counts) or by employee. Policy owners see the percentage for their own policies. For an auditor, the app generates a Policy Acknowledgement Report as Confluence pages, listing every person asked, their status, when they acknowledged and which page version.
The SOC 2 policy set comes with acknowledgement already switched on for the policies everyone should read. If you have a handbook page or procedure elsewhere in Confluence that works as a policy employees must accept, a Compliance Admin can bring it in as a custom policy with the import wizard, which has an Employees must acknowledge it once approved option, ticked by default. For owners, approvals and reviews of those pages, see Confluence policy management, and for how the rest of the program fits together, see running a SOC 2 program in Confluence.
FAQ
Does Confluence have read receipts?
Not in the sense of a recorded acceptance of a specific page version. Depending on your plan, Confluence can show that a page was viewed and sometimes by whom, but a view isn't proof of reading or agreement. For that you need an explicit confirmation step.
Is a click-through confirmation enough?
For most internal purposes, including SOC 2, a click-through that reliably records the person, the version and the time is generally accepted. No signature is required by SOC 2 itself. If an auditor or regulator is involved, confirm what evidence they expect early.
What should happen when the page is edited after people confirm?
Decide whether the edit matters. If it changes what people must do, ask them to confirm the new version and keep the old confirmations. If it is a typo or formatting fix, the existing confirmations can stand. Write the rule down so the decision is consistent.
How do I make sure new hires confirm the page?
Tie the request to an audience, such as a group, rather than a fixed list of names, and check that audience regularly for people who joined after the request went out. A system that does this check automatically removes the most common gap.