Most teams keep their policies in Confluence. Then an audit arrives - ISO 27001, SOC 2, a customer security review - and the question is not "where is the policy". It is "show me that the people who had to read it, read it, and show me the ones who did not."
That second half is where Confluence on its own runs out.
I work on a Marketplace app in this space, so treat the last section accordingly. The first three sections are the part I would want to read if I were choosing, and they apply whichever app you end up with, including none.
What Confluence gives you, and where it stops
Page analytics tell you how many people viewed a page and who. That sounds like the answer and is not, for three reasons.
A view is not an acknowledgement. Opening a tab is not a statement that someone read and understood a policy, and no auditor treats it as one.
There is no denominator. Analytics tell you who came. They cannot tell you who was supposed to come and did not, because Confluence does not know who the policy applied to.
Nothing is tied to a version. If the policy changed in March, a view recorded in January is evidence about a document that no longer exists.
Mentions, task lists and a comment saying "read it" all fail the same way: they are not structured, and nobody can extract them into an audit file six months later.
The three things that actually matter
If you are evaluating any app in this category, these are the three I would test first, because they are the ones an auditor pushes on.
1. The denominator. The useful output is not the list of people who confirmed. It is the list of people who have not. That requires the app to know the intended audience - usually a group - and to be able to say "nine of twelve, and here are the three." Ask what happens when the group is large, and what the app shows if it could only read part of it. A partial read that is presented as a complete answer is worse than no answer, because you will act on it.
2. Version locking. Policies change. When they do, previous acknowledgements should not silently become evidence for the new text, and they should not be deleted either. The honest behaviour is: the new version starts a new round, and the old round stays on record exactly as it was given. Ask to see what the record looks like after two rounds.
3. What the export contains. At some point someone will ask for a file. Check that it includes people who have left the group, rounds that are no longer current, and the version each confirmation belongs to. An export of only the current state is not an audit trail.
What to check before you install anything
Two things that are easy to check and rarely checked.
Permissions. Open the Permissions tab on any Marketplace listing and read it. An app in this category needs to read pages, users and groups, and to store its own records. If it asks to write to your Confluence content, to act on behalf of a user, or to read email addresses, ask why. For a compliance tool, the permissions it does not request are part of the product.
Where the records live. Forge apps can store data inside your own Atlassian site. Others send it to a vendor's server. Both can be fine, but you should know which one you are choosing before the DPA conversation, not during it.
Disclosure
I am the developer of Confirm & Chase, a Forge app for Confluence that does what this article describes: a confirmation button on the page, a group as the audience, a site-wide view of every policy with the outstanding names, a new round when the policy version changes with earlier rounds kept, and a CSV export that includes them.
https://marketplace.atlassian.com/apps/948129892
It is free for sites up to ten users. It runs entirely on Forge, so the records stay in your own Atlassian site, and it has no permission to write to your content.
If you are using something else in this category, the three tests above are still the ones I would run. I would rather you ran them and chose a competitor than installed anything on the strength of a listing page.
