Annual Policy Review Checklist Template

The first task sets the approval deadline, names the coordinator and the approving authority, and records which frameworks apply.

• Open the cycle and name the coordinator and approving authority — record the approval deadline and the frameworks the library must satisfy
• Load the policy register into one table — title, reference, owner, approving body, version, last approval, next review date, audience and linked framework
• Confirm a current owner for every policy — reassign anything owned by a leaver or a role that no longer exists before the review starts
• Sweep for policies outside the register — check the intranet, shared drives, the staff handbook and team wikis; register them or retire them
• Set the review depth for each policy — full rewrite, light review or confirm no change, based on risk, age and the triggers logged against it

Due dates in this phase run back from the approval deadline set in Phase 1.

• List the triggers since each policy was last approved — law changes, incidents, audit findings, complaints, restructures and new systems, with dates
• Pull audit findings and the exception log for each policy — repeated exceptions mean either the policy or the practice is wrong
• Ask legal or compliance for the year’s regulatory changes — a dated list showing which policies each change touches
• Compare each policy with the procedures beneath it — a policy promising quarterly checks over a procedure that runs them yearly is a finding waiting to happen
• Send each owner a review pack and a deadline — the current version, the trigger list, relevant findings and the redline rules

The last task asks whether the review found a material change. A Yes shows the legal check, consultation and re-attestation tasks in Phases 4 and 5.

• Owners review each policy against triggers and current practice — record No change, Minor edit or Material change in the register
• Mark every change in a tracked redline — never overwrite the approved text; add a one-line summary of each change for approvers and staff
• Correct names, roles, systems and links — job titles, team names, mailboxes and cross-references go out of date first
• Keep mandatory wording to what you can enforce — use ‘must’ only where someone monitors it; move aspirations to guidance
• Decide whether the review found a material change — new or removed obligations, scope, responsibilities or risk appetite; wording fixes are not material

The first two tasks appear only after a material change. The approval is assigned to the approving authority named in Phase 1, and the checklist waits for the decision.

• Legal or compliance checks each materially changed policy — confirms it reflects current law and contracts and promises nothing you cannot deliver
• Consult the people the change affects — HR for employment terms, information security, finance, and employee representatives where local law or agreements require it
• Prepare the approval pack — every policy with its outcome and change summary, plus redlines for the material changes
• Approving authority approves the reviewed library — checks the pack, then records Approved or Not approved with any conditions
• Record board or committee approval for reserved policies — attach the minute reference for policies only the board may approve, such as the code of conduct
• Assign version numbers and effective dates — a new version for every changed policy, and a new approval date for those confirmed unchanged

Re-attestation appears after a material change. The PCI DSS task appears when PCI DSS is among the Phase 1 frameworks, because that acknowledgement is due every 12 months regardless.

• Publish the approved versions in one place — the location staff are told to use, with version, owner, approval date and next review on each cover
• Withdraw superseded copies wherever they were copied — intranet pages, shared drives, onboarding packs and supplier portals; archive rather than delete
• Tell staff what changed, not just that something did — a short summary per material change, sent to the people it affects
• Collect re-attestations for materially changed policies — from the population each policy applies to; chase stragglers through their managers
• PCI DSS: collect the 12-month security policy acknowledgements — Requirement 12.6.3 needs personnel to confirm they have read and understood it at least once every 12 months
• Update training and guidance that quotes the policies — induction slides, e-learning, manager guides and customer-facing summaries

The annual schedule starts next year’s checklist on the same date.

• Retire policies that are no longer needed — the approving authority agrees the retirement, and the last version is archived for its retention period
• Update the register with versions, dates and owners — the register is the index auditors sample from, so it must match what is published
• Log follow-up actions with owners and dates — procedure rewrites, training changes and exceptions the review uncovered
• Set each policy’s next review date — annual by default, sooner for high-risk policies, and passed to the compliance calendar
• Report the cycle to the approving authority — policies reviewed, changed, retired and overdue, plus attestation rates