The hard part is the table, not the wording
Every cookie policy on the internet has roughly the same prose. What separates a real one from a copied one is whether the list of cookies is true.
A table taken from a template lists cookies you do not set and misses the ones you do. It is wrong in both directions at once, and it is the part anybody checking would actually look at.
The only way to write a true one takes ten minutes: open your own site, press F12, and read the Application tab. This page will not pretend it can know what your site does.
"Clear and comprehensive" is a standard, not a vibe
Schedule A1 asks for clear and comprehensive information before anything is stored on a visitor's device. Comprehensive means each cookie has a name, an owner, a purpose and a lifetime against it.
"We use cookies to improve your experience and analyse traffic" satisfies none of that. It is the most common sentence on the internet and it tells a reader nothing they could act on.
Three tiers, and only one of them needs a banner
This is where a policy generator earns its place, because the tier decides whether you have more work to do.
Strictly necessary. Sessions, baskets, security, the cookie remembering a consent choice. Nothing needed beyond telling people.
Preferences and first-party statistics. Notice and a simple opt-out, but no prior consent, provided what they collect is not shared with third parties.
Everything else. Advertising, third-party analytics, embeds. Opt-in, and they must not fire until somebody says yes.
The third-party line decides your analytics
The statistics exception has a condition on it and the condition does the work: the information must not be shared with third parties.
Self-hosted analytics stays inside that. Google Analytics does not, because sending the data to Google is sharing it with a third party. Identical numbers, identical purpose, different tier entirely, decided by where the data ends up rather than what it is for.
Free hosted analytics is generally free because the data is the payment, which is worth keeping in mind while deciding which of the two you have.
A policy does not stop anything
If anything on your list is in the opt-in tier, this document on its own leaves you exposed. Not because the wording is wrong, but because regulation 6 is about not storing information until the conditions are met, and prose does not do that.
What does is a banner that holds the tags back by never putting them on the page. That is a separate tool and it produces one file you paste in, with no library and nothing metered.
It goes stale without anybody noticing
A cookie policy is accurate on the day it is written and starts drifting immediately.
Somebody embeds a map. Somebody adds a chat widget. Somebody pastes a new tracking tag in for a campaign and forgets to take it out. None of those people think about the cookie policy, and there is nothing in a website that reminds them.
Twice a year, open the Application tab and compare it with what you published. It takes ten minutes and it is the only maintenance this document has.
Common questions
What does a cookie policy have to say?
Schedule A1 to PECR wants clear and comprehensive information before anything is stored on somebody's device. In practice that means naming each cookie, saying who sets it, what it is for and how long it lasts. "We use cookies to improve your experience" is neither clear nor comprehensive, and it is the commonest sentence on the internet.
Is a cookie policy enough on its own?
Only if everything you set is in the tiers that do not need prior consent. A policy is disclosure: it describes what you set and it does not stop anything being set. If you run advertising, third-party analytics or embeds, those must not fire until somebody agrees, which needs a banner that genuinely holds the tags back. The policy is the easier half and the half people mistake for the whole.
How do I find out what cookies my site actually sets?
Open your own site, press F12, and look at the Application tab. That takes ten minutes and it is the only way to write a true policy. Copying a table from a template gives you a document that lists cookies you do not set and misses the ones you do, which is wrong in both directions.
Do I need consent for analytics?
It depends where the data goes. Schedule A1 allows statistics about how a service is used, on notice and an opt-out rather than prior consent, but only where the information is not shared with third parties. Self-hosted analytics can meet that. Google Analytics cannot, because sending the data to Google is sharing it with a third party. Same numbers, same purpose, different tier.
What if everything I set is essential?
Then you need this policy and nothing else: no banner, no consent, no opt-out. It is a genuinely good position and very few sites are actually in it, so it is worth double checking. Embedded video, embedded maps and externally hosted fonts are the usual things quietly loading on a site somebody believes is cookie-free.
How often does it need updating?
Whenever the site changes, which is more often than anyone remembers. A policy goes stale the moment somebody adds a chat widget, an embedded map or a new tracking tag, and nobody thinks about the policy while they are doing it. Re-reading the Application tab twice a year takes ten minutes and is the only thing that keeps it true.