How to write a cookie policy

A cookie policy explains which cookies run on your site, what they are used for, how long they last, and what choices visitors have over them. Under the GDPR and the ePrivacy rules it is the standard way to meet your transparency duties for cookies, and regulators such as the ICO treat it as a baseline expectation.

The most common problem in practice is not a missing policy. It is a policy adapted from another website that has nothing to do with the cookies actually set. When a complaint or an audit lands, the first check is always the same: does the published list match what the site really does?

This guide walks through writing a cookie policy that matches reality: inventory first, then classification, then the text itself.

Is a cookie policy a separate document, and is it required?

No law demands a document with the exact title "cookie policy". What the law demands is transparency about personal data processed through cookies, and consent before non-essential cookies are set. The cookie policy is simply the established way to deliver the transparency half.

Keeping it as a separate document is still the right call, for a practical reason: the cookie list changes far more often than the rest of your privacy documentation. When marketing adds a new pixel, you update one page instead of reworking the whole privacy policy.

The relationship with the privacy policy should be clear: the privacy policy covers all of your processing, the cookie policy details the cookie-specific part. They may reference each other, but neither replaces the other.

Start with an inventory: which cookies actually run on your site?

A cookie policy starts with an inventory, not with a text editor. Any policy written without knowing what the site sets is a guess, and guessed policies are almost always incomplete.

You can build the inventory by hand: open the browser developer tools, browse the site, note every cookie stored. Two things are routinely missed this way. First, some cookies only load on specific pages, so checking the home page is not enough. Second, third-party scripts pull in further providers of their own, and the cookies those providers drop are easy to overlook manually.

To automate this step, run a free cookie scan of your site. The scan lists the cookies in use and the third-party services called in the background; the cookie table in your policy is written from that inventory.

Classify cookies correctly

Once the inventory exists, every cookie goes into a category. The established split is four groups:

• Strictly necessary cookies: sessions, security, shopping carts, things the site cannot work without.
• Functional cookies: language or theme preferences, convenient but not essential.
• Performance and analytics cookies: visitor statistics.
• Marketing and tracking cookies: advertising and retargeting.

The most common classification mistake is filing analytics or marketing cookies under "strictly necessary". A cookie is necessary only if the site genuinely breaks without it; measuring traffic or ad performance does not keep a site running. The category matters because it decides whether consent is required.

What the policy must contain

A solid cookie policy covers the following:

• Who the controller is and how to contact them.
• What cookies are and what the site uses them for.
• For every cookie: name, provider, purpose, lifetime, and whether it is first or third party.
• Which categories require consent.
• How visitors give, change and withdraw their preferences.
• Whether third-party providers transfer data outside your visitors' jurisdiction.
• The rights visitors have and how to exercise them.
• The date the policy was last updated.

Present the cookie list as a table. It is easier for readers, and easier for you: an outdated row or a missing cookie is visible at a glance.

The consent connection: the policy informs, the banner asks

Strictly necessary cookies do not need consent; transparency is enough. Analytics, functional and marketing cookies do, as a rule, and the consent must be collected before those cookies are set.

The division of labour is simple: the cookie policy is the information tool, the cookie banner is the consent tool. "By continuing to use this site you accept cookies" is not valid consent; consent needs an active choice, and rejecting must be as easy as accepting.

The categories in the banner and the categories in the policy must match exactly. If the banner asks about "analytics" and the policy never mentions the category, or the policy lists a category the banner never asks about, the two documents contradict each other.

Write purposes and lifetimes concretely

"We use cookies to improve your experience" is not a purpose. A purpose says what the cookie actually does: "keeps you signed in", "collects visit statistics", "limits how often you see the same ad".

Lifetimes get the same treatment. "Persistent" is not a lifetime; write "until the browser closes" for session cookies and the real duration for persistent ones. There is no need to guess: scan results show the actual lifetime of every cookie.

Five frequent mistakes

• Copying another site's cookie list: the policy then describes their site, not yours.
• "By using this site you consent": passive browsing is not consent.
• Inflating the strictly necessary category to move cookies out of the consent flow.
• Vague purposes and lifetimes: "various purposes" and "persistent" empty the text of meaning.
• Never updating the policy: one new pixel and the published list no longer matches reality.

When to update it

A cookie policy is not a one-off task. A conversion pixel added by marketing, an analytics tool a developer tries out, or a third-party provider changing its own infrastructure will age your list without anyone telling you.

The reliable setup is regular scanning with change monitoring: when a new tracking cookie or an undeclared provider appears, the scan tells you the policy needs an update, instead of you having to remember.

Template or from scratch?

A template is a fine starting skeleton; definitions, rights and contact sections vary little between sites. But the heart of the policy, the cookie list, is unique to your site and no template can produce it. The part the template leaves blank is exactly the part that takes the work.

DILAYS combines the two steps: it scans your site to build the cookie inventory, then generates the cookie policy from that inventory. Because the list comes from real scan data, the published policy and the live site agree.

Checklist

• The whole site was scanned and a current cookie inventory exists.
• Every cookie sits in one of the four categories, with a reason.
• The cookie table lists name, provider, purpose, lifetime and party for each entry.
• Purposes and lifetimes are concrete; no vague wording.
• For consent categories, the banner collects consent before cookies are set.
• Banner categories and policy categories match exactly.
• Providers transferring data abroad are named.
• Changing preferences and withdrawing consent is explained.
• The last-updated date is visible.
• A routine exists to catch site changes.