Sample — not real evidence
Every record below is fictional. The files were produced by Policyflow's own evidence export, run against invented data for a company that does not exist. They are not evidence about any organisation and not an audit result.
A sample evidence pack, generated by the real export.
The point of a sample is to let you judge the output before you commit an afternoon to it. This one comes out of the same code path a customer runs, so what you inspect here is what the product actually produces — not a mock-up drawn to look convincing.
The fictional campaign in this pack
- Workspace
- SAMPLE — Northwind Instruments (fictional)
- Campaign
- SAMPLE — Information Security Policy acknowledgement (Q1 review)
- Policy version
- SAMPLE — Information Security Policy — version 3 (policy_version_id 5a11e000-0000-4000-8000-00000000d003)
- Recipients
- 8 in scope — 5 acknowledged, 3 outstanding
- Export date shown
- February 20, 2026
Download the three files
Each file is labelled as a sample in its own contents, not only by its filename — so a copy that gets forwarded on cannot be mistaken for a real export.
- Campaign summary (PDF)
The readable overview: counts, response rate, who signed with timestamps, and who is still outstanding.
- Evidence log (CSV)
One row per recipient: the policy version they were sent, whether they confirmed, when, and — where they have not — why not.
- Pack notes (TXT)
What the pack contains, file checksums, and a plain statement of what these records do and do not prove.
The pack notes list a SHA-256 checksum for each file. The pack is regenerated deterministically, so those checksums stay stable and can be used to confirm a copy has not been altered.
What is deliberately shown as incomplete
5 of 8 recipients have acknowledged. The other 3 are outstanding for three different reasons, because an evidence pack in which everyone has already confirmed is not what a real campaign looks like mid-flight:
- One recipient opened the link and did not confirm — recorded as viewed, which is not the same as never having received it.
- One was reminded three times and then escalated, first to their manager and then to the ISMS owner.
- One has an approved exception with a compensating control and an expiry date, rather than being dropped from the list.
The columns worth understanding
The CSV has one row per recipient and a wide header. These are the columns that carry the argument:
- policy_version_id
- The exact published version the recipient was sent. It never changes after the campaign is activated, so a later edit to the policy cannot move this acknowledgement onto different text.
- policy_hash
- A content hash of that version's bytes, taken at the moment of confirmation. If the stored version were altered, the hash would no longer match it.
- recipient_status
- Where this person got to: attested, viewed (opened, not confirmed), email_sent (delivered, not opened), or removed (no longer in scope).
- attested_at
- Server timestamp of the confirmation, in UTC. Empty for anyone who has not confirmed.
- attestation_id
- The acknowledgement record itself. One per recipient per version — confirming twice does not create a second one.
- reminder_count
- How many reminders this person was sent. Reminders go only to people who have not confirmed.
- manager_escalated_at / admin_escalated_at
- When an overdue case was escalated, and to whom. This is how an outstanding recipient shows as chased rather than forgotten.
- exception_status and its reason / compensating_control
- A recipient who was formally excused, why, what was put in place instead, and when it expires. Recorded rather than quietly dropped from the list.
- evidence_row_sha256
- A hash of the row's own values, so a single altered cell is detectable without re-exporting.
What this pack does not prove
- That anyone read or understood the policy. An acknowledgement is a recorded act of confirmation, nothing more.
- That anyone complied with the policy afterwards.
- That a certification body would accept these records as sufficient. That is the auditor's judgement, against your own ISMS scope — and Policyflow makes no claim about the outcome.
The auditor walkthrough sets out those limits in the terms an auditor would put them.
Produce one of your own
The fastest way to judge this properly is on a policy you recognise, sent to three people you know. The first-campaign checklist walks through it.