How often should you update your privacy policy?
There's a tidy answer and a true answer, and they're not the same. The tidy one is "at least once a year" — which is a real legal floor. The true one is "whenever your site changes what it does with data" — which happens far more often than annually, and is where policies quietly go out of date. You need both cadences. Here's how they work.
Two cadences. Calendar: if the CCPA/CPRA applies to you, review and update your policy at least once every 12 months, and show a "last updated" date. Event-driven: update it any time your data practices change — new tool, vendor, tracker, data use, or law — because the GDPR and other laws require your policy to be accurate at all times. The annual review is the minimum; the event-driven updates are what actually keep you covered.
Most people asking this question want a number they can put in a calendar and forget. And there is one — but treating it as the whole answer is exactly how privacy policies end up describing a website that no longer exists. The annual review is real and required, but it's a floor, not a strategy. The updates that actually keep your policy accurate don't happen on a schedule; they happen every time you install a tool, add a vendor, or start using data a new way. Getting this right means running two different cadences at once — one on the calendar, one triggered by change — and understanding why the second matters more than the first.
The two cadences you actually need
Almost every good answer to "how often" collapses two very different things into one number, which is why it's confusing. Separate them and it gets clear:
A fixed, scheduled review — at least once every 12 months if the CCPA applies. Predictable, easy to diarise, and mostly about catching drift you didn't notice and new legal requirements.
An update triggered every time your data practices change — a new tracker, vendor, or data use. Unpredictable, easy to miss, and the cadence that actually keeps your policy accurate.
The calendar cadence is the one everyone knows and the one that's easy to comply with — you put it on the calendar and do it. The event-driven cadence is the one that actually determines whether your policy is true on any given day, and it's the one that gets missed, because nothing prompts it. Let's take each properly.
The calendar rule: at least every 12 months
The clearest fixed requirement comes from California. Under the CCPA (as amended by the CPRA), covered businesses must review and update their online privacy policy at least once every 12 months — it's codified in the statute and regulations, not just best practice. As part of that, the policy has to display the date it was last updated, so anyone (including a regulator) can see it's current.
What the annual review is actually for is worth understanding, because it's not a rubber stamp. In a CCPA context, you're expected to refresh the specifics: the categories of personal information you collected in the past 12 months, what you disclosed or sold, and the current description of consumer rights and how to exercise them. It's a genuine look-back at the year's data practices, not just bumping a date.
An annual review is sound practice regardless of whether you're strictly CCPA-covered. Over any twelve months you'll almost certainly have added tools, changed vendors, or adjusted how you handle data — and a yearly checkpoint catches the drift you didn't consciously notice. Many businesses that aren't technically covered do it anyway, simply because it's the reliable way to keep the categories of data you collect and share current.
How to actually run the annual review
Because the yearly review is the one cadence you can schedule, it's worth doing well rather than treating it as a date-bump. A useful annual review walks through a short, concrete checklist:
- Re-inventory what you collect. Compare the data categories in your policy against what your forms, accounts, and features actually gather now — a year is long enough for these to have quietly diverged.
- Re-inventory who you share with. Check the trackers and third-party tools actually running on your site against the vendors your policy names. New ones added mid-year are the usual gap.
- Check for new legal requirements. New state privacy laws and regulatory updates arrive regularly; confirm your policy still reflects the laws that apply to your audience.
- Verify the rights and contact details. Make sure the described rights, opt-out mechanisms, and contact routes still work and are current.
- Update the date — after the review, not instead of it. Refresh the "last updated" date once you've genuinely checked, so the date reflects a real review rather than a cosmetic touch.
Done properly, the annual review often surfaces two or three event-driven changes you missed during the year — which is precisely its value as a backstop. If it never turns up anything, that's usually a sign the review was a date-bump rather than a genuine look.
The GDPR standard: accurate at all times
The GDPR approaches this from a completely different direction, and the contrast is the whole point. The GDPR sets no fixed update frequency. Instead it sets a standard: your privacy notice must be accurate at all times. Any material change to your processing activities requires an updated notice — and if you start collecting or using personal data in new ways, you're required to disclose that and communicate the change to people.
Read those two regimes together and you get the real answer. California gives you a minimum frequency; the GDPR gives you a standard of accuracy with no minimum and no maximum — just "always true." The CCPA's annual review satisfies a calendar; the GDPR's accuracy standard can be violated the very day you add a tracker, months before your next scheduled review. That gap between the two is exactly where the event-driven cadence lives.
The events that should trigger an update
So what actually counts as a change that requires an update? Here are the triggers — and notice how ordinary most of them are. These aren't rare corporate events; they're routine Tuesdays:
You add a new tool or tracker — analytics, advertising, chat, reviews, a marketing pixel. Each can collect data your policy doesn't yet mention.
You engage a new vendor or processor — a new third party handling personal data changes who your data is shared with.
You collect a new type of data — a new form field, a new feature, an account system that gathers something you didn't before.
You use data for a new purpose — repurposing data you already hold (e.g. using signup emails for advertising) specifically requires disclosure.
You expand to a new market — new countries or states can bring new legal requirements your policy must reflect.
A relevant law changes — a new state privacy law or a regulatory update can require new disclosures even if nothing on your side changed.
Every trigger above shares one dangerous property: nothing forces you to notice it. When your marketing team adds a pixel through a tag manager, no alarm goes off in the legal review. When a plugin update starts collecting something new, your policy doesn't flinch. The annual review is easy precisely because it's on the calendar — but the updates that keep you accurate are the ones with no reminder attached, which is exactly why they get missed and why policies silently drift out of truth between annual reviews.
Has your site started collecting something new?
Run a free scan to see the trackers actually loading now — and whether they still match what your privacy policy says. It's the fastest way to catch the changes that should have triggered an update. No account needed.
Scan my site free →Free · about 10 seconds · no signup. Information, not legal advice.
Updating vs. notifying — they're different
There's a second question hiding inside "how often," and it's easy to miss: when you do update, do you have to tell anyone? The answer depends on how significant the change is, and it splits cleanly:
Small clarifications or wording fixes: refreshing the "last updated" date is generally enough.
New data uses or sharing: notify users — email, banner, or pop-up — so the change is communicated, not silent.
Maintain the "last updated" date and, ideally, a history of versions, so you can show what changed and when.
This distinction has teeth. CalOPPA specifically requires you to describe your process for notifying users of material changes, and the GDPR expects material changes to processing to be communicated, not buried in a silent edit. The rule of thumb: if the change affects what you do with people's data in a way they'd care about, tell them actively. If it's housekeeping, the date is enough. Quietly changing a material practice and hoping no one notices is the one approach that reliably backfires.
Why a version history is worth keeping
Beyond the live "last updated" date, keeping a record of past versions of your policy is quietly valuable. If a question ever arises about what your policy said at a particular time — during a dispute, a regulator's inquiry, or a data-subject complaint — you can show exactly what disclosure was in effect when. It also makes material-change notifications honest: you can point to precisely what changed between versions rather than asking users to take your word for it. You don't need elaborate tooling; even a simple archive of dated versions turns "trust us, it was disclosed" into something you can actually demonstrate. Given that a privacy policy is a set of representations you can be held to, being able to prove which representation applied when is a genuine protection.
The honest way to think about frequency
Step back and the "how often" question reframes itself. The reason it's hard isn't that the rules are unclear — it's that the right cadence is "whenever reality changes," and reality changes on no schedule you control. Which points at the actual solution:
The best update frequency isn't a number — it's "whenever your policy stops being true." A privacy policy is a disclosure, and a disclosure's only job is to be accurate. An annual review catches drift late; the real goal is to know the moment your site starts doing something your policy doesn't describe. That's less about diligence and more about having something that tells you when things changed — because "review it more often" fails the same way "remember to check" always fails. The winning setup makes the drift visible instead of relying on you to catch it.
This is why the most reliable approach ties your policy to what your site actually does, rather than to a calendar reminder. Two things make that work in practice:
- Notice when your site changes. If something watches the trackers on your site and flags when new ones appear, the event-driven trigger stops depending on someone remembering — the change surfaces on its own. That's the same idea behind a cookie declaration that flags its own drift.
- Get told when the law changes. The other trigger — a regulation update — is one you can't see by watching your own site. Tooling that flags "an update is available" when a document template changes for a regulation that actually applies to you covers the legal-change trigger the same way scanning covers the practice-change one.
Between those two — drift detection for your practices, update alerts for the law — the event-driven cadence stops being something you have to remember and becomes something you get told about. The annual review then does what it's actually good for: a scheduled backstop, not your only line of defence.
The bottom line
How often should you update your privacy policy? At least every 12 months if the CCPA applies — that's the firm floor, and the policy should carry a "last updated" date. But the reviews that actually keep you covered are event-driven: any time you add a tracker, a vendor, a data use, or a market, or a relevant law changes, because the GDPR and similar laws require your policy to be accurate at all times, not just once a year.
The catch is that the annual review is easy and the event-driven updates are the ones that get missed, because nothing reminds you. So the honest answer to "how often" isn't a number — it's "whenever your policy stops being true," which means the real fix is making that moment visible: watch your site for new trackers, get alerted when applicable law changes, and let the annual review be a backstop rather than your whole plan. Keep the policy true as reality moves, and "how often" takes care of itself.
Frequently asked questions
How often should you update your privacy policy?
On two cadences. First, on a fixed schedule: if the CCPA/CPRA applies, you must review and update your policy at least once every 12 months. Second, and more importantly, whenever your data practices change — a new tool, vendor, tracker, data use, or law change — because the GDPR and other laws require your policy to be accurate at all times. The annual review is the floor; event-driven updates are what actually keep it accurate. This is information, not legal advice.
Does the CCPA require annual privacy policy updates?
Yes. Under the CCPA (as amended by the CPRA), covered businesses must review and update their online privacy policy at least once every 12 months, and the policy must display the date it was last updated. This is a specific, codified requirement, not just best practice.
What events should trigger a privacy policy update?
Any material change to your data practices: adding a new analytics or advertising tool, installing an app or tracker, engaging a new vendor, collecting a new type of data, using data for a new purpose, expanding to a new market, or a change in applicable law. Each can make your existing policy inaccurate — which is the real risk, since an out-of-date policy misdescribes what your site actually does.
Do I have to notify users when I update my privacy policy?
For minor edits, updating the "last updated" date is generally enough. For material changes — especially new ways of using personal data — you should actively notify users, for example by email, banner or pop-up, so the change is communicated rather than silent. CalOPPA specifically requires you to describe your process for notifying users of material changes, and the GDPR expects material changes to be communicated.
What does the "last updated" date on a privacy policy do?
It signals that the policy is maintained and shows when it last changed — which the CCPA specifically requires. It's also a practical trust and accountability marker: a policy dated years ago suggests it may not reflect current practices, while a recent date shows the policy is kept current. Keep it accurate; don't bump the date without an actual review behind it.
Disclaimer: This article is general information, not legal advice, and does not create an attorney–client relationship. Update requirements vary by jurisdiction and the specifics of your business, and privacy laws change frequently. ConsentPixel — Privacy · Verified is not a law firm, and keeping a privacy policy updated does not by itself make a website compliant with any law. Consult qualified counsel for your specific situation.