Track policy acknowledgements without a spreadsheet

Most teams start tracking policy acknowledgements in a spreadsheet. One row per person, one column per policy, a date in each cell when someone says they have read it. It works for the first round. It tends to fall apart the second time an auditor, insurer or new compliance requirement asks the same question.

This post covers what the record actually needs to hold, where a spreadsheet struggles to hold it, and what to do instead.

Why the record matters

Several frameworks ask for acknowledgement explicitly, and some ask for it on a schedule:

• ISO/IEC 27001:2022, Annex A control 5.1, asks that information security policies be "communicated to and acknowledged by relevant personnel and relevant interested parties", and reviewed at planned intervals or when significant changes occur. The standard itself is paid for; the control text is reproduced by Cloudaware's framework reference and summarised by ISMS.online.
• PCI DSS v4.0.1, requirement 12.6.3, says personnel "acknowledge at least once every 12 months that they have read and understood the information security policy and procedures" (requirement text as reproduced by Cloudaware; the official standard is in the PCI SSC document library).
• California employers must distribute a harassment, discrimination and retaliation prevention policy, and the regulation lists acknowledgement forms and "a tracking system ensuring all employees have read and acknowledged receipt" among the accepted methods (2 CCR § 11023(c)).

Even where nothing names acknowledgement directly, retention rules apply to the paperwork around policies. HIPAA's Security Rule, for example, requires covered entities to keep required documentation "for 6 years from the date of its creation or the date when it last was in effect, whichever is later" (45 CFR § 164.316(b)(2)(i)).

So the question is rarely "did people read it?" in the abstract. It is "show me, for this person, this version, on this date".

What each record needs

A useful acknowledgement record answers five questions without anyone having to remember the answer:

1. Who acknowledged: a named person, not a team.
2. Which document, and which version of it. A policy that changed in March and was acknowledged in January is not covered by that January tick.
3. When, recorded by a system rather than typed in by hand.
4. How: something that ties the acknowledgement to the person, such as their own account, plus technical context like the IP address and browser.
5. Whether it is still current, given how often the policy must be re-acknowledged.

Where the spreadsheet struggles

None of this is impossible in a spreadsheet. It is just manual, and manual is where the gaps come from.

• Dates are typed, not recorded. Someone copies a date from an email reply into a cell. Nothing shows who did it or whether it matches the email.
• Versions get lost. One column per policy has nowhere obvious to say which revision a person read. When the policy changes, the old ticks still look green.
• Chasing lives somewhere else. The sheet shows who is missing; the reminders go out from someone's inbox, by hand, every time.
• Renewal is a calendar entry. An annual requirement such as PCI DSS 12.6.3 means clearing the column, or adding a new one, every year, and remembering to.
• New starters slip through. A person added to the sheet in week three is easy to miss, and a person never added is invisible.

What to do instead

Whatever tool you choose, look for these properties:

• The person acknowledges in their own name, through their own login or a link tied to them.
• The timestamp is set by the system at the moment of acknowledgement.
• Each acknowledgement is tied to a document version, and changing the document can ask everyone again.
• Re-acknowledgement on a schedule happens without someone rebuilding the tracker.
• People who have not acknowledged are reminded automatically.
• The whole history exports in a format an auditor can open.

How Listor handles it

Listor is built around exactly this record. The policy stays where it already lives (a Notion page, a Google Drive PDF, an intranet page); Listor holds its title and link.

• Assignment. You target a document at people or groups. Every member of a workspace joins its All Employees group automatically, so a document targeted there appears on a new starter's reading list as soon as they join.
• The acknowledgement. The person opens the document from their reading list, reads it, and confirms "I've read this" in Listor. The confirmation is dated server-side and stored with their IP address and user-agent. Opening the link is recorded separately.
• Versions. When a policy changes, an admin can declare a revision label (for example "v3.1") and force re-attestation, which emails everyone targeted. Earlier acknowledgements stay on the record against the earlier revision.
• Renewals. Each document can carry a renewal interval in months. When someone's acknowledgement passes that interval, Listor emails them to re-attest.
• Questions. "I need help" in the same dialog sends the person's question to the document's owner, so "I didn't understand section 4" becomes a conversation rather than a blind tick.
• Evidence. The audit log exports as CSV or JSON, one row per event, with the person, document, revision, IP address and user-agent.

Renewals, forced re-attestation and help requests are on the paid plan. Listor is free for up to 10 assigned people and five documents, then $2 per user per month.

A short checklist

• Every policy that needs acknowledging has a named owner.
• Each one is targeted at the right group, and new starters are in that group from day one.
• Each one has a renewal interval that matches the strictest requirement that applies to it (12 months, in the PCI DSS case above).
• When a policy changes, everyone is asked again, and the version is recorded.
• You can export the record for a date range without editing it first.