SOC 2 policy acknowledgement
Your SOC 2 audit is coming and you need to show who acknowledged which version.
Not who received an email once. Not the current PDF on the intranet. The specific version each named person confirmed, when they confirmed it, and who has not confirmed yet. Policyflow produces that record as a by-product of sending the policy, and exports it when you are asked for it.
Free for up to 15 employees, no card and no time limit. Then Core from €55/mo billed annually. The sample pack needs no account.
What usually goes wrong before an audit
Most teams have the policies. What they cannot assemble quickly is the proof that the right people confirmed the right version. The gaps are consistent:
- The confirmation is not tied to a version. A signature sheet from March says someone signed “the Information Security Policy”. The policy has been edited twice since, and nothing records which text they saw.
- There is no reliable timestamp. A reply in a mailbox, a tick in a spreadsheet, a name on a printout — each is a claim about when, not a record of it.
- The outstanding list is the hard part. Who is still missing, how many times they were chased, and whether anyone approved an exception. That question takes an afternoon of cross-referencing.
- Leavers and joiners break the denominator. “12 of 14 confirmed” means nothing if the 14 was taken from a headcount export that has since changed.
The workflow, and the record each step leaves
Six steps. You do the first three; the last three mostly happen on their own. Every row in the evidence export traces back to one of them.
| Step | What happens | What is recorded |
|---|---|---|
| Publish the version | Approve and publish the policy. The published version is frozen and gets its own identifier. | policy_version_id, plus an evidence hash bound to the published snapshot and, for PDFs, the exact file bytes |
| Choose who is in scope | Pick directory groups, or paste addresses. Duplicates across both are merged into one recipient. | One recipient row per person, each with its own link |
| Send the campaign | Activating the campaign sends each recipient a link to that version — no login required. | Activation timestamp, per-recipient send and delivery state |
| Recipients confirm | The recipient reads the version in the browser and confirms it. Nothing is pre-ticked. | Acknowledgement bound to that version id, with timestamp, IP, and user agent |
| Chase what is missing | Reminders go only to people who have not confirmed. Overdue cases escalate to a manager. | Reminder count, escalation stage and target, per recipient |
| Export the evidence | Export a summary PDF and a per-recipient CSV whenever the evidence is asked for. | The export itself is recorded, with a checksum of the file |
Look at the output before you sign up
The sample pack is generated by the product's own export code using invented data for a fictional company. Every file is labelled as a sample. It shows five acknowledgements and three outstanding recipients, because that is what a mid-campaign export actually looks like. The files are the same sample set used on the ISO 27001 page.
- 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.
Read the pack notes first. They explain what each column means and what the records do not prove.
Your first campaign, guided
The point of the first campaign is not to cover the whole organisation. It is to produce one real evidence export you can look at, end to end, on a policy that matters. Six steps: choose a policy, publish it, select recipients, send, review progress, export. A small first audience — one team, or three people — gets you there in an afternoon.
What Policyflow does not do
SOC 2 does not name a specific acknowledgement tool. What is appropriate depends on your controls, scope, and how you describe them to the auditor. So it is worth being exact about the limits:
- It does not make an organisation SOC 2 ready on its own, and it is not a SOC 2 audit or attestation service.
- It is not a full GRC platform. It does not map Trust Services Criteria, run control testing, or replace your auditor.
- It does not guarantee that an auditor will accept these records. Sufficiency is their judgement, against your control environment.
- It does not show that anyone read or understood a policy — only that a named person was sent a specific version and actively confirmed it.
- It does not show that anyone complied with the policy afterwards.
What it does is the repeatable operational work: versioning, approvals, distribution, acknowledgements, reminders, and evidence exports.
Common questions
Which policies should be acknowledged?
What happens to old evidence when a policy changes?
Do recipients need an account?
Does this only work for SOC 2?
One next step
Publish one policy, send it to a handful of people, and export the evidence. If the export is not something you would be comfortable putting in front of an auditor, you will know within the hour.
Free for up to 15 employees, no card and no time limit. Then Core from €55/mo billed annually.