This free annual policy review checklist is for compliance managers, company secretaries and the HR, risk and information security leads who look after a policy library. It runs one review cycle across the whole library: the policy register and its owners, the year’s triggers, redlining, the legal check, approval by the right authority, publication with version control, staff attestation, retiring what is no longer needed and setting next year’s review dates. Each cycle leaves a record of what changed in every policy, who approved it and who has acknowledged it.
Auditors rarely find that a policy is missing. They find that it no longer describes what the organisation does. The access policy promises quarterly reviews and the team runs them twice a year. The incident policy routes reports to a mailbox that was closed in a migration. The review date was updated, but nobody read the text.
Several frameworks expect policies to be reviewed, not just stored. ISO/IEC 27001:2022 Annex A control 5.1 asks for policies that are approved by management, communicated, acknowledged by relevant personnel and reviewed at planned intervals and when significant changes occur. PCI DSS v4.0.1 Requirement 12.1.2 sets the interval for the information security policy: at least once every 12 months. A useful review answers three questions for each document: is it still right, is it still followed, and does everyone it applies to know the current version?
Who: each policy owner, chased by a coordinator, with sign-off by the authority that owns the policy.
Depth: varies. A full rewrite for high-risk or heavily triggered policies, a light check for stable ones, and a documented ‘no change’ where that is the honest answer.
Output: an approved, version-controlled library and a register with new review dates.
Law or regulation: a new obligation, or one with a new commencement date, that a policy must reflect.
Incidents and findings: a breach, a near miss, an audit finding or a run of policy exceptions.
Organisation: a restructure, an acquisition, a new system or outsourcing that changes who does what.
Log each trigger as it happens. The annual cycle then picks up anything still open.
This template reviews the content of the library. Knowing when the review is due, alongside every filing, renewal and audit date, is the job of the Annual Compliance Calendar Checklist. Writing a new procedure from scratch is a different task too: our guide to writing an SOP covers it.
Six phases, one checklist per review cycle, started each year by an annual schedule. A material change brings in the legal check, consultation and re-attestation steps.
The first task sets the approval deadline, names the coordinator and the approving authority, and records which frameworks apply.
Due dates in this phase run back from the approval deadline set in Phase 1.
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.
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.
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.
The annual schedule starts next year’s checklist on the same date.
The table lists the framework requirements most often behind an annual policy review and the phase that produces the evidence. Sector regulators and contracts can add their own, so treat the table as a starting point, not legal advice.
| Framework | Requirement | What it asks | Evidenced in |
|---|---|---|---|
| ISO/IEC 27001:2022 | Clause 5.2 | Top management establishes the information security policy; it is available as documented information, communicated within the organisation and available to interested parties as appropriate | Phases 4 and 5 |
| ISO/IEC 27001:2022 | Annex A 5.1 | Policy and topic-specific policies defined, approved by management, published, communicated, acknowledged, and reviewed at planned intervals and after significant changes | Phases 1 to 5 |
| ISO harmonized structure (ISO/IEC 27001:2022, ISO 9001:2026 and other management system standards) | Clause 7.5 | Review and approval of documented information for suitability and adequacy; control of changes such as version control; retention and disposition | Phases 3, 4 and 6 |
| PCI DSS v4.0.1 | Requirements 12.1.1 and 12.1.2 | Security policy established, published, maintained and disseminated; reviewed at least once every 12 months and updated as needed | Phases 1 to 5 |
| PCI DSS v4.0.1 | Requirement 12.6.3 | Personnel acknowledge at least once every 12 months that they have read and understood the security policy and procedures | Phase 5 |
| PCI DSS v4.0.1 | Requirements 1.1.1 to 11.1.1 | Each requirement’s policies and procedures are documented, kept up to date, in use and known to all affected parties | Phase 2 |
| SOC 2 (2017 Trust Services Criteria) | CC5.3, COSO Principle 12 | Point of focus: management periodically reviews control activities for continued relevance and refreshes them when necessary | Phases 2 to 4 |
| NIST CSF 2.0 | GV.PO-02 | Cybersecurity risk policy reviewed, updated, communicated and enforced to reflect changes in requirements, threats, technology and mission | Phases 2 and 5 |
| HIPAA Security Rule | 45 CFR 164.316(b)(2) | Review documentation periodically and update it as needed; make it available to those who implement it; keep it for six years from creation or from when it was last in effect, whichever is later | Phases 5 and 6 |
Most of these texts say ‘planned intervals’ or ‘periodically’. Of the frameworks above, only PCI DSS fixes the interval at 12 months, so an annual cycle is a convention that satisfies the rest, provided triggered reviews happen in between. The HIPAA row reflects the current Security Rule. A proposed update was published in January 2025, and at the time of review the Federal Register showed no final rule. Nothing on this page is legal advice.
An annual recurring schedule opens the review on the same date each year. Owner deadlines run back from the approval date you enter, and the register sits in a table on the first task, so the coordinator chases from one list rather than a spreadsheet emailed around.
Conditional logic shows the legal check, consultation and re-attestation tasks only when the review finds a material change. A quiet year stays short, and the PCI DSS acknowledgement step appears only for libraries that need it.
The approval is assigned to the authority you named and the checklist waits for it. Redlines, minute references and attestation exports attach to their tasks, and the activity trail shows who did what, and when, for the auditor who asks.
CheckFlow is not a document management system or a policy portal, and it does not give legal advice. Your policies stay where staff read them; CheckFlow runs the review around them. Recurring checklists keep the annual cycle and the triggered reviews on schedule, and CheckFlow’s SOP software turns the procedures beneath each policy into checklists people actually follow.
Some policies drive their own annual process. The Conflict of Interest Declaration Checklist runs the yearly declaration campaign once the policy is approved, and the Whistleblowing Report Handling Checklist handles reports made under your speak-up policy. To standardise the procedures beneath your policies, start from the Process Standardization Checklist.
At least once a year is the common standard, and for the information security policy under PCI DSS it is a requirement. ISO/IEC 27001 and SOC 2 leave the interval to you, but an auditor will expect a defined cadence and evidence that you kept to it. Higher-risk policies, such as access control or anti-bribery, may warrant a shorter cycle. Whatever the cadence, review straight away when a law, an incident or a restructure makes a policy wrong.
The authority your governance framework gives that policy, recorded in the register. A common pattern is the board for the code of conduct and other reserved matters, the executive team for organisation-wide policies such as information security, and a function head for narrower topic policies. ISO/IEC 27001 requires management approval and top management to establish the information security policy. The owner who wrote the redline should not be the only approver.
A change to what people must do, who must do it, who the policy covers or how much risk the organisation accepts. Adding a reporting deadline, widening scope to contractors or changing an approval limit are material. Fixing a job title, a broken link or the layout is not. Material changes need the legal check, communication and re-attestation; minor edits need approval and a new version number.
For the security policy in a PCI DSS environment, yes: Requirement 12.6.3 needs an acknowledgement at least once every 12 months. ISO/IEC 27001 Annex A 5.1 asks for policies to be acknowledged by relevant personnel but sets no interval. Elsewhere it is your choice. Many organisations ask for annual acknowledgement of the code of conduct and a fresh one whenever another policy changes materially, with records kept against each person and version.
As long as you might need to show what applied at a past date, which your retention schedule should state. For HIPAA Security Rule documentation, 45 CFR 164.316 sets six years from creation or from the date it was last in effect, whichever is later. Archive superseded versions with their approval record rather than deleting them; the Data Retention & Disposal Review Checklist helps set the periods.
A policy states what the organisation requires and why, and is approved at a senior level. A standard sets the specific rules that meet it, such as password length. A procedure describes how a task is done, step by step, and is owned by the team that does it. Review them together, because most policy failures are a policy and a procedure that no longer agree.
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.
