Paperlatch
Guide · Checked against Atlassian's documentation on 20 October 2026
A policy attestation is a person's recorded statement that they have read a policy and will follow it. Both ISO 27001 and SOC 2 audits tend to ask for it, for a simple reason: a policy nobody has seen does not control anything.
This article summarises common practice. Your auditor's request list is the authority for your audit — read it first.
Annex A control 5.1, Policies for information security, is widely summarised as requiring that policies be defined, approved by management, published, communicated to and acknowledged by relevant personnel and relevant interested parties, and reviewed at planned intervals and when significant changes occur.
We have not checked this against the official text, which is in the standard itself and is paid; the summary above is how practitioners describe it (for example High Table and TCSA). If you hold a copy of ISO/IEC 27001:2022 or 27002:2022, read control 5.1 there.
If that summary is right, two words in it are worth thinking about when you plan your evidence:
Control 6.3, Information security awareness, education and training, is related: policies are expected to be part of the awareness programme.
SOC 2 reports are built on the AICPA Trust Services Criteria, and the criteria describe outcomes, not forms. Nothing below is a requirement quoted from them.
What practitioner guides describe is a common practice: policy and code of conduct acknowledgements are often used as evidence for the control environment criteria (CC1.1, commitment to integrity and ethical values) and internal communication (CC2.2), typically collected at hire and annually after that (for example Creately's SOC 2 code of conduct process and Watchdog Security on CC1.1). Guides differ on the details — some describe only annual signing.
Whether your auditor tests acknowledgements at all, and on what cadence, is set by your own controls and your auditor's request list (often called the PBC list). Check it before building a process.
Whatever the framework, the same questions come up when an auditor samples a policy:
| Question the auditor asks | Field you need |
|---|---|
| Who acknowledged it? | A named person |
| Which version did they acknowledge? | The document version at the time |
| When? | A system timestamp |
| Who was required to? | The audience — to show coverage, not just a list of names |
| What happened when the policy changed? | A new round, with the earlier one kept |
A common gap: a list of names with no audience. It proves that some people acknowledged, but not that everyone who should have did — and coverage is usually what gets sampled.
Many teams already keep their ISMS policies in Confluence. Confluence has no built-in acknowledgement step, and page view analytics are not an attestation (why). The options are a manual table on each page, an external form linked from the page, or a Marketplace app.
We make Confirm & Chase for this. You add a confirmation button to each policy page and pick the group that must confirm. One dashboard shows who confirmed and who is outstanding across every space, which is the coverage view an auditor samples. When a policy changes, a new round starts and the earlier round stays on record. The CSV export contains page, policy version, round, audience, person, status and timestamp.
It runs on Atlassian Forge with read-only access to your content, so it adds no new place where your policy text is stored. Free for up to 10 users.
Paperlatch makes Confirm & Chase. Using it does not make you compliant with ISO 27001 or SOC 2 — it produces one kind of evidence those audits ask for.