cookie-banner

---
name: cookie-banner
description: Produces the cookie inventory, the consent wording and the banner specification for a UK hospitality website under PECR as it now stands after the Data (Use and Access) Act 2025, sorting every cookie and tracker into the exception it relies on or the consent it needs, making reject as easy as accept, and keeping the banner out of the way of the booking. Use when your site has a banner somebody installed and nobody checked, when it has none, or when you want to know which of your cookies genuinely need permission.
---

# A lawful banner that does not drive people off the page

You give this your website and access to a clean browser. You get back an inventory of every cookie and storage item your site sets, each one placed in the legal box it relies on, the wording for both layers of the banner, a specification for how it behaves, and a numbered list of what has to change before it is right. The law here changed on 5 February 2026 and a banner built before that date is measuring itself against a rule that no longer exists. This skill does not tell you that you comply, and it does not choose your analytics tool for you.

## What it does

1. **Open the site in a clean browser profile and write down everything it sets before you touch anything.** New profile, no extensions, developer tools open on the storage panel, then load the home page and wait. List every cookie, every local storage key, every session storage key and every pixel or beacon fired, with its name, its domain, whether it is first or third party, and its stated lifetime. Do the same on the menu page, the booking page and any page with an embedded map, video or social feed, because embeds are where third party cookies arrive without anyone deciding to add them. This list, taken before any click, is the evidence. Everything after it is argument.

2. **Read the rule as it now stands, because it was replaced this year.** Regulation 6 of the Privacy and Electronic Communications (EC Directive) Regulations 2003 was substituted on 5 February 2026 by the Data (Use and Access) Act 2025, and it now reads: "Subject to Schedule A1, a person must not store information, or gain access to information stored, in the terminal equipment of a subscriber or user." That is a prohibition with exceptions, and the exceptions are in the new Schedule A1, in force from the same date. Note the word "information": this is not a cookie rule, it covers local storage, fingerprinting and pixels equally. Write the date of the version you read at the top of the inventory, because guidance written before February 2026 describes a different regulation.

3. **Sort each item into one Schedule A1 box and name it, and refuse to leave anything unsorted.** The boxes are: consent under paragraph 2; transmission of a communication under paragraph 3; storage or access "strictly necessary for the provision of an information society service requested" under paragraph 4, which is where a basket, a login session and fraud prevention live; statistical purposes under paragraph 5; adapting appearance or functionality under paragraph 6; and emergency location under paragraph 7. One box per item, written down with the reason in a sentence a customer could follow. An item nobody can place is an item to remove, not an item to default into strictly necessary, and "our developer added it" is not a box.

4. **Use the new statistical purposes exception if it fits, and understand exactly where it stops.** This is the genuinely new freedom from the Data (Use and Access) Act, and the GOV.UK factsheet published 27 June 2025 describes it as covering "using cookies or similar technologies to collect statistical information about how an organisation's online services are used with the aim of improving the service". The ICO's guidance then draws the line hard: "The statistical purposes exception does not allow you to monitor or track individual visitors to your service." Aggregate counts of visits, pages and scroll depth to improve the site can sit here. Following one person across your site, across devices, or joining their visit to a conversion cannot, and most analytics products do the second by default unless configured not to.

5. **Where you rely on the statistical or appearance exception, give the information and a working way to object.** These two exceptions are not free. The ICO requires that you provide "a simple means of objecting, free of charge, to the storage or access", and it says the objection route can run "through your existing consent mechanism" with those toggles defaulting to on and switchable off at any time. It also closes an obvious shortcut: "You must not solely rely on browser settings as an indication of whether a person does not object." So the banner still carries a panel for these, still explains them, and still honours a switch, even though it does not ask permission for them.

6. **Everything left over needs permission before it is set, and that includes the parts nobody thinks of as tracking.** The ICO lists cross-site and cross-device tracking, online advertising for all purposes, content personalisation based on inferred interests, and device fingerprinting for advertising as requiring consent. In hospitality that means the advertising pixel somebody added for a campaign two years ago, the embedded map that sets a third party cookie on load, the video player, the social feed and the review widget. The requirement is stated flatly by the ICO: "You must not pre-enable non-exempt storage and access technologies." Not set and then withdrawn. Not set on the reasoning that the visitor will probably accept. Not set at all, until the visitor has said yes.

7. **Make refusing as easy as accepting, on the same layer, with the same weight.** The ICO's guidance tells organisations to "review your consent mechanism and privacy settings to ensure that users can reject the use of any non-exempt storage and access technologies as easily as they can accept them". In practice: a Reject all control on the first layer, beside Accept all, the same size, the same colour weight, the same number of clicks, and neither of them hidden behind Manage preferences. This is not a theoretical point. On 4 December 2025 the ICO reported that of the UK's top 1,000 websites, 979 met its checks, 564 of them only after the ICO made contact, and that it had issued preliminary enforcement notices in 17 cases. The thing it was checking was precisely this.

8. **Specify the banner so it does not cost you the booking it interrupted.** Give the actual information required: the ICO lists "the storage and access technologies you intend to use", "the purposes you intend to use them for", "any third parties who store or access information" and "the duration for which any information will be stored", presented so as to be "concise; transparent; intelligible; easily accessible; and in clear and plain language". Then make it behave: never cover the phone number or the booking button, never block the page so the content cannot be read at all, never reappear on every page after a decision, operable by keyboard and escapable, and readable at 320 pixels wide. And record each decision with a date, so you can show what was consented to and when.

9. **Retest from a clean profile, capture the evidence, and diarise the next check.** Load the site fresh and confirm that nothing outside the exceptions is set before a click. Click Reject all and confirm the same, then reload and confirm the refusal stuck. Click Accept all and confirm what appears matches the inventory with nothing extra. Screenshot both layers. Save the storage panel in all three states. Then put a date in the diary, because a booking widget update, a new marketing pixel or a change at a third party will add a cookie to your site without telling you, and the inventory you built today is a photograph rather than a fence.

## Then it checks

1. The inventory was captured from a clean browser profile with no prior consent, on a stated date, and lists every cookie and storage item by name, domain, party, lifetime and the page it appeared on.
2. Every item in the inventory names exactly one Schedule A1 paragraph or is marked for removal, with a one sentence reason, and no item is placed in strictly necessary without a stated function that the customer asked for.
3. Nothing outside the exceptions is set on page load before a decision, proven by a storage capture taken before any click rather than by the banner's own settings screen.
4. A Reject all control is present on the first layer, beside Accept all, reachable in the same number of clicks, and a refusal survives a page reload, proven by a second capture.
5. The banner names the technologies, the purposes, the third parties and the retention periods, and every third party named in it appears in the inventory and every third party in the inventory appears in it.
6. The banner can be operated and dismissed with the keyboard alone, does not obscure the telephone number or the booking control at 320 pixels wide, and does not reappear after a decision has been recorded.

Any check fails: name it, redo that step once. Failed twice: say what is wrong and stop.

## Rules
- Public information only.
- Never invent a fact, a number or a quote.
- Anything sent in someone's name says whose name it is.
- Never set a non-exempt cookie or tracker before consent, and refuse to build or accept a design that does. This includes the common pattern where scripts load on page load and a banner asks afterwards. If the existing site does this, it is recorded as the first item on the list and nothing else is signed off until it changes.
- Never build a cookie wall that blocks a customer from reading the menu, the address or the opening hours unless they accept. A person checking whether you are open on Sunday has not made a free choice if the alternative is not finding out.
- Never make Reject smaller, greyer, later or further away than Accept, and never place the only refusal route behind a second screen.
- Never describe a cookie as necessary because the business finds it useful. The exception is about the service the visitor requested, not the service the marketing plan requested.
- Never carry an inventory forward from a previous audit without recapturing it. Third parties change what they set without notice and the whole point of the capture is that it is evidence from a date.
- Never tell the owner the site is compliant, and never publish a banner that says the site complies with PECR or the UK GDPR. Compliance is a conclusion about the whole of the processing, not about the banner.
- This output is a working document prepared for the owner to check and for their solicitor or data protection adviser to review before it is published or relied on. It applies the regulation and the regulator's published guidance to one capture of one website on one date. It is not legal advice and it is not a finding that the site complies.

## Built from
- The Privacy and Electronic Communications (EC Directive) Regulations 2003, SI 2003/2426, regulation 6 as substituted with effect from 5 February 2026 by the Data (Use and Access) Act 2025, https://www.legislation.gov.uk/uksi/2003/2426/regulation/6, read 16 September 2026: the prohibition quoted in step 2 and the fact that it now reads subject to Schedule A1.
- The Privacy and Electronic Communications (EC Directive) Regulations 2003, Schedule A1, in force 5 February 2026, https://www.legislation.gov.uk/uksi/2003/2426/schedule/A1, read 16 September 2026: the six exception paragraphs that step 3 sorts every item into.
- Information Commissioner's Office, "How do we comply with the PECR rules?", guidance on the use of storage and access technologies, https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-the-use-of-storage-and-access-technologies/how-do-we-comply-with-the-pecr-rules/, no publication date shown on the page, read 16 September 2026: the pre-enabling prohibition in step 6, the reject as easily as accept requirement in step 7 and the information and presentation requirements in step 8.
- Information Commissioner's Office, "What are the exceptions?", same guidance, https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-the-use-of-storage-and-access-technologies/what-are-the-exceptions/, no publication date shown on the page, read 16 September 2026: the limit on the statistical purposes exception in step 4, the simple means of objecting and the browser settings point in step 5, and the list of consent-requiring purposes in step 6.
- Information Commissioner's Office, "ICO action secures increased cookie compliance, giving millions stronger control over their personal information online", https://ico.org.uk/about-the-ico/media-centre/news-and-blogs/2025/12/ico-action-secures-increased-cookie-compliance/, published 4 December 2025, read 16 September 2026: the 979 of 1,000, the 564 that changed after contact and the 17 preliminary enforcement notices quoted in step 7.
- Department for Science, Innovation and Technology, "Data (Use and Access) Act factsheet: PEC Regulations", https://www.gov.uk/government/publications/data-use-and-access-act-2025-factsheets/data-use-and-access-act-factsheet-pec-regulations, published 27 June 2025, read 16 September 2026: the description of the new statistical information exception used in step 4.
- Information Commissioner's Office, "Final storage and access technologies guidance published", https://ico.org.uk/about-the-ico/media-centre/news-and-blogs/2026/04/final-storage-and-access-technologies-guidance-published/, published 29 April 2026, read 16 September 2026: confirmation that the guidance relied on above is the final version and its scope covers "cookies, tracking pixels, device fingerprinting and similar technologies", which is why step 1 captures storage and pixels and not only cookies.

# cookie-banner

## You are given
Three storage captures from one UK hospitality website, each taken from a clean browser profile on a stated date by a named person: a `before any click` capture, a `after reject all` capture and a `after accept all` capture. Each capture lists, per page visited, every cookie, local storage key, session storage key and network beacon, with name, domain, first or third party, stated lifetime, the page URL and the script or embed that set it. The list of pages visited. The Schedule A1 classification for every item, already decided by Claude and supplied as one record per item giving the paragraph number, the box name and the one sentence reason. The third party register, listing each third party, what it is for and the venue's relationship to it. The drafted first layer and second layer banner wording as finished copy. The banner behaviour specification. And, where a banner already exists, its configuration export and screenshots of both layers.

## Produce
Write into a `./cookie-banner-output/` folder:

1. `inventory.csv` with these columns in this order: `item_ref`, `capture_state`, `page_url`, `item_name`, `storage_type`, `domain`, `party`, `stated_lifetime`, `set_by_script_or_embed`, `schedule_a1_paragraph`, `box_name`, `reason_supplied`, `named_in_banner`. `item_ref` is I001 upward. `capture_state` is exactly one of `before any click`, `after reject all`, `after accept all`. `storage_type` is exactly one of `cookie`, `local storage`, `session storage`, `pixel or beacon`, `fingerprinting signal`. `party` is `first` or `third`. `box_name` is exactly one of `consent`, `transmission`, `strictly necessary`, `statistical purposes`, `appearance or functionality`, `emergency location`, `to be removed`.
2. `pre-consent-violations.csv` with columns: `item_ref`, `page_url`, `item_name`, `domain`, `party`, `box_name`, `set_by_script_or_embed`, `seconds_after_load`. One row for every item present in the `before any click` capture whose `box_name` is `consent` or `to be removed`. This file being non-empty is the first item in `gaps.md`.
3. `reject-effectiveness.csv` with columns: `item_ref`, `item_name`, `domain`, `present_before_any_click`, `present_after_reject_all`, `present_after_reload_following_reject`, `box_name`, `outcome`. The three presence columns are `yes` or `no`. `outcome` is exactly one of `correctly absent`, `set despite refusal`, `refusal did not survive reload`, `exempt and expected`.
4. `third-parties.csv` with columns: `third_party_name`, `domains_observed`, `items_set`, `pages_observed_on`, `purpose_supplied`, `box_name`, `named_in_banner`, `relationship`. `relationship` is exactly one of `contracted by the venue`, `embedded by the venue`, `arrived with a plugin or theme`, `unknown`. Any row with `relationship` set to `unknown` is listed in `gaps.md`.
5. `banner-behaviour.csv` with columns: `behaviour_check`, `required_by_specification`, `observed`, `evidence_file`, `passes`. One row per check, with `behaviour_check` exactly one of `reject all present on first layer`, `reject all same click count as accept all`, `reject all same visual weight as accept all`, `operable by keyboard alone`, `dismissable by keyboard alone`, `does not obscure telephone number at 320 CSS pixels`, `does not obscure booking control at 320 CSS pixels`, `does not reappear after a recorded decision`, `objection route present for statistical purposes`, `objection route present for appearance or functionality`, `decision recorded with a date`.
6. `banner-copy.md` containing the supplied first layer and second layer wording reproduced exactly, with nothing added, removed or reworded, and `information-checklist.csv` with columns: `required_information`, `present_in_banner`, `wording_verbatim`, `page_or_layer`. `required_information` is exactly one of `technologies used`, `purposes`, `third parties`, `retention durations`.
7. `capture-log.csv` with columns: `capture_state`, `captured_by`, `date_captured`, `browser_and_version`, `profile_clean`, `extensions_present`, `pages_visited`, `item_count`. `profile_clean` is `yes` or `no`, and a `no` invalidates the capture and is listed in `gaps.md`. Dates are DD Month YYYY.
8. `gaps.md` is a numbered list of: every row in `pre-consent-violations.csv`; every item with no `schedule_a1_paragraph` or no `reason_supplied`; every item in `box_name` `strictly necessary` whose `reason_supplied` does not name a function the visitor requested; every third party with `relationship` `unknown`; every third party in the inventory not named in the banner and every third party named in the banner not in the inventory; every `banner-behaviour.csv` row where `passes` is `no`; every `required_information` not present in the banner; every `reject-effectiveness.csv` row whose outcome is `set despite refusal` or `refusal did not survive reload`; and any capture where `profile_clean` is `no` or extensions were present.

## Rules
- Codex measures, records and checks. It never classifies an item into a Schedule A1 paragraph, never writes or reworks banner copy, never changes a banner configuration, and never edits the website.
- Never infer a classification for an item that arrives without one. An unclassified item is recorded with empty classification columns and listed in `gaps.md`.
- Never write that the site, the banner or the business is compliant, lawful, PECR compliant or GDPR compliant in any file. Findings are recorded per item and are never aggregated into a verdict.
- Never treat a banner's own configuration, settings screen or vendor report as evidence of what was set. Only the storage captures are evidence, and where the configuration and the capture disagree, both are recorded and the disagreement is listed in `gaps.md`.
- Never mark an item exempt because it is first party, because it is common, or because the vendor describes it as essential. The `box_name` arrives supplied and is recorded as supplied.
- Never write a benchmark, an industry average, a consent rate, an acceptance rate or a figure for what proportion of visitors reject. No such figure exists for a single independent UK venue and none is to be written into any file.
- Lifetimes are recorded exactly as the cookie or storage item states them, in the unit given, and are never converted, rounded or described as short or long.
- Use British English, GBP and DD Month YYYY dates. No em dashes in any file you write, and any supplied copy containing one is reproduced verbatim and flagged in `gaps.md`.
- Every file ends with this line: this is a working document prepared for the owner to check and for their solicitor or data protection adviser to review before publication. It records one capture of one website on one date. It is not legal advice and it is not a finding that the site complies.

## Return
The absolute path of each file written, the row count of each CSV, the item count in each of the three captures, the number of items set before any click broken down by `box_name` with every `consent` and `to be removed` item named in full with its domain and the script that set it, the distribution of items across the Schedule A1 boxes, every item with no classification, the number and names of third parties observed and how many have `relationship` `unknown`, the count of `reject-effectiveness.csv` rows at each outcome with every failure named, which of the eleven behaviour checks failed, which of the four required information items are absent from the banner, whether any capture was taken on a profile that was not clean, and the `gaps.md` item count.