But "no fixed rule" is not the same as "consent lasts forever." The same GDPR principles that define what makes consent valid in the first place — specific, informed, freely given, reflecting current user intent — also define what causes it to expire. The duration question is inseparable from the purpose and context questions. When those change materially, the original consent may no longer be valid regardless of how recently it was given. When neither changes, consent obtained two years ago may still be sound. When both are stable but a long time has passed, the WP29 (now EDPB) has recommended refreshing consent "at appropriate intervals" as a best practice — and several national DPAs have translated that recommendation into specific timeframes.
TL;DR
- GDPR Article 7 does not define a maximum consent duration. Consent validity is determined by context, purpose, and user expectations — not by a countdown clock.
- Consent must be renewed whenever processing purposes change, new vendors or data recipients are added, there is a significant update to the cookie or privacy policy, or a long period of inactivity has elapsed.
- As a matter of regulatory guidance (not statute), France's CNIL and the Irish DPC recommend renewal at no longer than six months. Germany suggests six to twelve months. Spain has allowed up to twenty-four months. Luxembourg recommends twelve months. The ePrivacy Directive, as applied in practice, implies at least annual renewal.
- The practical approach for most organizations is a hybrid model: a fixed renewal interval aligned with the most conservative DPA guidance applicable to your user base, combined with immediate re-consent triggers whenever material changes occur.
What the Law Actually Says
GDPR Article 4(11) defines consent as "any freely given, specific, informed and unambiguous indication of the data subject's wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data." Article 7 sets the conditions: controllers must be able to demonstrate consent was obtained, consent must be separable from other matters, and the data subject must be able to withdraw at any time with the same ease as granting.
Neither article addresses duration. The storage limitation principle under Article 5(1)(e) — which requires personal data to be kept no longer than necessary — applies to the data processed under consent, not to the consent record itself. Article 5(2)'s accountability principle requires that you be able to demonstrate compliance at any time, which means your consent records must be current and retrievable, but does not set a maximum age for valid consent.
What does emerge from the GDPR framework is a logical inference about duration: consent is valid as long as it accurately reflects the data subject's informed, specific, and freely given choice about the specific processing activity in question. As the ICO puts it, "consent is likely to degrade over time." The reasons for that degradation are concrete: purposes change, vendors change, technologies change, policies change, and time itself erodes the reasonable expectation that a choice made some time ago still reflects current intent. The ICO recommends considering whether to automatically refresh consent every two years, while acknowledging that a longer or shorter period may be justified depending on context.
The ePrivacy Directive, which governs cookies and similar tracking technologies and must be satisfied in parallel with GDPR, contains no explicit duration rule either. However, in practice most DPA guidance on cookie consent renewal is issued under national implementations of ePrivacy rather than directly under GDPR, producing the six-month and twelve-month recommendations discussed below.
National DPA Guidance: The Practical Timeframes
Because GDPR sets principles rather than periods, the national data protection authorities have filled the gap with their own guidance. This guidance is not binding law — organizations can justify different periods if they can articulate a rational basis — but it carries significant enforcement weight. Regulators who have issued specific recommendations will expect organizations in their jurisdiction to either follow them or demonstrate why their approach is equally valid.
France's CNIL is the most conservative and most influential. Its guidance specifies that consent for cookies should be re-obtained at no longer than six months after the initial consent. This applies to all cookies requiring consent — analytics, advertising, social media trackers. Six months is the hard recommended maximum for French user traffic. The CNIL's September 2025 fine of €325 million against Google — its largest cookie-related penalty to date — reinforces how seriously French regulators treat consent practices.
Ireland's Data Protection Commission, the lead supervisory authority for many major tech platforms due to EU establishment rules, aligns with CNIL's six-month recommendation for cookie consent renewal. This has outsized practical importance: many organizations whose EU privacy compliance is formally supervised by the Irish DPC should treat six months as their effective working maximum.
Germany's Federal Commissioner for Data Protection and Freedom of Information (BfDI) takes a slightly more permissive position, suggesting a range of six to twelve months. Spain's AEPD has allowed up to twenty-four months in certain contexts, though this applies at the conservative end of proportionality analysis. Luxembourg recommends twelve months. The practical consequence for organizations serving users across multiple EU member states is that the most conservative applicable standard — which is typically six months for any site serving French or Irish users — is the sensible default. The variation in cookie consent requirements across EU member states — and how to implement banner logic that serves the correct standard for each user's jurisdiction without maintaining separate implementations — is the operational challenge that multi-region consent management infrastructure must solve.
When You Must Renew Consent Regardless of Time
Duration-based renewal is the baseline. Event-based renewal is the requirement that catches organizations off guard, because it is not optional and does not depend on how recently consent was given. Certain changes to your processing activities categorically invalidate existing consent and require fresh consent before processing continues.
A change in purpose is the clearest trigger. GDPR Article 6 requires that consent be specific to a defined purpose. If you obtained consent to use analytics cookies, that consent does not extend to using the same identifiers for behavioral advertising. If your email marketing program was originally consented to for product updates and you want to extend it to promotions from partner companies, the original consent does not cover the expanded scope. The WP29 guidelines on consent are explicit: "if consent is sought for a particular purpose and the controller wishes to process the data for another purpose, the controller needs to seek additional consent for the new purpose." There is no exception for closely related purposes or minor expansions.
The introduction of new third-party recipients or vendors is a separate trigger, because consent to share data with "our analytics partners" is not the same as consent to share data with a specific new partner added six months later. The specificity requirement means users must know which third parties will receive their data — GDPR Recital 42 specifies that data subjects should know the identity of the controller, and this extends to third-party recipients. When a new advertising vendor, data broker, or analytics platform is added to your stack, existing consent that did not cover that entity is not a valid basis for sharing data with them.
Significant updates to your privacy or cookie policy also require fresh consent, because the "informed" requirement means users consented to the practices described in the version they saw. A material change to those practices — not a minor formatting update, but a substantive change to categories of data collected, purposes, or retention periods — creates a version mismatch between what was disclosed and what is now practiced. Managing the consent lifecycle so that policy version changes trigger re-consent flows and new consent records are created reflecting the updated disclosure is the operational mechanism that keeps consent aligned with the privacy notice the user actually saw.
Introduction of new tracking technologies is the ICO's specific trigger: "If you introduce new storage and access technologies for a different purpose to what you originally stated when consent was granted, you must obtain fresh consent for the new technology or purpose." This captures the common scenario of adding a new pixel, switching analytics platforms, or deploying a new remarketing tag. Each new technology introduced for a purpose not covered by the original consent disclosure requires its own consent.
The Three Practical Models for Consent Expiration
Organizations implement consent expiration through three structural approaches, each with different compliance characteristics and operational costs.
The fixed duration model assigns a calendar-based expiration to every consent event. All consents expire at the same interval — typically six months or twelve months depending on the applicable DPA guidance — and the consent management platform automatically presents a renewal banner to returning users when their consent record has aged beyond the configured period. This is the simplest model to implement and audit: every consent record has a clear expiry date, and the system enforces renewal uniformly. Its limitation is that it produces unnecessary re-consent requests for users whose situation has not changed, potentially creating friction and reducing opt-in rates.
The event-based model configures renewal triggers around material changes rather than time. When a privacy policy version updates, when a new vendor is added to the consent framework, or when a new purpose category is activated, the system invalidates existing consent records and presents a renewal banner to all returning users whose prior consent predates the change. This model is more precise but more complex to implement, because it requires version control of the consent configuration and logic to compare each returning user's consent record version against the current configuration version.
The hybrid model combines both. Every consent record carries a maximum expiration date — set at the most conservative DPA guidance period applicable to the user's jurisdiction — and the system also triggers early renewal when a material change occurs that would invalidate older consents. A user who consented three months ago and whose consent record is still within the six-month window would see a renewal banner if a new vendor is added, but not otherwise. A user who consented seven months ago would see a renewal banner on return even if nothing has changed. This is the most defensible model because it captures both the context-driven and time-driven dimensions of consent degradation.
How to Implement Consent Expiration in a CMP
The technical implementation of consent expiration centers on the consent record's version and timestamp fields. Every consent event stored by a CMP should include the timestamp of the consent, the version of the consent configuration (banner text, vendor list, purpose categories) that was shown at the time, and the jurisdiction or consent framework applicable to the user's location.
The CMP's logic for returning users should evaluate these three fields against the current state of the system: has the configured expiration period elapsed since the consent timestamp? Has the consent configuration version changed in a way that materially affects the user's choices? If either condition is true, the returning user should see the consent banner again rather than being treated as having valid stored consent. If neither is true, the stored consent remains operative and no banner should appear.
Configuring the expiration period correctly requires knowing which DPA guidance applies to your user base and setting the period accordingly. If you serve French users, six months must be the maximum. If you serve German users and no French users, you might justify up to twelve months with appropriate documentation. If you serve global traffic and cannot segment by jurisdiction at the CMP level, the most conservative guidance period applicable to any significant portion of your EU traffic is the rational choice.
Consent cookie lifetime — the duration of the browser-side cookie that stores the user's consent record — must be aligned with the CMP's logical expiration period. If your CMP is configured to present renewal banners after six months but your consent cookie has a twelve-month lifetime, returning users whose consent has logically expired will not see the banner because the browser-side record still appears valid. The cookie lifetime and the system-side renewal logic must be synchronized. Many CMPs default to consent cookie lifetimes of twelve months or more without surfacing this as a configurable compliance parameter — verifying and adjusting this default is one of the most commonly overlooked consent expiration tasks.
Risks of Treating Consent as Indefinite
The practical risk of indefinite consent is not abstract. When a supervisory authority investigates a complaint, one of the first questions is whether the consent being relied upon is current. A consent record from three years ago, for a site that has added twenty new advertising vendors, deployed two new analytics platforms, and updated its privacy policy four times, is not credible evidence of informed consent to current data practices. The accountability obligation — the requirement to demonstrate that consent was properly obtained — cannot be met by producing a stale record that predates the current processing context by years.
Enforcement actions have specifically identified the inability to demonstrate ongoing consent validity as a contributing factor to liability. Italy's Garante, Spain's AEPD, and France's CNIL have all cited inadequate consent management practices — including treating historical consent as indefinitely valid without renewal mechanisms — in their enforcement decisions. The CNIL's €325 million Google fine in 2025 arose partly from a consent design that made ongoing reliance on valid consent structurally untenable. The principles that determine whether consent-based processing is lawful on an ongoing basis — not just at collection — and how to build operational practices around those principles rather than around compliance appearances — are the substance of what regulators test.
Common Mistakes
Treating consent as permanently valid unless explicitly withdrawn is the most widespread error. GDPR's withdrawal right means consent can be actively revoked at any time, but this does not mean consent is valid until explicitly revoked. The degradation dynamic — where changing context erodes the "informed" and "specific" foundations of the original consent — operates independently of withdrawal.
Not tracking consent age is the operational manifestation of this error. Organizations that maintain consent records but do not surface the age of those records in a way that triggers renewal are operationally incapable of identifying stale consent before a regulatory investigation does it for them. The dashboard you need is not just "did the user consent" but "when did the user consent, under which version of our privacy notice, and how does that compare to current processing."
Inconsistent expiration across channels creates a class of problem specific to organizations with web, app, and email consent managed by different systems. A user who consented to web analytics twelve months ago and email marketing eight months ago, on a site with six-month renewal configured for web but no renewal configured for email, has inconsistent consent status across channels. Regulators examining a complaint will look at the complete consent picture, not just the channel where the complaint originates.
Not triggering re-consent after vendor changes is the specific failure that the WP29 and ICO guidance most directly addresses. Adding a new advertising partner, switching analytics providers, or integrating a new CRM platform — each of these changes the data recipient set that users consented to, and each requires either obtaining fresh consent or demonstrating that the original consent was broad enough to cover the new recipient (which, given GDPR's specificity requirement, is rarely the case).
FAQ
Does GDPR require consent renewal?
Not explicitly. GDPR does not define a maximum consent duration. However, the principles underlying valid consent — specific, informed, freely given — mean consent degrades when context changes, and best practice guidance from DPAs recommends periodic renewal regardless of material changes.
How long does cookie consent last?
Legally, as long as the consent remains valid against the original purposes and disclosures, and until withdrawn. Practically, French CNIL and Irish DPC guidance suggests a maximum of six months before renewal. Germany suggests six to twelve months. Luxembourg recommends twelve months. The most conservative applicable guidance period for your user base is the practical working maximum.
When should consent be refreshed?
Whenever a new processing purpose is added, a new vendor or third-party recipient is introduced, there is a material update to the privacy or cookie policy, or the applicable DPA-recommended renewal period has elapsed — whichever comes first.
Is 12-month consent valid under GDPR?
Potentially, depending on your user base's jurisdiction and whether any material changes have occurred. For users in France, twelve months exceeds the CNIL's recommended maximum of six months. For users where no DPA has issued specific guidance, twelve months may be defensible with appropriate documentation. Apply the most conservative guidance applicable to your EU traffic.
Do I need to renew consent after policy changes?
Yes, if the changes are material — that is, if they affect the categories of data processed, the purposes, the vendors, or the rights and choices available to the user. Minor formatting or clarity edits that do not change the substance of what was disclosed do not require fresh consent. Material changes do.
Consent validity is not a binary state that flips from valid to invalid on a fixed date. It is a continuous judgment about whether the original consent still accurately reflects an informed, specific, freely given choice about current processing activities. Building systems that maintain consent validity over time — through both time-based renewal schedules and event-triggered re-consent flows — is the operational expression of that judgment at scale.
