No, not by the calendar. There is no expiry period anywhere in the GDPR and no rule that consent lapses after twelve or twenty-four months. But consent stops being valid when the things it rested on change, and that happens far more often than an arbitrary clock would catch. The right question is not how old your consent is. It is whether it still describes what you are doing.
This article covers why there is no statutory expiry, what actually invalidates consent, the evidential problem with old records, how to think about refreshing, and the case where consent was the wrong basis from the start.
There Is No Expiry Date In The Regulation
Search for a number and you will find twelve months, twenty-four months, and confident statements that consent must be refreshed annually. None of these comes from the GDPR. Article 7 sets conditions for consent and says nothing about duration.
What does exist is a strong expectation that consent remains current. Regulators consistently advise reviewing consents and refreshing them where anything material has changed, and the accountability principle in Article 5(2) requires you to be able to demonstrate the consent you are relying on is valid — present tense. How consent is collected, recorded, versioned and withdrawn in the first place is the consent management guide's subject; this article is only about what happens to it afterwards.
The distinction matters practically. A fixed expiry gives you a rule to follow and a false sense of safety, because consent collected badly is invalid on day one and consent collected well for unchanged processing does not spoil at month thirteen. Ageing is a poor proxy for the thing that actually goes wrong.
What Actually Stops Consent Being Valid
Four things, none of them time.
The purpose changed. Consent is specific to the purposes described when it was given. Adding a new use for the data means the existing consent does not cover it, whether that happened last week or three years ago.
The scope crept. More data types, new recipients, a new subprocessor category, a transfer to a country that was not in the picture. Each takes the processing outside what the person agreed to.
The information stopped being true. Consent must be informed, and it was informed by a specific description. If your privacy information has moved on and the consent record points at wording that no longer reflects reality, the basis for that consent has quietly gone.
It was withdrawn — and the withdrawal did not reach the processing. Article 7(3) requires withdrawal to be as easy as giving, and a preference toggle that updates a table but does not stop a downstream job is a withdrawal in form only.
Notice that three of the four are things you did, not things the data subject did. Consent decays because organisations change around it.
The Evidential Problem With Old Records
Article 7(1) requires you to be able to demonstrate that the person consented. In practice that becomes harder with age for reasons unrelated to validity.
A five-year-old consent record usually says who and when. It rarely says what they were shown. The banner has been redesigned twice, the privacy notice rewritten, the purposes reworded, and nobody versioned any of it — so the record can prove an interaction occurred and cannot prove it was informed.
That is a documentation failure rather than a legal one, and it is worth separating because the fix is different. You do not need to re-collect consent because it is old. You need to be able to reconstruct what was on screen at the time, which means storing the version of the wording alongside the timestamp, and keeping old versions.
If you cannot do that for existing records, say so internally, and decide deliberately whether to re-collect or to move the processing to a basis you can actually evidence. What you should not do is treat an unversioned record as though it demonstrates something it does not.
How To Think About Refreshing
Refresh on change, and review on a cadence.
On change is the real trigger. New purpose, new recipient category, materially rewritten notice, a shift in what the processing does. That is when existing consent stops covering the activity and re-collection is genuinely required.
On a cadence is hygiene rather than obligation. An annual review of what you hold consent for, what it says, and whether it still matches the processing is reasonable for most companies, and it is one of the recurring jobs that has to land on someone rather than being nobody's.
There is a trap in re-permission campaigns worth naming, and it has a precedent. Emailing a dormant list to ask people to re-confirm is itself processing, and if the original consent was invalid you have no basis for the email either.
In March 2017 the ICO fined Flybe £70,000 for sending 3,333,940 emails titled "Are your details correct?" to people who had already opted out, and Honda £13,000 for 289,790 emails asking customers to clarify their marketing preferences. Both argued the messages were service emails sent to help them comply. The ICO held that an email asking whether someone wants marketing is itself marketing, and that both had therefore breached the electronic marketing rules. The enforcement head's summary was that businesses cannot break one law to get ready for another.
Note the statute: those were fines under the UK's electronic marketing regulations rather than under data protection law, which is a distinction worth keeping straight. The lesson transfers regardless. If consent was never valid, a campaign to renew it compounds the problem rather than resolving it.
When Consent Was The Wrong Basis All Along
A large share of "does our consent expire" questions are really a symptom. The processing has been running for years, the consent record is thin, and the underlying discomfort is that consent was never the right basis.
That is worth examining directly rather than papering over with a refresh. If the processing is necessary to deliver a contracted service, contract is the basis and consent was never needed. If it is ordinary business processing a reasonable person would expect, legitimate interests with a documented assessment is usually the right home. Consent belongs where the person genuinely has a free choice — and that condition is harder to satisfy than most teams assume.
Changing basis is not something to do casually, because the rights attached differ and switching retrospectively alters what someone could have exercised. But correcting a basis that was wrong from the start, deliberately and with a record of the reasoning, is better than maintaining an expensive consent apparatus that was never load-bearing.
One boundary: none of this touches the separate ePrivacy consent required to store or read information on a device. That requirement has its own logic, and reconsidering your Article 6 basis does not remove it.
Common Mistakes With Consent Expiry
Adopting an arbitrary expiry period. A twelve-month rule is not in the regulation. It creates work where nothing changed and misses the cases where the purpose shifted in month three, which are the ones that actually matter.
Treating age as the problem. Old consent for unchanged processing, properly collected and properly evidenced, is still valid. Recent consent for processing that has quietly expanded is not. Time is the wrong axis.
Running a re-permission campaign on invalid consent. If the original consent did not support contacting these people, it does not support contacting them to ask about consent. This has produced enforcement action, and it is entirely avoidable.
Storing the timestamp and not the wording. Article 7(1) requires you to demonstrate valid consent, which includes that it was informed. Without the version of what was shown, the record cannot do that, and no amount of refreshing fixes historical gaps.
Refreshing instead of reconsidering. If you find yourself renewing consent for processing the person cannot realistically refuse, the answer is not a better renewal cycle. It is that consent was the wrong basis and something else should be carrying the processing.
FAQ
How long is GDPR consent valid for?
For as long as it accurately describes the processing, the person has not withdrawn it, and you can still demonstrate it was validly given. There is no maximum in the regulation. Any specific figure you find has been supplied by whoever wrote the article rather than by the law.
Do we need to re-collect consent if we change our privacy notice?
It depends on whether the change is material to what people agreed to. Fixing typography or restructuring for clarity does not affect validity. Adding a purpose, a recipient category or a transfer does, because the consent was specific to what was described. The test is whether someone who agreed to the old wording would recognise the new processing.
What if we cannot tell what people were shown when they consented?
Then you cannot demonstrate the consent was informed, and you should treat that as a gap rather than assume it holds. Decide deliberately whether to re-collect properly, or whether another lawful basis genuinely applies to that processing. Start versioning your consent wording now so the problem stops growing.
Does withdrawal delete the data?
Not automatically — they are separate rights. Withdrawal stops further processing based on that consent going forward, and does not affect the lawfulness of processing already carried out. Erasure is a distinct request under Article 17, though in practice a withdrawal often triggers one, and you should be clear with people about which they are exercising.
Closing Thought
The search for an expiry date is really a search for a rule that would let this be handled without thinking about it — set a period, schedule a job, stop worrying. The regulation declines to provide one, and that refusal is consistent with everything else in it: you are not given a threshold to clear, you are made accountable for a position you can defend. Consent does not go stale on a schedule. It goes stale when the company changes and the consent record does not, which is a governance problem wearing a legal costume.
Which means the useful artefact is not a renewal calendar but a versioned record of what people were told and when. ComplyDog provides a cookie consent banner alongside a compliance portal on your own domain covering your DPA, subprocessor list, data subject request handling and security page. It does not audit whether your existing consents were validly collected or decide whether consent was the right basis in the first place — and on this question, those are the two things actually worth doing.
