When Purposes Change, Consent Has to Be Asked Again
Somewhere in your database there is probably a row that says consent: true, with a timestamp. That row feels like evidence. Put it in front of a regulator, or a judge, or an angry customer with a screenshot of a different banner than the one you run now, and it turns into a claim you cannot support.
The burden sits with the controller. Under GDPR Article 7, the organisation relying on consent has to be able to demonstrate that the person gave it. Demonstrate is a records problem, not a design problem, and the receipt is where most consent programmes are thinnest, because the banner got the budget and the log got whatever the default settings kept.
A dark pattern consent banner steers people toward accepting by making refusal slower, dimmer, or more confusing than acceptance. Regulators treat that steering as a consent defect, not a design choice, because a yes obtained through friction asymmetry is not freely given under GDPR or state privacy law.
Consent is purpose specific. When a site starts using data for a materially new purpose, a new vendor category, a new sharing partner, or targeted advertising it did not previously run, the previous consent does not cover it and the choice has to be presented again to people whose data will be used that way.
What counts as a material change
A new purpose is material when a reasonable visitor would be surprised by it. Turning on cross-context behavioral advertising where only first party analytics ran before qualifies. So does sharing data with a new category of recipient, adding biometric or precise location use, or repurposing service data for marketing. Changing a vendor inside the same purpose, same data, same retention usually does not, which is why purpose wording has to be specific enough to tell the difference.
Vague purposes break this test on purpose. A purpose written as improving your experience covers everything and therefore consents to nothing specific. Regulators read broad purpose language against the site: if the notice could mean anything, the consent it collected proves very little when a new use is challenged.
The re-ask, done without training people to click anything
Re-asking on every visit is the failure mode at the other extreme. People learn that the banner is furniture and click the first button to clear it, which degrades every consent on the site, old and new. The workable pattern is a targeted re-ask: present the new purpose clearly to returning visitors whose stored consent predates it, name what changed in plain words, and leave existing choices untouched for everything that did not change.
Version the notice and the banner together. The consent record for the new choice should point at the new notice version, with a timestamp, so an auditor can separate data collected under the old purposes from data collected after the change. Without that version line, a re-ask happened on screen and nowhere in the evidence.
Sequencing the change so data does not run ahead of consent
The order matters: configure the new purpose in the consent platform, publish the new notice, deploy the re-ask, and only then enable the new vendor or sharing. Teams routinely ship in the opposite order because the marketing tool is ready first, and the gap between the tag going live and the banner catching up is exactly the period a complaint will screenshot.
Hold the launch if the consent platform cannot express the new purpose separately. Bundling a new advertising purpose into an existing analytics toggle because the tool has no spare toggle is a tooling limitation turned into a legal position, and it reads that way in an enforcement file.
Keep reading: Dark Pattern Consent Banners: The Designs Regulators Name in Complaints, Honoring Global Privacy Control: Testing Whether Your Site Actually Stops the Sale, and Consent Receipts: The Six Fields That Make a Yes Provable Later cover the nearby cases in this series.
Frequently asked questions
Does every privacy notice edit require re-asking consent?
No. Clarifications, contact changes, and vendor swaps inside an unchanged purpose usually do not. A new purpose, a new category of sharing, or a materially broader use does, because the original choice never covered it.
How should a re-ask be worded?
Name the change directly: what is new, what data it uses, and what stays the same. A banner that says we value your privacy and asks again teaches nothing and records a choice the person did not understand they were making.
What happens to data collected before the re-ask?
It stays governed by the purposes it was collected under. It does not gain the new purpose retroactively, so systems that merge old and new audiences need a rule that keeps pre-change records out of the new use until consent exists.
How long can a site run the old and new consent side by side?
As long as the records stay separable by version and timestamp. The risk is not the overlap period, it is losing track of which records carry which purposes when audiences and exports are built.