Consent renewal after a policy change: who must be asked again, and who must not be assumed

Specificity is the property that makes consent worth having. A visitor agreed to analytics and marketing as described on a date, under a notice version. That agreement covers that processing, described that way. It does not cover a new purpose added later, a new class of recipient, or a quiet expansion of an existing purpose from measurement into profiling. Those are new consent events, because the thing being agreed to is new.

The same specificity protects you from re asking fatigue. If the original agreement genuinely covered the processing, a wording clarification that does not change the substance does not invalidate it. Re prompting the entire base for a comma teaches visitors that banners are weather, something to dismiss on sight, which degrades every future ask including the ones that matter. Materiality is the discipline: substance changes get a prompt, presentation changes get a changelog.

Consent is specific, which cuts both ways

New purposes are material: adding advertising to a base that only consented to analytics, adding personalisation, adding data sale or sharing in the jurisdictions that use those terms. New recipient categories are material: sharing with data brokers or ad platforms when previously data stayed with processors acting for you. New data types can be material: precise location joining a consent that covered page views. Longer retention and new automated decision making are the sort of changes transparency law expects to be communicated, and where they change the deal, re consented.

Not material: fixing a typo, reordering purposes without changing them, adding a vendor that performs an existing purpose under the same conditions where your framework treats the purpose as the consent unit, updating contact details. Keep a written materiality call for each notice change, signed off by whoever owns privacy, so the decision is a record and not a recollection. Auditors ask for the reasoning. A one paragraph memo per version is enough, and it is gold when it exists.

What counts as material, in practice

Version everything: notice text, purposes, vendor list, banner build, each with an effective date, and store the version in every consent record. When a material change ships, the banner logic splits the world cleanly: visitors with consent under the old version keep their existing processing, the new purpose stays off for them, and they are shown the new ask at the next natural visit, not ambushed mid task where consent quality goes to die. Their refusal of the new purpose changes nothing about the old grant.

Running the re ask without breaking the old base

Keep reading: Embedded social feeds and consent: the timeline that phones home before the click, Analytics exemption claims: the narrow door that is not a general excuse.

When silence is not an option at all

New visitors see the current version only. Reporting splits by version too, so you can see the new purpose uptake honestly instead of blended into a base that never saw it. The failure mode to avoid is the silent merge: updating the purposes text on the live banner and letting yesterday consent records be read as covering today purposes. That is not renewal. It is forgery with better typography.

Some changes are too big for a banner cycle. If the original consent was defective, wrong purposes, bundled consent, no genuine reject path, the fix is not a version bump. The processing built on it needs pausing for the affected purposes and a fresh consent programme, with legal advice on the historical position. Similarly, if a regulator in your market changes the rules, as happened when reject all expectations hardened in several European states, old banners that no longer meet the standard cannot keep collecting valid consent until the redesign lands.

Those cases are rarer than the routine version change, and they are exactly the cases where the version records and materiality memos pay for themselves. You will know precisely which consents were taken under which text, which purposes they covered, and which processing must stop. Companies without records get to have that conversation from memory, in front of a regulator. Versioning is cheap. Buy it before you need it.

Frequently asked questions

Do we need fresh consent every time the privacy policy changes?

No. Fresh consent is needed when processing changes materially: new purposes, new categories of recipients or data, or substance changes to what was agreed. Cosmetic or clarifying text changes do not invalidate existing consent. Record a short materiality judgement for each policy or notice version so the decision is documented.

Can we add a new tracking purpose under existing consent by updating the banner text?

No. Editing the purposes shown going forward does not extend consents already given. The new purpose must stay off for existing consent holders until they agree to it under the new version. Their old consent remains valid for the purposes it actually covered.

How should a consent renewal prompt be timed?

At the next natural visit or session start after the change takes effect, not injected mid task. The new processing stays off until the visitor responds. The prompt should make clear what is new, in plain language, rather than presenting the whole consent flow as if nothing had been agreed before.

What records prove which version a user consented under?

Consent records storing the notice and purposes version, the text or a reference to it, the timestamp, and the purposes granted. Combined with your version history and materiality notes, that lets you demonstrate exactly what each consent covers and why a change did or did not trigger a re ask.