Storage Limitation Is a Rule, Not a Suggestion
The GDPR gives you six words that decide this whole topic: keep personal data no longer than necessary. That's the storage limitation principle in Article 5(1)(e). Cookies collect personal data, online identifiers, device details, browsing behaviour, so the data they generate falls squarely under it. If a regulator asks how long you keep it and why, "we've never deleted anything" is the wrong answer.
Most teams set up a consent banner, categorise their cookies, and stop there. Retention is the part that gets skipped, partly because it involves two separate clocks that are easy to confuse. Get them straight and the rest is bookkeeping.
Two Clocks: Cookie Lifespan vs Data Retention
The first clock is the cookie's own lifespan, the expiry you set with the cookie's max-age or expires attribute. A session cookie dies when the browser closes. A persistent analytics cookie might be set to live for months. This clock controls how long the identifier sits on the visitor's device.
The second clock is how long you retain the data the cookie feeds. An analytics cookie identifies a returning visitor, but the events it generates land in your analytics backend and your server logs, and those can be kept on a completely different schedule. You could delete the cookie tomorrow and still be holding two years of behavioural records tied to it.
A retention policy has to name both. It's common to see a site advertise a tidy 13-month cookie lifespan in its cookie policy while quietly retaining the underlying analytics data for years. That gap is exactly what an auditor picks up on.
The CNIL's Concrete Numbers
France's regulator, the CNIL, publishes benchmarks worth borrowing even outside France: a tracker's lifespan should be capped at 13 months, the data collected through it retained for at most 25 months, and consent itself refreshed periodically, with six months cited as good practice. These aren't hard limits everywhere, but they give you defensible defaults instead of round numbers you picked because they felt right.
What the Numbers Look Like in Practice
Default cookie lifespans and what regulators expect don't always line up. Google's _ga cookie is set to last two years out of the box, while the CNIL would prefer you cap analytics trackers at 13 months. When defaults and guidance disagree, the safer move is to shorten, then document why.
| Cookie / tool | Default cookie lifespan | Underlying data retention | Notes |
|---|---|---|---|
| Google Analytics (_ga) | 2 years by default | GA4 event/user data: 2 or 14 months (up to 50 on 360) | CNIL suggests capping the cookie at 13 months |
| Meta Pixel (_fbp) | ~90 days | Held by Meta per its terms | You are a controller for the ad targeting you enable |
| Session / cart cookie | Session or short | Order data kept per your commerce and tax rules | Necessary function, but scope the retention |
| Consent record | Stored client-side plus server log | As long as you rely on the consent, plus a limitation period | A different clock again, see below |
Setting GA4 Data Retention (the setting most people miss)
Google Analytics 4 ships with data retention set to two months. Under Admin > Data settings > Data retention you can raise event and user data to 14 months on a standard property, or up to 50 months on Analytics 360. Two things bite people here. The change isn't retroactive, so if you leave the default and later switch to 14 months, you don't get the missing history back. And the setting only governs the granular, explorable data; aggregated standard reports persist longer. Pick your retention deliberately when you create the property. Google documents the behaviour in the GA4 data retention help page.
Consent Records Have Their Own Clock
Here's a trap: teams apply the same short retention to their proof-of-consent logs that they apply to marketing data, then can't prove consent when challenged. Consent records aren't the data you minimise aggressively. You keep them for as long as you're relying on that consent, plus a reasonable window to defend a legal claim after the relationship ends. "Forever" is wrong, but so is deleting the receipt the day the cookie expires. We cover the record itself in proof of consent under GDPR and consent logging and audit requirements.
Delete Means Delete, Including Backups
A retention period only counts if data actually leaves your systems at the end of it. That includes copies in data warehouses, exports to spreadsheets, and backups. You don't have to shred a backup the instant a record expires, but your policy should say how backup data ages out and confirm that a restore doesn't quietly revive records you were supposed to delete.
Writing a Retention Schedule
A retention schedule is a table your future self and a regulator can both read. One row per data category, each answering the same questions. It doesn't need a lawyer to draft, it needs someone who knows what data you actually collect, which is why it starts from a real cookie inventory rather than a template.
Each retention-schedule row should name
The data category and its purpose
For example: analytics events for traffic measurement, or ad-click data for campaign attribution.
The legal basis
Consent for non-essential trackers; legitimate interests or contract only where genuinely applicable.
The cookie lifespan
The max-age you set on the client-side cookie itself.
The backend retention period
How long the collected data lives in analytics, your warehouse, and logs.
The deletion method and trigger
Automated expiry, a scheduled purge job, or a manual review date.
The owner
The person or team accountable for enforcing that row.
Start From Real Data, Not Guesses
A retention schedule is only as honest as the inventory behind it. A cookie scan surfaces every cookie on your site and its declared duration, so you're scheduling retention against what's actually set, not what a plugin's docs claim. CookieBeam pairs that inventory with consent logs, so the two clocks, the trackers and the consent behind them, live in one place instead of scattered across tools. Review the schedule whenever a scan flags a new cookie.