Policy Review Cycles: How Often to Review Company Policies and How to Run the Review (India, 2026)

Almost every policy has a line that says “reviewed annually”. Far fewer have a record showing it was. Reviews slip because nobody owns the date, because a review that finds nothing to change feels like wasted effort, and because the real trigger for a rewrite, a new law or a regulator’s circular, arrives in the middle of the year and no calendar anticipates it.

This guide answers two practical questions: how often should a company review its policies, and how should it run the review so there is evidence afterward? Where an Indian regulator has set a minimum frequency, we cite it from the source. Where it has not, we give a sensible default and say clearly that it is our recommendation.

Three reasons a policy comes up for review

A review cycle that only runs on the calendar will miss most of the changes that matter. Build the process around three triggers.

The calendar. A fixed interval, set by the regulator or by your own risk view, so that no policy goes unread for years.
An external change. A new law, rule or regulator direction. These cannot wait for the next scheduled review.
An internal event. An incident, an audit finding, a failed control, a reorganization or a new system. These show where the policy and reality have drifted apart.

Recent changes show how quickly the external trigger can invalidate a policy. The Labour Codes came into force on 21 November 2025, and under Section 32 of the OSH Code (Occupation, Safety, Health and Working Conditions Code) annual leave now starts to accrue after 180 days of work, not 240, so every leave policy built on the old threshold needed to change. Our leave policy guide walks through the detail.

In technology, RBI’s Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, issued on 31 July 2026, repealed the earlier IT framework and IT governance instructions for NBFCs. Any NBFC policy that still cites those instructions needs to be re-based on the new text. Our NBFC outsourcing and IT governance checklist covers it.

Keep a trigger logRecord every external and internal trigger as it arrives, with the date and the policies it touches. A review that starts from a logged trigger is faster and easier to defend than one that starts from a vague sense that something is out of date.

Review frequencies set by Indian regulators

Some review intervals are written into the rules. These are minimums, and they are worth putting at the top of your calendar because they are the ones an inspector can check.

RBI, NBFC technology and cybersecurity policies: at least annually. The Board must approve the strategies and policies on technology and cybersecurity and review them at least annually (paragraph 6 of the 2026 Directions). For Middle Layer and above NBFCs, those strategies and policies must be placed before the Board for review at least annually, and the information security infrastructure and policies reviewed at least annually. See the Directions on rbi.org.in.
RBI, NBFC outsourcing: half yearly and annual cycles. The central record of material outsourcing of financial services is reviewed half yearly by the Board or the Risk Management Committee, and each service provider’s financial and operational condition is reviewed at least annually. See the Outsourcing Directions, 2025.
SEBI LODR, related party transaction policy: at least once every three years. Regulation 23(1) requires the Board to review the policy on materiality of related party transactions at least once every three years and update it accordingly. See the Listing Regulations.
SEBI LODR, code of conduct: annual affirmation. Regulation 26(3) requires the Board and senior management to affirm compliance with the code of conduct on an annual basis. That is an attestation, not a review, but it is a natural moment to confirm the code is current. Our guide on acknowledgment as audit evidence covers the record behind it.

Many other policies have no prescribed interval. The Listing Regulations require, for instance, a Board approved policy for the preservation of documents under Regulation 9, but do not fix how often it must be reviewed. For those, the interval is your decision, and you should be able to explain why you chose it.

A practical review calendar by policy type

The list below is our recommended baseline for policies that have no regulator set interval. It is a starting point, not a legal requirement. Shorten the interval for any policy that governs a high-risk process or sits in a fast-moving area of law.

Every 6 to 12 months: information security, cybersecurity, incident response, business continuity, vendor and third party risk. Technology and threats change quickly, and for regulated entities the minimum is already annual.
Every 12 months: code of conduct, anti-bribery, whistleblower, conflict of interest, data privacy, retention. These pair naturally with the annual affirmation and training cycle.
Every 12 months, plus on every legal change: HR policies such as leave, working hours, compensation, maternity and gratuity. Labour law is in transition, and a change in a Code or State rule should trigger an immediate review.
Every 2 to 3 years: stable governance and administrative policies, such as dress code, expense and travel, and facilities policies, unless something changes sooner.

Whatever the interval, write it into the policy itself, together with the owner and the date of the next review. Our guide to how to write a policy document shows where those fields belong.

How to run a review that leaves evidence

Assign a named owner. Every policy needs one accountable person, not a department. Ownership should follow the person’s role so that it survives staff changes.
Open the review from a task. Start from a due date or a logged trigger and send the owner the policy, its current version, the trigger log and any incidents or audit findings since the last review.
Compare the policy with practice. Ask whether people actually do what the policy says. A policy that is accurate on paper but ignored in practice needs a different fix than one that is outdated.
Check the law and the sources. Confirm the citations still point to the current text. Repealed instructions and superseded thresholds are the most common errors.
Decide and record the outcome. The outcome is one of three: no change, minor change, or material change. Record “reviewed, no change” with the date and reviewer. An unchanged policy with a dated review record is evidence. An unchanged policy with no record is a gap.
Route approval. Send changes to the right approver, whether a department head, a committee or the Board, as the policy requires.
Publish a new version and retire the old one. Keep the history. See why version control prevents legal risk.
Decide who must re-acknowledge. After a material change, the affected employees should read and accept the new version. For a minor change, a notice may be enough. Set that rule in advance.

A review with no change still countsMost review cycles find that most policies are fine. That is the point. Record the review even when nothing changes, because the dated record is what shows the review happened.

Material or minor: set the rule in advance

Teams argue about whether a change is big enough to need fresh approval and acknowledgment. Settle it before the first change by writing a short rule. For example, treat a change as material if it alters an obligation, a deadline, a threshold, an approval authority or a prohibited action. Treat it as minor if it corrects a typo, updates a name or link, or reformats the document. When in doubt, treat it as material. The rule makes the decision consistent and defensible, and it feeds the distribution step in your policy lifecycle.

Measure the review program

A review program that nobody measures decays. Track a small set of numbers each month:

the share of policies with a named owner and a next review date;
the number of policies overdue for review, and how long they have been overdue;
the age of each policy since its last review and its last material change;
the time from an external trigger to a published update; and
the share of affected employees who have acknowledged the latest version.

The first two will tell you immediately where the program is weakest. Put them in front of the compliance head or the audit committee on a regular schedule.

Six reasons review cycles fail

No owner. The date exists, but nobody is accountable for it.
One shared spreadsheet. The calendar lives in a file that one person updates when they remember.
Reviews only on the calendar. A new law arrives, but nothing prompts a review until the next annual date.
No record of “no change”. The review happened, but nothing proves it.
Edits without versions. The policy is changed in place, so the history and the acknowledgments are lost.
Review without redistribution. The document is updated but the people who must follow it are never told. Our guide on policy onboarding and acknowledgment covers closing that loop.

The DPDP Rules offer a useful planning example. Their core obligations apply from May 2027, which gives companies a defined window to review privacy, security, breach and retention policies. Our guide to the eight DPDP policies to update shows how to use that window as a review trigger rather than a last minute rewrite.

How PolicyCentral.ai helps

PolicyCentral.ai puts the review cycle on rails. Every policy has an owner and a next review date, and owners are reminded when a review is due. Changes route through approval, each version is kept, and the approved version goes to exactly the audience it applies to, in ten Indian languages. Acknowledgments are recorded in a tamper-evident audit trail, so after a material change you can see who has accepted the new version and who has not.

If your review calendar lives in a spreadsheet, request a demo and bring it. It is the quickest way to see how owners, due dates, approvals and acknowledgments connect. This guide is for general information and is not legal advice.

Frequently Asked Questions

How often should company policies be reviewed?

Where a regulator sets an interval, follow it. For example, RBI requires NBFC technology and cybersecurity policies to be reviewed by the Board at least annually, and SEBI requires a listed company’s related party transaction policy to be reviewed at least once every three years. For other policies, a common baseline is annually for most policies and every two to three years for stable administrative ones, with an immediate review whenever the law changes.

What should trigger a policy review outside the normal schedule?

A new or amended law, rule or regulator direction, a security or compliance incident, an audit finding, a reorganization, or the introduction of a new system or vendor. Log each trigger with its date and the policies it affects.

Does every policy review need Board approval?

No. Approval should follow the policy’s own approval authority. Some, such as RBI required technology and cybersecurity policies for NBFCs, must be approved by the Board. Others can be approved by a committee or a department head. State the approval authority in each policy.

Do we need to record a review if nothing changed?

Yes. A dated record showing who reviewed the policy and concluded that no change was needed is the evidence that the review took place. Without it, an unchanged policy looks like a skipped review.

When should employees re-acknowledge a policy?

After a material change, such as a new obligation, deadline, threshold or approval authority. For minor edits such as typo fixes, a notice is usually enough. Write a rule for material and minor changes in advance so the decision is consistent.

Who should own a policy review?

One named, accountable person with the authority and knowledge to judge whether the policy still reflects practice and the law, usually the head of the function the policy governs. Tie ownership to a role so that it survives staff changes.

How can PolicyCentral.ai help with policy reviews?

PolicyCentral.ai assigns owners and next review dates, reminds owners when a review is due, routes changes through approval, keeps every version, distributes the new version to the right audience in ten Indian languages, and records acknowledgments in a tamper-evident audit trail.