Fylde-Digital-Logo-Final
Contact us
back to all

UK Website Privacy Policy: Article 13/14 Checklist and the Two Sections That Matter

Yes, you need one. If your website collects names, email addresses, IP addresses, or anything that identifies a person, UK GDPR and the Data Protection Act 2018 require a published privacy notice covering who you are, why you’re processing data, what rights people have, and how to complain to the ICO. Start with the ICO’s privacy notice generator or a UK-specific template, and make sure your cookie consent is sorted before you publish.

TL;DR:

  • Privacy notices must detail data collection, sharing, international transfers, and retention periods with specific information, not vague generalities.
  • Non-essential cookies require active user consent before deployment, and consent tools must block scripts until agreement, with clear granular options.
  • Regularly review and update the privacy notice to reflect changes in data flows, processing methods, or legal requirements, especially after system or business model changes.
  • Templates should explicitly reference Articles 13 and 14, separate PECR and cookie consent, and specify data transfer mechanisms for compliance.
  • Technical setup must prevent non-essential scripts before consent is given and match the privacy notice’s disclosures to ensure legal and operational compliance.

Table of Contents

What a UK privacy policy website needs to contain (Article 13 & 14 checklist)

Every privacy notice published in the UK has to answer the same closed set of questions, whether you’re a sole trader selling candles or a 40-person marketing firm. These come from Articles 13 and 14 of UK GDPR, and there’s no small-business exemption from any of them, even if you’re processing a handful of contact form entries a week.

The requirement sounds bureaucratic until you realise it’s really just accountability written down. The ICO treats missing or vague privacy information as one of the most common failings it identifies when reviewing organisations, which tells you this isn’t a box most businesses tick well the first time.

Here’s the annotated checklist, with phrasing prompts you can adapt directly.

  • Controller identity and contact details. State your registered company name, trading name if different, a postal address, and a contact point (email is fine). If you have a Data Protection Officer, name them here too. Example phrasing: “[Business name] of [address] is the data controller for the personal information collected through this website.”
  • Purposes and lawful basis for each one. Don’t lump everything under “to run our business.” List each purpose separately, tie it to a lawful basis (consent, contract, legal obligation, legitimate interests, vital interests, or public task), and be specific: “We process your email address to send order confirmations (contract) and, where you’ve opted in, to send marketing emails (consent).”
  • Categories of data and recipients. Name the types of data you hold (contact details, payment data, browsing behaviour) and who else sees it, such as your hosting provider, CRM platform, or payment processor. A workable line: “We share order data with our payment processor and delivery partner solely to fulfil your order.”
  • International transfers and safeguards. If any of those recipients store data outside the UK, say so and name the safeguard, whether that’s a UK adequacy decision, a UK International Data Transfer Agreement, or the UK Addendum to the EU Standard Contractual Clauses. Example: “Our email marketing platform stores data in the United States under the UK International Data Transfer Agreement.”
  • Retention periods or criteria. Vague phrases like “we keep data as long as necessary” invite scrutiny because they give the reader no way to check you’re actually doing what you claim. State a period (“Customer order data is kept to meet HMRC record-keeping requirements, according to applicable legal standards.”) or a clear criterion if a fixed number doesn’t apply.
  • Data subject rights and the ICO complaint route. Explain, in plain terms, that people can ask to access, correct, delete, or move their data, object to processing, or withdraw consent, and give them a way to do it. Always close with the right to complain to the ICO if they’re unhappy with your response.
  • Automated decision-making and source of data. If you use automated scoring or profiling with legal or significant effect, disclose it and explain the logic in general terms. If you obtained data from somewhere other than the person directly (a marketing list, a public register), Article 14 requires you to name that source.

Pro Tip: Write your purposes and lawful bases as a table inside the notice itself. It forces you to actually decide the lawful basis for each activity, rather than defaulting to “legitimate interests” for everything, which the ICO tends to view as lazy drafting rather than genuine analysis.

Getting this list right matters for more than compliance. A privacy notice that’s specific and easy to find is part of the trust signal that turns a visitor into an enquiry, because uncertainty about what happens to personal data is exactly the kind of friction that makes people abandon a contact form.

A privacy notice and cookie consent solve two different legal problems, and mixing them up is one of the most common mistakes on UK websites. The privacy notice is a transparency document. PECR (the Privacy and Electronic Communications Regulations) is a consent requirement, and it applies specifically to storing or accessing information on someone’s device, which in practice means cookies, tracking pixels, and similar technologies.

Under PECR, non-essential cookies must not be set until the visitor has given valid, informed consent. That rules out banners that fire analytics scripts on page load and just ask forgiveness with an “I accept” button underneath. Consent has to come first.

A minimal cookie table on your site should cover:

  • Cookie name — the technical identifier, e.g. _ga or _fbp.
  • Purpose — what it actually does, in plain English (analytics, ad targeting, session management).
  • Provider — whether it’s set by you (first-party) or a third party like an ad network.
  • Lifespan — how long it persists on the device.
  • Consent required — yes or no, based on whether it’s strictly necessary.

Strictly necessary cookies (keeping someone logged in, remembering a shopping basket) don’t need consent. Everything else does, and that includes most analytics and advertising cookies by default.

Practically, that means your consent tool needs to block non-essential scripts until someone actively agrees, offer granular choices rather than one blanket toggle, and log when and how consent was given so you can prove it later. If you’re setting up analytics for the first time, it’s worth reading through a proper analytics setup guide before wiring tracking into a site that hasn’t got consent logic in place yet.

Test it yourself before you trust it: load the site in a private browser window with cookies disabled, check nothing fires before you click “accept,” then check your analytics dashboard and any ad pixels stop reporting data until consent is logged.

How to create, publish and test a compliant privacy notice

1. Map every data flow on your site. Before you write a word, list every place data enters your business: contact forms, newsletter sign-ups, checkout pages, live chat, CRM imports, marketing lists bought or shared. Ask, for each one: what do we collect, why, who else touches it, and how long do we keep it? Skipping this step is why so many privacy notices read like they were written for a different business.

2. Draft from a UK-specific starting point. Use the ICO’s generator or a UK-focused template, then populate every field with the specifics from your data mapping. Resist the temptation to leave in placeholder text like “we may share your data with third parties” without naming who those third parties actually are.

3. Publish it where people will actually see it. Link the notice from your site footer so it’s reachable from every page, from the cookie banner itself, and directly beside every form that collects personal data. If you’re building a new site or lead-generation page, work the privacy link into the form design from the start rather than bolting it on afterwards, since forms are exactly where GDPR-anxious visitors look for reassurance before typing anything in.

4. Test the live site, not just the draft. Check that non-essential cookies stay blocked until consent, that consent choices are actually logged somewhere retrievable, that every form links to the notice, and that the whole thing reads properly on a phone screen, not just a widescreen monitor in your office.

5. Know when to call in legal review. A generator or template covers the vast majority of UK small business sites well. Escalate to a solicitor or a specialist provider like Practical Law when you’re processing special category data (health, biometric, religious belief), running large-scale profiling, or relying on a complex chain of international data transfers that a standard template can’t realistically capture.

How to create, publish and test a compliant privacy notice — overview diagram

Retention, record-keeping and how to keep your notice defensible

Retention is where most privacy notices fall apart under scrutiny, because “as long as necessary” is not a period or a criterion, it’s an evasion. Tie each retention decision to something concrete: a legal requirement (HMRC generally expects financial records kept for 6 years), an operational need (support tickets closed and deleted after 24 months), or a specific event that triggers deletion (an account inactive for three years).

The privacy notice itself doesn’t need your full internal retention schedule, just the periods or criteria relevant to the reader. Keep the granular version, along with a proper Record of Processing Activities (ROPA), as an internal document that your notice can point to rather than reproduce. The notice says what happens; the ROPA proves you actually thought it through.

  • Review the notice at least annually, even if nothing obvious has changed.
  • Update it immediately when you add a new processor, launch a new service that collects data differently, or switch analytics or CRM providers.
  • Treat a change in the law, such as the Data (Use and Access) Act 2025 adjustments to UK data protection rules, as an automatic trigger for review rather than something to catch up on later.
  • Keep a simple changelog of notice updates. It’s the easiest way to demonstrate ongoing governance if the ICO ever asks.

Which UK privacy policy templates and tools are worth using

For most sole traders and small businesses, the ICO’s own generator is the right place to start. It’s free, built specifically around UK GDPR and DPA 2018 obligations, and gets updated as legislation changes, including recent adjustments under the Data (Use and Access) Act 2025. It won’t handle a genuinely complex business model, but it will get a straightforward website compliant without legal fees.

UK-focused generators beyond the ICO’s own tool often go a step further, building in fields for your ICO registration number, individual lawful bases per purpose, retention periods, and a ready-made cookie table, which saves you assembling one from scratch.

Paid templates or solicitor-drafted notices earn their cost once your business gets complicated: multiple international data transfers, special category data, or a data-sharing arrangement with a group company or franchise network.

Whatever you use, vet it against four things before you trust it:

  • Does it reference Articles 13 and 14 by name, not just “GDPR” in general terms?
  • Does it separate out PECR and cookie consent as a distinct section?
  • Does it name a real UK transfer mechanism (adequacy, UK IDTA, SCC/UK Addendum) rather than a vague “adequate safeguards” line?
  • Was it updated recently enough to reflect current legislation, including the Data (Use and Access) Act 2025?

An agency’s perspective on where privacy notices actually go wrong

The privacy notices Fyldedigital reviews on client sites tend to fail in the same three places: missing Article 13 elements (usually retention and international transfers, the two sections people find hardest to write), cookie banners that technically exist but don’t actually block anything before consent, and retention statements that dodge specifics entirely.

The fix follows a consistent order: audit what data the site actually collects, draft or rewrite the notice against the real data flows rather than a generic template, correct the technical cookie-blocking setup, then test the whole thing live before calling it done. Skipping the audit step is the single biggest reason notices go stale within months of publishing.

Four-stage privacy compliance workflow

If you’re not sure where your own site stands, a free website and privacy review flags the gaps before a visitor, or the ICO, does it for you.

Common privacy policy mistakes on UK websites

The most frequent pitfall is a notice copied from a US or generic international template, complete with references to the California Consumer Privacy Act or a “Do Not Track” clause that has no equivalent under UK law. It reads as compliant to the untrained eye and falls apart the moment anyone checks it against Article 13.

A close second is treating the cookie banner and the privacy notice as the same document. Plenty of UK sites publish a solid transparency notice but still fire third-party analytics before a visitor clicks anything, which breaches PECR regardless of how good the written notice is.

Retention vagueness shows up constantly too: “we retain data for as long as necessary for the purposes outlined” appears on far more UK sites than it should, and it’s precisely the kind of phrasing the ICO flags as inadequate.

Finally, businesses that grow tend to forget the notice needs to grow with them. Adding a new CRM, switching email marketing platforms, or starting to use a US-based transcription tool for customer calls all change what the notice needs to say, and an unreviewed notice from two systems ago quietly becomes inaccurate rather than just outdated.

Tailoring your privacy policy by website type

An e-commerce site carries the heaviest burden: payment data, delivery addresses, order history, and usually a marketing list, all needing separate lawful bases and a proper breakdown of which payment processor and courier see what. If you use a CRM or sales tool to manage customer relationships post-purchase, check how it handles GDPR-relevant data flows before assuming your privacy notice covers it automatically.

A purely informational site, a blog or a local trade site with no checkout, has a much lighter load: usually just contact form data, newsletter sign-up, and analytics cookies. The notice can be shorter, but it still needs every Article 13 element, just with less to say under each one.

Membership sites sit in between. Beyond basic contact details, they typically hold login credentials, payment details for subscriptions, and sometimes profile information members set themselves. That means an extra section on account data specifically, plus clarity on what happens to a member’s data when they cancel, since “what happens when I leave” is one of the first questions a departing member actually wants answered.

What actually matters most in a UK privacy notice

Most privacy policy advice online treats this as a copy-paste exercise: grab a template, swap in your company name, done. That’s how you end up with a notice that technically exists but says nothing true about your actual data flows, which is worse than having a slightly rough one that’s accurate.

The conventional advice underweights retention and international transfers specifically, because they’re the two sections that require you to actually know your own systems rather than fill in generic legal language. Get those two right and the rest of the notice tends to follow, because you’ve already done the hard part: mapping what happens to data once someone hands it over.

If you do only one thing after reading this, make it the data-flow map from the how-to section above. Everything else in your notice, and honestly your cookie consent setup too, gets easier once you know exactly what you’re disclosing and why.

— tibor

Get a privacy-ready website built properly the first time

Fyldedigital is the practical alternative to hiring a solicitor for every clause and hoping a bolt-on cookie plugin covers the rest. We build the privacy notice, the cookie consent logic, and the site itself as one job, so the forms, the banner, and the footer link all agree with each other from day one, instead of three separate contractors half-fixing three separate pieces.

Fyldedigital

That matters most at the two points most UK sites get wrong: the technical cookie block actually stopping non-essential scripts before consent, and the retention wording matching what your systems genuinely do rather than a generic phrase pasted in from elsewhere. We audit first, draft the notice against your real data flows, fix the technical setup, then test it live before we call it finished, the same process outlined above, applied to your actual website rather than a hypothetical one.

If you’re not sure whether your current site would survive that audit, request a free website review and we’ll tell you exactly what’s missing and what it would take to fix it.

Where to check the rules yourself

This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.

Sources

Some More Cool Projects