Stop juggling agencies. Start dealing with one.
Stop juggling agencies. Start dealing with one.
Get your free consultation

Audit, Block, Record: 3 Step GDPR Cookie Consent Checklist for UK

You must not set non-essential cookies for UK visitors before obtaining UK GDPR-standard consent under PECR. That means a banner with equally prominent accept and reject options, non-essential scripts blocked until someone actively chooses, and a dated record of what they agreed to. Do those three things and you have solved most of the problem.


TL;DR:

  • Cookies that are strictly necessary, such as those for logging in or processing transactions, are exempt from active consent requirements under UK law.
  • Consent must be active, granular, and recorded, with no pre-ticked boxes or implied acceptance through browsing or scrolling; the burden of proof is on the site owner.
  • Scripts that are not strictly necessary should only fire after a user’s explicit consent signal, with non-essential cookies blocked until then and tested thoroughly across devices and browsers.
  • Consent records must be stored separately from cookies and kept accurate to ensure compliance, especially when purposes or third-party vendors change.
  • Embedded third-party content like videos and social media widgets should default to no-cookie modes or be loaded only after consent to prevent premature tracking.

Hook-digital
Build A More Compliant Website
Hook-digital brings websites, SEO, social media, design and other marketing needs together through one Oxfordshire-based agency.
Explore Hook-digital

Table of Contents

Two laws govern this, and they pull in the same direction. The Privacy and Electronic Communications Regulations (PECR) deal specifically with cookies and similar tracking technologies. Regulation 6 of PECR says you must tell people if you’re setting cookies, explain what those cookies do, and get their consent before you set anything that isn’t strictly necessary. The ICO’s guidance on cookies and similar technologies is unambiguous on this point.

Where PECR says you need consent, it borrows the definition from UK GDPR rather than inventing its own. Article 4(11) defines consent as a freely given, specific, informed and unambiguous indication of the person’s wishes, given by a clear affirmative act. Article 7 adds that you must be able to demonstrate consent was given, and that withdrawing it must be as easy as giving it. In plain terms: a user has to actively say yes to something specific, and you need to be able to prove they did.

Not every cookie needs this treatment. Strictly necessary cookies are exempt, covering things like session cookies that keep someone logged in, basket cookies on an ecommerce checkout, and load balancing or security cookies that keep the site functioning. The exemption is narrow. Analytics cookies, personalisation cookies, and anything feeding an advertising platform almost never qualify, whatever a plugin’s default settings suggest.

The legal backdrop is also shifting. The Data Use and Access Act 2025 introduces some changes to the wider data protection landscape, and Gov is worth bookmarking if you want to track which provisions are live. Cookie consent rules under PECR haven’t been swept away by this, but expect incremental updates rather than a single big bang.

Run your current banner against this before you assume it’s compliant. Most failures the ICO documents are variations on the same handful of mistakes.

  • No pre-ticked boxes for anything beyond strictly necessary cookies.
  • No implied consent through continued browsing, scrolling, or simply closing the banner.
  • Separate, granular toggles for separate purposes (analytics, advertising, personalisation), not one blanket “accept all” switch dressed up as choice.
  • Clear disclosure before consent of what each cookie does, which third parties receive data, how long it’s retained, and who the data controller is.
  • A record for every user showing what they agreed to, when, and how.

The EDPB’s guidance on consent is explicit that cookie walls, where a visitor can’t access a site at all without accepting tracking, do not produce freely given consent. Neither does a banner that only tracks scrolling as an “accept” signal. Both patterns show up repeatedly in ICO enforcement correspondence, which tells you they’re common mistakes, not rare edge cases.

Demonstrability matters more than most site owners assume. It isn’t enough to have offered a fair choice. You need to be able to show, months later, exactly what a specific user consented to and when, because the burden of proof sits with you, not the visitor.

Pro Tip: Screenshot or archive every version of your banner copy alongside your consent logs. If your wording changes, you need to know which version a given user actually saw when they made their choice.

Design and engineering fail this together more often than copywriting does. A well-worded banner sitting on top of scripts that fire regardless of the user’s answer is still non-compliant.

Structure the banner in two layers. The first layer is short: what you use cookies for, a link to full details, and two buttons of equal visual weight, one to accept and one to reject. The second layer, reached by clicking “manage preferences” or similar, breaks consent down by purpose, so someone can accept analytics but reject advertising. The GOV.UK Design System’s cookies page pattern is a genuinely useful reference for getting this layering right without over-engineering it.

  1. Audit every script currently firing on page load and tag each one as strictly necessary or not.
  2. Wrap non-essential scripts (analytics, ad pixels, embedded video trackers) so they only fire after a matching consent signal.
  3. Build or configure the banner with accept and reject buttons of identical size, colour weight and position.
  4. Test with browser developer tools open on the network tab, confirming nothing third-party fires before you click accept.
  5. Re-test on mobile separately. Banners that render correctly on desktop frequently push the reject option off-screen on smaller viewports.
  6. Check that rejecting cookies doesn’t quietly get overridden on a page reload or a different entry page.

The most common ICO findings involve non-essential cookies firing before any consent decision, a missing or buried reject button, or a site that ignores a rejection and keeps tracking anyway. ICO assessment letters sent to organisations cite exactly these three issues repeatedly.

Pro Tip: Test your banner in an incognito window with your ad blocker off. It’s the fastest way to spot scripts firing early, because you’ll see requests to third-party domains in the network tab within seconds of the page loading.

Record-keeping, retention, and handling withdrawals

Every consent decision needs a record that stands up months or years later. At minimum, log the timestamp, the version of the banner shown, the exact choices made per purpose, and the method used to capture consent (a click on a specific button, for instance, not an assumption from inactivity).

  • Store consent records separately from the cookies themselves, so they survive even if a user clears their browser.
  • Most consent management platforms set a default expiry, often six or twelve months, after which they re-prompt automatically.
  • The ICO doesn’t mandate a fixed refresh interval, but treats consent as stale once purposes, third parties, or the nature of processing change materially.
  • On withdrawal, stop the relevant processing immediately, delete data gathered under that specific consent where feasible, and notify any third party who received it.
  • Trigger fresh consent whenever you add a new purpose or a new third-party recipient, rather than assuming existing consent stretches to cover it.

Guidance from the ICO’s PECR and cookies documentation treats withdrawal as functionally equivalent to never having consented in the first place: you’re expected to unwind the processing, not just stop starting new instances of it.

A dedicated consent management platform earns its cost once you’re running more than a handful of third-party scripts, need per-purpose granularity, or operate across multiple domains that should share consent state. A lightweight custom banner can work for a simple site with two or three trackers, provided someone maintains the script-blocking logic as tools get added.

Whichever route you take, check for these before committing:

  • Genuine script blocking, not just a banner overlay sitting above scripts that still fire.
  • Auditable, exportable consent records tied to individual users or sessions.
  • Per-purpose toggles rather than a single accept-all switch.
  • Clear terms on where consent data is processed and stored, since that affects your own data protection documentation.

Ask any CMP vendor directly how their default configuration handles a rejection, because misconfigured “reject all” buttons that still permit certain vendors to fire are a documented ICO finding, not a theoretical risk. Dark patterns, such as making reject visually recessive or requiring extra clicks to decline, invite exactly the enforcement attention you’re trying to avoid.

Pro Tip: During CMP procurement, ask for a live demo where you personally click reject and then check the network tab. If the vendor can’t show you that in the demo, that’s your answer.

Hook-digital runs the same sequence on every site: cookie discovery to catalogue what’s actually firing, consent architecture to map purposes and third parties, then blocking tags implemented so nothing non-essential loads before a decision, followed by CMP configuration and verification testing before handover. Where a site relies on Google Ads or analytics, we integrate consent signals directly with conversion tracking so measurement stays intact without ignoring a visitor’s choice. Clients leave with consent records, dated banner copy versions, and documentation they can hand to their own compliance team.

Pro Tip: The UX and the compliance requirement aren’t in tension if you design the banner properly. A clean two-layer approach satisfies both a design brief and a legal one.

Sites likely to be accessed by children under 18 fall under the ICO’s Age Appropriate Design Code, which sits alongside standard cookie consent rules rather than replacing them. If your service is likely to reach children, default settings should favour privacy: non-essential cookies off by default, with any opt-in language written in terms a younger user can genuinely understand rather than dense legal phrasing borrowed from an adult-facing policy.

Consent given by a child raises a genuine question of whether it’s informed, given how the standard specifically requires the person to understand what they’re agreeing to. Where a site’s audience plausibly includes under-13s, the safer approach treats analytics and advertising cookies as off until an adult or a clearly informed decision confirms otherwise, rather than assuming the standard adult consent flow covers everyone equally. This matters most for education, gaming, and family-oriented ecommerce sites, where the audience mix isn’t hypothetical. If your site isn’t designed for children but occasionally attracts them, plain, simple banner language still serves everyone better than legal boilerplate.

Embedded social media widgets, YouTube or Vimeo videos, and third-party maps almost always set cookies the moment they load, independent of anything your own CMP controls. A YouTube embed, for instance, can drop tracking cookies before a visitor has made any choice at all, because the request goes straight to Google’s servers on page render.

The fix is to hold the actual embed back behind a placeholder image or a “click to load” prompt until consent for that category is given, rather than trusting the embed’s own settings. Most video platforms offer a privacy-enhanced or no-cookie embed mode that reduces tracking prior to interaction, and it’s worth defaulting to that mode even after consent, since it lowers the number of third-party requests overall. Social media share buttons carry the same issue and are frequently overlooked because they look decorative rather than functional. Audit every embed on a page as carefully as you audit your own analytics scripts, because from a consent standpoint they’re the same risk.

Third-party embed consent flow diagram

A cookie policy isn’t a static document you publish once. Update it whenever you add a new tracking purpose, bring on a new third-party vendor, or change how long you retain data, because the disclosure obligations under PECR require the policy to reflect what’s actually happening on the site at any given time.

Material changes, such as adding a new advertising partner or introducing a tracking purpose that didn’t exist before, should trigger a fresh consent prompt rather than a quiet policy edit. A dated changelog or a simple “last updated” line at the top of the policy gives users and regulators a clear reference point. For smaller changes, such as correcting a retention period that was stated incorrectly, updating the published policy without re-prompting every user is usually reasonable, provided the underlying processing hasn’t changed. The test is always whether the change affects what a user previously agreed to; if it does, treat their existing consent as no longer valid for that purpose.

Post-Brexit transitional rules: how UK GDPR and PECR actually diverge from the EU now

UK GDPR is the retained, domesticated version of the EU General Data Protection Regulation, adapted after Brexit to function as standalone UK law. PECR remained UK law throughout and was never an EU regulation directly, so its cookie consent requirements didn’t change at the point of exit. What did change is that the UK is now free to amend its own framework independently of Brussels, and the Data Use and Access Act 2025 is the clearest example of that divergence starting to take shape.

For most site owners this means the practical consent standard, active opt-in, granularity, demonstrability, hasn’t shifted from what applied before Brexit. What has changed is the direction of travel: the UK can now diverge from EU interpretations, including EDPB guidance, at its own pace. The ICO still references EDPB positions as persuasive authority, as seen in its treatment of cookie walls, but it isn’t bound to follow every future EU update. Anyone running a site that serves both UK and EU visitors should treat these as two related but separately evolving frameworks and check GOV.UK’s official commencement guidance periodically rather than assuming EU and UK rules will stay perfectly aligned.

Consent given on one domain doesn’t automatically transfer to a different domain, even one owned by the same company, unless the two sites share a consent management setup specifically built to synchronise that state. A visitor who accepts analytics cookies on your main site and later lands on a separate microsite or subdomain may need to make the choice again, depending on how your CMP is configured.

Cross-device synchronisation is trickier still. There’s no reliable technical mechanism that recognises the same person across a phone and a laptop unless they’re logged into an account that ties the sessions together, so most consent choices are inherently tied to a single browser on a single device. Design your architecture with that limitation in mind rather than promising users a seamless cross-device experience you can’t actually deliver. For multi-domain operations, a shared CMP configuration with a common consent string, stored against a first-party identifier where possible, is the standard approach, though it still resets whenever someone switches device or clears cookies.

Why getting this right protects more than your compliance record

Clear, honest consent choices lower your enforcement exposure and build the kind of trust that keeps visitors coming back. First-party measurement built on consent that people genuinely gave outlasts any short-term tracking workaround, because workarounds eventually break when browsers or regulators close the loophole. Treating this as an investment in your measurement strategy, not a legal chore, tends to pay off longer than treating it as a box to tick.

— Hook

Hook-digital treats a cookie consent audit the way it treats every technical project: one team handles the legal review, the banner build, the tag configuration and the testing, rather than you juggling a developer, a designer and a compliance consultant separately. That matters here specifically because most consent failures sit at the join between good copy and bad script implementation, and having one team accountable for both closes that gap. If your current banner has never had its network requests checked against what it claims to block, that’s the first thing worth fixing.

Hook-digital

A short engagement typically starts with a cookie discovery audit across your site, moves into consent architecture and blocking tags, then finishes with CMP configuration, verification testing and full handover documentation, including consent records and dated banner copy versions your team can maintain going forward. This work sits comfortably alongside a broader website design and development project if your site needs other attention at the same time, or it can run as a standalone fix through Hook-digital’s WebBuilds service. Get in touch to request a cookie audit and a clear quote for putting it right.

Sources

FAQ

Yes. Under Regulation 6 of PECR, you need consent before setting any cookie that isn’t strictly necessary, and that consent must meet the UK GDPR standard of being freely given, specific, informed and unambiguous. Strictly necessary cookies, such as those keeping a checkout basket working, are exempt.

UK GDPR itself doesn’t mention cookies directly. It supplies the consent definition and standard that PECR then applies specifically to cookies and similar tracking technologies, so the two work together rather than either one covering the whole requirement alone.

There’s no single new rule replacing the existing standard. The Data Use and Access Act 2025 is adjusting the wider data protection landscape gradually, and GOV.UK’s commencement guidance tracks which provisions are actually in force. The core requirement, active consent before non-essential cookies, hasn’t changed.

Does GDPR apply to the United Kingdom?

Yes, in the form of UK GDPR, the retained version of the EU regulation adapted into domestic law after Brexit. It applies alongside PECR to any organisation processing personal data or setting cookies for UK visitors, regardless of where the organisation itself is based.

0
1
2
3
4
5
6
7
8
9
0
0
1
2
3
4
5
6
7
8
9
0
0
1
2
3
4
5
6
7
8
9
0
%