Re-Consent After a Vendor Change: Who Has to Click Again
The CMP vendor list changes on a Tuesday. A new analytics vendor joins, an old ad partner leaves, and nobody tells the visitors. The consent records still say yes, because the visitors did say yes, to the old list. The new vendor is processing data under a consent that never covered it, and the gap sits in the log until someone asks.
Consent is specific. A visitor consents to purposes and vendors, not to a brand in general, and a consent record proves a choice about a specific banner version. The banner and privacy notice version shown is one of the six fields a useful consent record contains, precisely because consent to version three says nothing about version five. Change the vendor list and you have changed the version. The old record covers the old list.
What counts as a change that triggers re-consent
Not every change triggers a re-ask. A vendor leaving the list does not. A vendor joining it does, for every visitor whose data the new vendor will receive. A new purpose does, for every visitor affected by that purpose. A change in how an existing vendor processes data, new categories of data or a new retention period, is a change to the processing the visitor agreed to, and it needs a fresh choice too.
The regulators have said this in different words for years. The Garante's cookie guidelines say the banner should not be shown again unless processing changes significantly, the site cannot tell whether a cookie was already stored, or at least six months have elapsed. The CNIL's guidance treats six months as good practice for keeping a choice, consent and refusal alike. A significant processing change is the first of those three conditions, and a new vendor is the clearest example of one.
The record has to show which change did it
The practical work is record-keeping, not banner design. When the vendor list changes, record the date, the vendors added and removed, and the banner version that carries the new list. Then re-prompt the affected visitors and log the new choice against the new version, with the same six fields as the original record: identifier, timestamp, purposes accepted and rejected, banner version, method, and jurisdiction. A log that cannot show which version a visitor consented to cannot prove the consent covers the current vendors.
The retention side matters here too. Keep the old record as well as the new one. The old record proves the processing that happened before the change was lawful. Deleting it to tidy the log destroys the evidence for the period it covers. Consent records should outlive the reliance: keep them while the processing they authorize is active, plus one to three years after lapse, aligned with limitation periods in the main markets.
Who has to click again, exactly
Everyone the new vendor touches. Not everyone on the site, and not nobody. A vendor that only serves EU visitors needs re-consent from EU visitors. A vendor that only processes analytics data needs re-consent from visitors whose analytics data it will receive. Segment the re-prompt by the same jurisdiction and purpose fields the record already carries. A blanket re-ask to the whole audience is lazy and it trains visitors to click accept without reading, which is how the next vendor change gets ignored too.
The test is simple. Pick a vendor added in the last change, pick a visitor who consented before it, and confirm the log shows a fresh choice against the new banner version. If it does not, the vendor is processing on a consent that never covered it, and the fix is a re-prompt, not a note in a ticket.
Keep reading: The Banner Fires Again on app.yoursite.com: Subdomain Consent, Fixed, Server-Side Tagging Does Not Remove the Consent Question, Testing Your Cookie Banner Without Breaking the Law: What You Can A/B Test cover the nearby cases in this series.
Frequently asked questions
Does adding a vendor to the CMP list require re-consent?
Yes, for every visitor whose data the new vendor will receive. Consent is specific to purposes and vendors, and a consent to the old vendor list does not cover a new vendor. Segment the re-prompt by jurisdiction and purpose so only affected visitors are asked again.
Does removing a vendor require re-consent?
No. A vendor leaving the list narrows the processing the visitor agreed to, it does not expand it. Record the removal with the date and the banner version, but there is nothing new for the visitor to agree to.
How long does a consent choice last?
Regulator guidance clusters around six months: the CNIL, the Garante, and the ICO all treat about six months as good practice for both acceptance and refusal. Spain's AEPD allows up to 24 months. A significant processing change resets the clock before the period lapses.
What should the consent record show after a vendor change?
The date of the change, the vendors added and removed, the new banner version, and a fresh choice from each affected visitor logged against that version with the usual six fields. Keep the old record too, since it proves the processing before the change was lawful.