A policy with no review in the last year, no approver or no owner is one of the most common findings. Prevent it with a policy register that shows an owner, the last review date, the next review date, the approver and where staff acknowledged it.
Why it gets flagged
Auditors read policies first. A policy that mentions a tool you retired, a role that no longer exists or a date three years old tells them the document is not in use. It also casts doubt on the controls that depend on it.
Build a policy register
A spreadsheet is fine. Columns that matter:
- Policy name and version.
- Owner by role.
- Approver and approval date.
- Last review date and next review date.
- Where it is stored.
- Acknowledgement status for staff.
Sort by next review date and look at it monthly.
What a review should do
A review is not changing the date. Read the policy, compare it with what you actually do, and adjust either one. Record the outcome even if no change was needed: "Reviewed 14 October, no changes, approved by the CTO."
Keep version history so the auditor can see what changed and when.
Match policy to practice
Short policies that you really follow beat long ones copied from a template. If the policy says all changes need two reviewers and you have a small team with one, change the policy or change the practice. Auditors test the stated rule.
Acknowledgement
Staff should read and acknowledge the policies that apply to them at hire and after material changes. Keep a record. Include contractors with access.
A monthly routine
On the first working day of each month, open the register and filter for anything due in the next sixty days. Assign the review to the owner, give a due date and track it in your ticket system. Reviews that depend on goodwill slip. Reviews with tickets happen.
Keep policies short
Long policies are hard to review and hard to follow. A two page access control policy that says what you really do beats a fifteen page one with clauses you cannot meet. Move detail into procedures and runbooks that engineers actually use, and link them from the policy.
Check what the policy names
During review, search for tool names, role titles and system names. Update any that changed. Small details like an old ticketing tool tell the auditor the document was copied and not read.
One owner per policy
Name a role, not only a person, as the owner. When someone changes jobs, the role stays and the register stays correct. Give the owner authority to edit and a named approver for sign off. Policies that belong to everyone belong to no one.
Quick check
How often should policies be reviewed?
Many programs choose at least once a year. Pick an interval, write it in the policy and keep to it.
Safeguard's compliance automation can track policies and reminders in one place. The review still needs a human decision.
Last reviewed: 19 October 2026.
