Reading a Policyflow evidence export.
Written to be handed to whoever is reviewing the records — an internal auditor, an external assessor, or the colleague who has to answer for them. It covers what the export records, how versions relate to acknowledgements, and where the evidence stops. The last part is the one worth reading twice.
To follow along with a concrete file, open the sample evidence log — fictional data, produced by the real export. The pack page explains each column.
How versions relate to acknowledgements
This is the relationship the whole export rests on, so it is worth being precise about it.
A policy is a container with a title and an owner. It changes over time. A policy version is an immutable snapshot of the text, created when the policy is published, with its own identifier. A campaign is bound to one specific version at the moment it is activated. An acknowledgement is recorded against that same version, not against the policy.
Three consequences follow, and they are the ones an assessor tends to test:
- Editing a policy after a campaign has been sent does not change what anyone acknowledged. The new text becomes a new version; the existing acknowledgements stay bound to the old one.
- A new version does not retroactively invalidate earlier acknowledgements — nor does it silently satisfy the new one. Getting acknowledgements for a new version means distributing it, which is a new campaign with its own records.
- An acknowledgement can therefore be current or superseded, and the export lets you tell which: compare the policy_version_id on the row against the policy's current version.
What the evidence records
Five assertions the export can support, and the record behind each:
- This person was given this exact text.
- The recipient row names a policy_version_id. That version is an immutable snapshot created when the policy was published; the campaign is bound to it at activation and cannot be repointed afterwards.
- The text has not been altered since.
- Each acknowledgement stores a content hash of the version, computed from the version's own bytes at the moment of confirmation. Re-hashing the stored version reproduces it. A change to the stored content would not.
- This person actively confirmed it, at this time.
- The acknowledgement row carries a server-side timestamp in UTC, the recipient identity, and the request's IP address and user agent. Confirmation is an explicit action by the recipient — nothing is pre-ticked and nothing is inferred from opening an email.
- These people have not confirmed, and here is what was done about it.
- Every recipient in scope appears in the export, confirmed or not, with their delivery state, how many reminders they were sent, and any escalation to a manager or administrator with its date.
- This person was formally excused, on this basis.
- An exception row records the reason, the compensating control, who decided it and when, and when it expires. An excused recipient stays visible in the export rather than disappearing from the denominator.
Integrity of the export itself
Two mechanisms, both worth knowing about before you rely on the file in front of you:
- Each row in the CSV carries a evidence_row_sha256 over its own values, so a single edited cell is detectable without going back to the source system.
- Every successful export is itself recorded in the workspace, with the exporting administrator, the timestamp, the acknowledgement count, and a SHA-256 of the whole file. A file can therefore be checked against the export it claims to be. That record is written by the server, not by the user requesting the export.
Neither mechanism makes the file tamper-proof in the hands of someone determined to forge it — a re-hash would match a fully reconstructed file. They make undetected partial edits impractical, which is the realistic threat.
What the evidence does not prove
Overstating what an acknowledgement record shows is the fastest way to lose credibility in a review. So, plainly:
- That the person read the policy.
- The record shows the version was opened in the browser and confirmed. It does not measure reading, attention, or time on page — and a claim built on those would not survive scrutiny anyway.
- That the person understood the policy.
- Comprehension is not something an acknowledgement can evidence. Where understanding matters, it needs its own control — training with assessment, for example — and its own evidence.
- That the person complied with the policy afterwards.
- Acknowledgement records communication, not behaviour. Compliance with the policy's requirements is evidenced by the controls the policy mandates, not by this export.
- That the acknowledgement was made by that person and nobody else.
- A link-based confirmation evidences that someone holding that recipient's unique link confirmed it, from a recorded IP address, at a recorded time. Where a campaign is sent to people who also hold Policyflow accounts, the signed-in identity is recorded too. Neither is a legal identity proof, and the export does not claim to be one.
- That the scope of the campaign was correct.
- The export shows who was in scope, not whether that was the right set of people. Deciding who must acknowledge a given policy is an ISMS judgement and sits with the organisation.
- That any of this is sufficient for certification.
- ISO 27001 prescribes no acknowledgement tool or format. What is adequate depends on the organisation's scope, risks, and controls, and the judgement belongs to the auditor and the certification body. Policyflow is not a certification service and makes no claim about the outcome of any audit.
How to present it
The summary PDF is the readable overview: what was distributed, to how many people, how many confirmed, and who is outstanding. The CSV is the detail behind it, one row per recipient. Hand over both, and describe the evidence as what it is — a record that named people were given a specific version of a policy and actively confirmed it, with the outstanding cases and their handling shown alongside.
Where a control requires more than communication — understanding, or compliance with the policy's requirements — say so, and point at the evidence for that control instead. An acknowledgement export offered as proof of compliance invites exactly the challenge it cannot answer.
Produce an export of your own
One policy, a few recipients, one export. The first-campaign checklist is the shortest path to having a real file to read.