Published: November 9, 2026
A policy review is a scheduled check that a policy is still accurate, legal, followed and useful. To run one, set a review date for every policy based on risk, have the owner and stakeholders check it against current law and practice, decide whether to keep, update or retire it, approve the result, and tell affected staff what changed.
This guide covers why policy reviews matter, how often to review, the triggers that should prompt an early review, a 7-step policy review process, and a checklist. It also covers a step most guides leave out: deciding whether staff need to read and accept the policy again, and keeping evidence that the review happened.
What is a policy review?
A policy review is a structured re-examination of an existing policy by its owner and the people it affects. The review asks whether the policy still reflects current laws, regulations, systems and ways of working, whether people follow it, and whether it achieves what it was written to do. The outcome is a decision: keep the policy as it is, update it, merge it with another policy, or retire it.
A policy review is not the same as a policy audit. A review looks at the document and asks whether it is right. An audit looks at practice and asks whether people are following it. The two feed each other: audit findings are one of the best inputs to a review.
Why policy reviews matter
- Laws and regulations change. A policy that was compliant when it was approved can fall out of line with a new rule without anyone noticing.
- Organizations change. New systems, structures, sites and job roles make steps, contacts and responsibilities out of date.
- Outdated policies create risk. If staff follow an old version, or ignore a policy because it no longer fits, the organization can’t rely on it in an incident, dispute or inspection.
- Some rules require it. SEC-registered investment advisers must review their compliance policies and procedures “no less frequently than annually” (17 CFR 275.206(4)-7). HIPAA requires covered entities to review their security documentation periodically and update it in response to environmental or operational changes (45 CFR 164.316(b)(2)(iii)).
How often should policies be reviewed?
Set the review cycle by risk and record it in each policy, as part of a “policy on policies” (sometimes called a metapolicy) that defines how all policies are managed. A common pattern:
| Policy risk | Examples | Typical review cycle |
|---|---|---|
| High | Information security, data protection, health and safety, anti-bribery, clinical procedures | Every 12 months, or more often if a regulation requires it |
| Medium | HR policies such as leave, conduct and remote working, plus expenses and procurement | Every 12 to 24 months |
| Low | Dress code, office facilities, brand and style guidelines | Every 24 to 36 months |
Where a law, regulator, standard or contract sets a frequency, that frequency wins. The SEC’s annual review requirement for registered investment advisers is one example.
Triggers for an early review
Don’t wait for the scheduled date if any of these happen:
- A new or changed law, regulation, standard or contract term
- A restructure, merger, new site, new system or new job role
- An incident, near miss, complaint or policy breach
- An audit or inspection finding
- Repeated questions or exception requests, which show the policy is unclear or unworkable
Who should be involved in a policy review?
The policy owner leads the review and is accountable for the result. They usually bring in subject-matter experts who know how the work is really done, legal or compliance to check the policy against current requirements, HR where the policy affects employment terms, IT where systems are involved, and a few of the people who follow the policy. The approver (an executive, committee or board) signs off the outcome. A policy coordinator or compliance team often tracks review dates across all policies.
The policy review process in 7 steps
1. Schedule the review and notify the owner
Keep a register of every policy with its owner, approval date and next review date. Notify each owner well before the date. Sending the first reminder 60 to 90 days ahead leaves time to consult. In SharePoint, a “Next review date” column in the policy library and a scheduled Power Automate flow can send these reminders automatically. See how to create policy review reminders in Office 365.
2. Gather the evidence
Before reading the policy, collect what has happened since the last review: changes in laws and standards, audit and inspection findings, incidents and breaches, exception requests, staff questions, and changes to systems and structures. This evidence turns the review from a read-through into a real check.
3. Review the policy against the evidence
Work through the policy with these questions:
- Is it still required, and does it still meet every legal and regulatory requirement?
- Is it being followed as intended? If not, is the policy at fault or the way it was communicated?
- Is it achieving its purpose?
- Are the scope, roles, contacts, system names and linked procedures still correct?
- Does it conflict with or duplicate another policy?
- Is it clear, in plain language, and still the right length?
4. Consult stakeholders and draft changes
Share the findings and proposed changes with the people listed above and give them a deadline. Record every comment and what you did with it. Make the changes in a draft version, keeping the published version live until the new one is approved. If the policy needs a full rewrite, our guide on how to write a policy covers structure and plain-language rules.
5. Decide the outcome and get approval
Every review should end in one of four documented outcomes:
- No change: the policy is still correct. Record the review and set the next date.
- Minor update: wording, contacts, links or formatting change, but the rules don’t.
- Material update: the rules, scope or responsibilities change.
- Retire or merge: the policy is no longer needed or is absorbed into another one.
Send updates and retirements to the approver, and record who approved them and when.
6. Publish and decide who needs to re-acknowledge
Publish the approved version as the only current copy, remove old copies from shared drives and intranet pages, and update the version history. Then decide whether staff need to read and accept the policy again (see the next section).
7. Record the review and set the next date
Even when nothing changes, record that the review happened: the date, reviewer, evidence considered, outcome and approver. Set the next review date and add it to the register.
After the review: does staff need to re-acknowledge the policy?
This is the step most review processes skip. If a policy’s rules change but staff never see the new version, the review hasn’t changed behavior, and your evidence still points to the old version. Decide case by case:
| Review outcome | Example | Re-acknowledgment? |
|---|---|---|
| No change | The policy is confirmed as current | No. Record the review only. |
| Minor update | A new contact name, a fixed link or a typo | Usually no. Publish as a minor version and mention it in a newsletter if useful. |
| Material update | A new approval limit, a new prohibited activity or a change in who must do what | Yes. Assign the new version to everyone in scope, with a deadline and a summary of what changed. |
| Scope change | The policy now also covers contractors or a new site | Yes, at least for the newly covered group. |
| Retired | The policy is merged into another one | Assign the policy that replaces it, if its rules are new to people. |
Write the rule for this decision into your policy on policies, so owners don’t decide it differently each time.
How to prove a policy review happened
Auditors and regulators often ask for evidence of the review itself, not just the current policy. For each policy, keep:
- A version history showing every version, its effective date and what changed
- A review record with the date, reviewer, evidence considered, outcome and approver, including reviews where nothing changed
- Earlier versions, kept for as long as your retention rules require. HIPAA, for example, requires security policies and procedures to be kept for 6 years from creation or from when they were last in effect, whichever is later (45 CFR 164.316(b)(2)(i)).
- For material changes, a record of who read and accepted the new version, and when
Running policy reviews in SharePoint
SharePoint document libraries already support most of the review: metadata columns for owner and next review date, major and minor versions, version history, content approval, and Power Automate flows for reminders and approvals. For a full setup, see our guide to managing policies in SharePoint.
What SharePoint doesn’t do on its own is re-issue a changed policy to the people in scope, chase people who haven’t read it, or keep a time-stamped acknowledgment of the exact version each person accepted. Our policy and procedure management software, DocRead, adds that inside SharePoint and Microsoft 365. It assigns the new version to SharePoint or Microsoft Entra ID groups, sets a reading deadline, sends reminders, escalates overdue readers to their managers and produces acknowledgment reports that export for auditors.
Policy review checklist
- Every policy has an owner, an approver and a next review date in a register.
- The review cycle is set by risk, or by the frequency a regulation requires.
- Early-review triggers are defined and monitored.
- Owners are reminded well before each review date.
- Evidence (law changes, audits, incidents, exceptions, questions) is collected before the review.
- The policy is checked for compliance, use, effectiveness, accuracy, overlap and clarity.
- Stakeholder comments and responses are recorded.
- The outcome (no change, minor, material or retire) is documented and approved.
- Only the current version is published, and old copies are removed.
- Staff re-acknowledge material changes by a set deadline.
- The review record and version history are kept for the required retention period.
- The next review date is set.
Reviewed and updated a policy? Make sure the right people read the new version. See how DocRead re-issues changed policies in SharePoint and records who accepted each version.
Book a demoRequest a quoteStart the 30-day SharePoint Server trial
Frequently asked questions about policy reviews
What is a policy review?
A policy review is a scheduled check, led by the policy owner, that a policy is still legal, accurate, followed and effective. It ends with a documented decision to keep, update, merge or retire the policy, followed by approval and communication of any changes.
How often should policies be reviewed?
Set the cycle by risk: commonly every 12 months for high-risk policies, every 12 to 24 months for medium-risk policies and every 24 to 36 months for low-risk ones. Review earlier when laws, systems or structures change, after incidents or audit findings, and whenever a regulation sets a specific frequency.
What are the steps in a policy review process?
Schedule the review and notify the owner, gather evidence, review the policy against it, consult stakeholders and draft changes, decide the outcome and get approval, publish and decide who needs to re-acknowledge, then record the review and set the next date.
Who is responsible for reviewing a policy?
The policy owner is responsible for leading the review, with input from subject-matter experts, legal or compliance, HR, IT and the people who follow the policy. The designated approver signs off any changes.
What is the difference between a policy review and a policy audit?
A policy review checks whether the policy document is still right. A policy audit checks whether people are actually following it. Audit findings are a key input to the next review.
Do employees need to sign a policy again after a review?
Only when the change is material, such as new rules, new responsibilities or a wider scope. Minor wording or contact changes usually don’t need re-acknowledgment. Write this rule into your policy on policies so it is applied consistently.
What should a policy review record include?
The policy name and version, review date, reviewer, evidence considered, outcome, approver and approval date, a summary of changes, whether re-acknowledgment was required, and the next review date.