Guide · Confluence

Policy acknowledgement evidence for ISO 27001 and SOC 2 audits: what to keep, and how to produce it from Confluence

Attestation Flow for Confluence 3.1.0 is the production version (30 October 2026). Last updated 1 November 2026. On the Atlassian Marketplace.

By Bartosz Stankiewicz, founder, Stanki Guild.

Every information security management system meets the same question sooner or later: prove that staff read the policies. In Confluence this is policy acknowledgement: a record of who confirmed which version of which page, and when. Not "we sent them", not "they are on the intranet": who acknowledged which version of which policy, and when.

This guide is about the evidence itself: what to keep, what a pile of signed PDFs cannot tell you, and how to produce the records from Confluence without a dedicated compliance platform. We make an app for this (disclosed below), but most of this guide works without any app.

The short answer: auditors want a record of who acknowledged which version of which policy and when, not proof that the policy was sent. Practitioners report that a name and a timestamp have been accepted, and a record that names the version and cannot be edited afterwards is stronger. Confirm the expectations with your own auditor.

Expectations are often more modest than software vendors suggest. In an r/grc discussion, practitioners said a name and a timestamp were enough evidence of policy approval for a SOC 2 Type 1 audit (thread). In r/cybersecurity, an ISO 27001 auditor accepted a single acceptable use attestation that referred to the other policies (thread).

Your auditor decides what is enough for you, so treat the following as a sensible minimum, not a guarantee. The records that answer the question:

1. Policy identity and version: name, document ID, version number, effective date.
2. The acknowledgement list for that version: person, date and time, and the version they acknowledged.
3. The outstanding list on a given date: who had not acknowledged yet. "Everyone signed" is more credible when you can also show who was late.
4. The re-acknowledgement cycle: when the policy changed, who was asked again, and when they answered.
5. The method: what people actually saw and clicked, so the acknowledgement means something.

Many companies start with a signed PDF form per person per policy. It struggles with points 2, 3 and 4:

• A signature on a generic form is not tied to a policy version unless the form says which version, and someone checks that it does.
• Finding who has not signed means subtracting signatures from the headcount by hand, every time.
• A policy edit restarts the whole exercise, and nothing tracks who has signed the new version.

The pain is the same wherever policies live. In an r/sysadmin thread on getting a whole company to acknowledge security policies (thread), the recurring problem is not collecting the first signature but keeping the record honest after the policy changes and people join or leave.

Many teams already keep policies in Confluence, and its page history is real: each published edit creates a new numbered version with its author and date. A workflow without any app:

1. One page per policy, in a space with restricted edit rights. The page version is the policy version.
2. A table on the page (or on a child page) where each person adds a row: name, date, "I have read and understood version N".
3. A named owner who, after each published edit, starts a new table for the new version and chases the outstanding names.
4. Before the audit, export the pages to PDF as a point-in-time snapshot, and keep the page history.

This works, and it is honest. The costs: the table can be edited by the people it tracks, the outstanding list is manual arithmetic, and someone must remember to restart it after every edit.

What Confluence cannot do natively is a per-person, per-version receipt that the reader cannot edit. Community answers to this question have said for years that there is no native read confirmation (2023 thread, 2026 thread). Confluence's native approvals, on Premium and Enterprise, let named people approve a page's content; they do not record who read the published page. Marketplace apps fill this gap, ours among them.

If you keep policies in Confluence and want an app for policy acknowledgement, the points to check are the ones in the checklist below: a record bound to the page version, nothing that can rewrite it, a list of who is outstanding and an export for the audit folder. The table shows the annual list price at 10, 50 and 100 users.

Read from the Atlassian Marketplace data on 31 October 2026. Prices are the annual list price in USD for the first year at 10, 50 and 100 users. The rows are the 5 most-installed of the 8 read confirmation and acknowledgement apps for Confluence in our tracked list, ordered by installs; this is not the order of the Marketplace search results, and apps outside our list are not shown. A blank install figure means the data held none. Star ratings are left out on purpose: the star field in the Marketplace data does not always match the rating shown on the listing, so open the listing for the current rating.

The Marketplace data does not say which of these apps meets each point, so check each listing against the checklist. Attestation Flow is ours and is the last row.

• Every policy has a page with a version number and effective date.
• An acknowledgement record exists per person per version, with date and time.
• You can produce the outstanding list for a past date.
• Re-acknowledgement after each policy change is tracked, not assumed.
• New starters get the policy set on day one, and the record shows it.
• Leavers drop off the outstanding lists, and erasure requests have a defined path.
• Export works on demand: CSV or similar, per space.
• Someone has tested that a record cannot be edited or backdated.

Attestation Flow is our Confluence app. You name the required readers on a page; each one clicks I have read and understood, and the app stores a write-once receipt with their account, the page, the page version and the time. When the page is edited, readers are asked again, and the earlier receipts stay as history. Each page also keeps a SHA-256 hash-chained log of every acknowledgement and change, so a changed or removed entry shows up when the chain is checked. These work in every edition; without an active paid licence, one page per space can carry a requirement.

With a paid licence: Confluence groups as readers, a re-acknowledgement window of 30 to 730 days, questions before confirming, a minimum reading time, reminder page comments that mention outstanding readers, and the compliance report per space or across all spaces with CSV, Excel and PDF export, a per-person record and an evidence export. The 16 policy pack templates include an information security policy (ISO 27001) and a code of conduct (SOC 2). Attestation Flow is free for up to 10 users with every feature, then from USD 0.75 per user per month for the first 100 users. See the documentation and the comparison with other apps.

What it is not: a legally binding electronic signature. We make no claim of 21 CFR Part 11 compliance, and the app does not decide whether its records satisfy a particular control; that judgement is yours and your auditor's.

Which Confluence apps handle policy acknowledgement?

The table above lists the read confirmation and acknowledgement apps in our tracked list, with their annual list prices. The Marketplace data does not say which of them records the page version, so check each listing against the checklist. Attestation Flow is ours.

Is a click-through acknowledgement valid evidence?

Practitioners report that a name and a timestamp have been accepted for SOC 2 Type 1 and ISO 27001 audits (see the threads linked above). What makes it stronger is that the record names the policy version and cannot be edited afterwards. Confirm the expectations with your own auditor.

How long should we keep acknowledgement records?

At least as long as your audit cycle and your retention rule for the policy documents themselves. If you re-acknowledge annually, keeping the full history per version is the safe default.

What about staff without Confluence access?

Named readers need accounts that can open the page. For contractors or staff without access, either give them limited Confluence access or run a parallel process and keep its record alongside; a mixed record is better than an incomplete one.

Do people have to re-acknowledge after every small edit?

With version-bound records, every published version asks again. Some teams batch editorial fixes into planned releases of the policy to avoid this; others accept the re-ask. Decide the rule once and write it into the policy.

• Attestation Flow for Confluence documentation
• Confluence policy templates
• Attestation Flow compared with other Confluence apps
• Read and understood in Confluence: how to get proof, not just page views
• Confluence policy: owner, review date and next review
• ISO 9001 documented information: showing a review in Confluence
• ISO 27001 awareness for staff: how to run a quiz, and keep the evidence
• Policy acknowledgement nudges in Slack and Microsoft Teams with Confluence Automation
• Comala Document Management alternative for Confluence: when Attestation Flow fits and when it does not
• When is "everyone has read it" actually true? Testing read and understood in Confluence