The Policy Has to Describe Your Site, Not a Template
Most cookie policies are copied from a generator, list cookies the site doesn't use, and omit the three trackers a marketing plugin added last quarter. That's not a technicality. A policy that misrepresents your processing is a compliance problem in its own right, because the whole point of the document is to tell visitors accurately what runs on their device. So the first rule is simple: write the policy from your actual cookies, not from a template.
That means you start with an inventory. If you haven't built one, do a cookie audit first. The policy is the human-readable output of that audit. And to be clear on scope, a cookie policy is a distinct document from a privacy policy, though they're related, see cookie policy vs privacy policy.
What Every Entry Needs
Regulators (the ICO and CNIL are the clearest) expect a cookie policy to let a visitor understand each tracker before deciding. For every cookie or similar technology, record:
- Name, the cookie or storage key (for example
_ga). - Provider, who sets it, and whether it's first-party (your domain) or third-party.
- Purpose, in plain language, what it does and why.
- Category, strictly necessary, functional, analytics, or marketing.
- Duration, session, or a concrete expiry. CNIL guidance caps tracker lifetime at 13 months for consent, so a two-year analytics cookie is worth questioning.
Third parties need naming, not a vague "we use advertising partners." The ICO expects you to identify who they are and what they do with the data. Where the list is long or changes often, a linked, regularly updated third-party list is acceptable.
Building the policy
Scan first
Run an automated scan and a manual DevTools pass so the policy starts from what the site actually loads today. Cover every template, because checkout, article, and account pages set cookies the homepage never touches.
Categorize honestly
Sort each tracker into a category. Don't file analytics under strictly necessary to dodge consent, that's the single most common way policies (and banners) fail.
Build the cookie table
Turn the inventory into a table with a row per cookie and columns for name, provider, purpose, category, and duration. This is the core of the document.
Explain choice and withdrawal
State how visitors accept, reject, and change their mind later. Link to the banner's preferences panel so withdrawal is one click, not an email.
Add context and date it
Briefly explain what cookies are, cover local storage and tracking pixels as well as HTTP cookies, and show a last-updated date so the policy's freshness is visible.
Publish and link it
Link the policy from the banner and the footer. A policy nobody can find isn't doing its job.
The Cookie Table
The table is what regulators and diligent visitors actually read. Keep it scannable:
- One row per cookie, grouped by category so a reader can see all analytics cookies together.
- Plain-language purposes. "Distinguishes users for analytics" beats "Google Analytics tracking cookie."
- Real durations, taken from the cookie's actual expiry, not guessed.
- Provider links where a third party publishes its own cookie documentation.
If you maintain the inventory in a CMP, the table can be generated from live scan data and embedded, so it updates itself instead of drifting the day after you publish.
The Word "Cookie" Undersells What You Cover
Article 5(3) of the ePrivacy Directive talks about storing or accessing information on a device, and that's broader than HTTP cookies. Your policy should account for the other techniques your site uses:
- Local and session storage. Many analytics and preference tools store data here instead of in cookies. It's still trackable storage on the user's device.
- Tracking pixels. A 1x1 image or a fetch beacon can transmit data without setting a cookie at all, so a cookie-only list undercounts your marketing footprint.
- Device and browser fingerprinting. If any tool identifies visitors by combining device signals, that's within scope and should be disclosed.
- SDKs and embeds. Video players, maps, chat widgets, and social embeds each bring their own storage. List what they set, or use click-to-load so they set nothing until consent.
Calling the document a "cookie policy" is fine, the convention is well understood. Just make sure the contents describe every tracking technology, not the literal cookie jar alone.
A Policy That Drifts Is a Policy That Lies
Cookie inventories change constantly. A new plugin, an updated third-party script, a fresh ad pixel, and your hand-written list is wrong. A stale policy that lists cookies you dropped or omits ones you added misrepresents your processing, which is worse than a thin policy. Generate the table from a continuous scan and let drift detection flag new trackers, rather than promising to update a static document you'll forget.
Cookie policy checklist
Built from a real scan, not a template
The policy matches what the live site loads today.
Every entry has name, provider, purpose, category, duration
Enough for a visitor to make an informed choice.
Third parties are named specifically
Not "advertising partners" but the actual vendors.
Durations are honest and justified
CNIL expects tracker lifetime limited to what's necessary, 13 months for consent.
Withdrawal is explained and one click
Link straight to the preferences panel.
The policy is dated and kept in sync
Regenerate from scan data so it doesn't drift.
Match the Policy to the Enforcement
An accurate policy means little if the banner doesn't enforce what it describes. Pair a scanner-generated cookie policy with a banner that blocks scripts before consent, and keep both in step as your inventory changes. Then confirm the whole setup against the GDPR compliance checklist.