Cookie consent requirements for a small SaaS: what to block until consent, and how to test refusal and withdrawal

In the first second of a visit from Berlin, before anyone has touched a banner, your page has either loaded GA4 and set its cookies or it has not. EU cookie consent requirements turn on that second: nothing optional is stored until the visitor agrees, and withdrawing is as easy as agreeing. Since 5 February 2026 the UK has its own exceptions.

Cookie consent requirements: what the EU and UK rules ask for, in code terms

Cookie consent requirements in the EU come from 2 laws: the ePrivacy Directive bars storing or reading anything on a visitor’s device without consent unless it is strictly necessary for a service they asked for (or for transmission), and the GDPR says that consent must be freely given, specific, informed, unambiguous and as easy to withdraw as to give.

This page covers the banner, the scripts and the test. Whether the regulation reaches your company at all, which lawful basis you rely on and what else it asks of you are set out in GDPR for a small SaaS: what you owe, in order. Everything here is practical guidance, not legal advice.

The device rule is Article 5(3) of the ePrivacy Directive. It allows “the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user” only once the visitor “has given his or her consent, having been provided with clear and comprehensive information”, which is why the question comes before the cookie and not after it. The quality of the yes is set by the GDPR. Article 4(11) defines consent as a “freely given, specific, informed and unambiguous indication” given “by a statement or by a clear affirmative action”, and GDPR Article 7 adds, in Article 7(3) of the adopted EU text: “It shall be as easy to withdraw as to give consent.”

Cookie consent under the GDPR is therefore shorthand. The duty to ask comes from the Directive, and the standard the answer has to meet comes from the regulation; the EDPB’s cookie banner taskforce wrote that the Directive’s reference to consent covers both the GDPR’s definition in Article 4 and its conditions in Article 7. GDPR cookie compliance, in practice, means meeting both texts at once.

The table turns the GDPR cookie consent requirements into what they mean for a page, with the UK source beside each one. Cells marked guidance come from a regulator’s documents, not from the statute.

Two rows rest on case law and regulator guidance rather than on the statute. The Planet49 judgment (Court of Justice, Grand Chamber, 1 October 2019, case C-673/17) held that consent “is not validly constituted” when cookie storage “is permitted by way of a pre-checked checkbox which the user must deselect to refuse his or her consent”. The EDPB’s consent guidelines (version 1.1, adopted 4 May 2020) say scrolling or swiping “will not under any circumstances satisfy the requirement of a clear and affirmative action”, that access to a service “must not be made conditional” on cookie consent (“so called cookie walls”), and that “Granular consent options should be provided to allow data subjects to consent separately to separate purposes.”

The rules attach to visitors in the EU and the UK, so in my reading a company registered in the United States with European visitors meets them too; the applicability test itself is in the small-SaaS GDPR guide above. California works differently, with an opt-out, which the questions at the end cover. The cookies section of a privacy policy for SaaS is where the longer list of cookies lives, and cookie consent is one piece of how to manage SaaS data compliance as a whole.

UK cookie rules since February 2026: consent, and the new exceptions

UK cookie rules changed on 5 February 2026: PECR still makes consent the general route, but Schedule A1 now lets a site store information solely for statistics that improve its own service (shared only to make those improvements) or to adapt its appearance to visitor preferences, without consent, if visitors get clear information and a simple, free way to object.

The Data (Use and Access) Act 2025 substituted regulation 6 of PECR on 5 February 2026, and the regulation now opens: “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.” PECR Schedule A1 holds the exceptions, and its definition of “website” includes a mobile application. Paragraph 3 keeps the transmission exception and paragraph 7 covers location data for emergency assistance; the other four are the ones a SaaS works with.

My reading of paragraph 5: whether a given analytics tool fits it turns on where its data goes, and the tool’s own terms and settings answer that. I give no verdict on any tool here. Paragraph 5 also excludes from its scope “collecting or monitoring information automatically emitted by the terminal equipment”, so in my reading it is not a route for fingerprinting.

For paragraph 2, PECR says consent “corresponds to the data subject’s consent in the UK GDPR”, whose Articles 4(1)(11) (4(11) until 5 February 2026), 7(1) and 7(3) carry the same wording as the EU text. The ICO’s cookies guidance still says, as of 3 October 2026, that it “is based on the previous version of the detailed cookies guidance” and that a revised version is out for consultation, so I treat it as guidance under revision, not as a statement of the current UK rule. The EU text has no statistics exception: an analytics cookie set for an EU visitor still needs consent.

Which cookies need consent, and which never did

Cookies in the EU need consent unless they are strictly necessary for a service the visitor asked for. Session, CSRF, cart and load balancer cookies pass that test. Analytics, advertising pixels, session replay and most embedded widgets do not, and the same rule covers localStorage, because Article 5(3) is about the device, not the file.

The sorting below is my reading of “strictly necessary” against the stack a small SaaS usually runs; the UK column names the Schedule A1 paragraph that could apply, with its conditions in the section above.

Article 5(3) speaks of information stored on the device and never names a file format, so localStorage, sessionStorage and IndexedDB entries fall under it the same way cookies do. The UK text goes one step further: regulation 6(2)(b) counts “collecting or monitoring information automatically emitted by the terminal equipment” as gaining access.

One EU regulator carves out a narrow analytics class in its own guidance. The CNIL’s cookie guidelines, summarized in a sheet dated 11 June 2020, exempt audience measurement cookies from consent when users are informed and can object, the purposes are limited to audience measurement and A/B testing, the data is not cross-checked with other processing, the tracer covers a single site or app publisher, the last byte of the IP address is truncated and the tracker lives no longer than 13 months. The same sheet says “Most large audience measurement offerings do not fall within the scope of the exemption, regardless of their configuration”, and that its position may be subject to national variation, so it is France’s regulator speaking, not EU law.

A site that sets only strictly necessary cookies needs no consent banner under either text (EU Article 5(3), UK Schedule A1 paragraph 4). Listing those cookies in the privacy policy anyway is good practice.

What goes wrong without it

Each row below is a check you can run on your own site in the browser’s Network and Application tabs. Row 1, analytics loading before consent is given, comes first because it is the default state of a GA4 snippet pasted into a layout.

Take a marketing site with the GA4 snippet in its layout’s head, and a consent banner added later through a script that loads asynchronously and sets consent mode’s default to denied. On a fresh visit the snippet’s commands run before the banner’s script has set any default, and Google’s documentation says that “By default, no consent mode values are set” and that “If your consent code is called out of order, consent defaults won’t work”, so the default the banner sets does not govern those first commands. The lesson I take from it: the order of the scripts is part of the consent control, and only a fresh-profile check shows it.

Row 3 is a consent-quality problem in regulators’ guidance rather than a script fault. The EDPB cookie banner taskforce report (18 January 2023) records that “a vast majority of authorities considered that the absence of refuse/reject/not consent options on any layer with a consent button” is an infringement, while calling its positions a “minimum threshold” agreed among authorities, not stand-alone recommendations. The CNIL’s consolidated recommendation (16 January 2026) asks for accepting and refusing to be offered “avec le même degré de simplicité”, with the same degree of simplicity. Row 4 has its own line in the EDPB’s guidelines: when consent was given through a website’s interface, the visitor “must be able to withdraw consent via the same electronic interface”.

How to do it: the inventory, the block, the banner, the record

Consent controls are built in 5 steps: list every script, pixel and iframe the pages load, mark which ones need consent, hold those until a choice is stored, put a banner with an equal refuse button in front of them, and keep a dated record of each choice.

The order matters, and it is the order of the sections below. The procedures come from the legal texts and regulators’ documents quoted above, Google’s consent mode documentation and the CookieConsent documentation, each read on 3 October 2026.

A cookie compliance checklist for EU visitors

A cookie compliance checklist for EU visitors has 10 lines: an inventory of every tag, nothing optional before a choice, an equal refuse button, separate purposes switched off, named vendors, a stored dated choice, a standing change link, a working withdrawal, persistence, and a matching policy.

Build the inventory from the Network tab on your busiest pages, plus a search of the codebase for <script, <iframe and the tag manager’s container ID, then cross-check it against the vendor list in a data map GDPR reviewers accept. Embeds are the entries a tag list misses most, because they arrive in the HTML.

Lines 1, 2, 5, 6, 7 and 8 rest on law: Article 5(3) of the ePrivacy Directive for prior consent and information, Article 7 of the GDPR for proof and withdrawal. Line 3 and the re-ask period rest on regulator guidance. The CNIL’s recommendation calls keeping a choice, consent or refusal alike, for 6 months good practice. My working rule for a small team is to ask again whenever the tag list changes, and otherwise roughly once a year.

UK visitors get the same list, except that a script that fits a Schedule A1 statistics or appearance exception needs the information and a simple, free way to object in place of line 2’s prior consent; the conditions are in the UK section above.

Block tracking scripts until consent

Tracking scripts are blocked until consent in one of 3 ways: your code does not render the tag until the stored choice allows it, the tag is rendered inert as text/plain and released by a consent library, or the tag manager gates each tag on consent state.

The simplest is not rendering the tag at all. Your own code injects the script only after the stored choice allows its category; in a React or Next.js app that means the analytics component reads the consent state and returns nothing until analytics is granted. The second way leaves the tag in the HTML but inert, with type="text/plain" and a data-category attribute, which a library such as CookieConsent swaps for a live script when that category is accepted. The third belongs to Google Tag Manager: Google’s tags have built-in consent checks, and for other tags Google says “you can add checks in Tag Manager using configuration in Advanced > Consent Settings”.

Some analytics SDKs document their own switch instead. PostHog’s docs warn against gating its snippet behind consent and recommend loading it “opted out by default, then opt the user in once they consent”. There, follow the vendor’s switch and let State 0 of the test below show whether anything is stored or sent before the choice.

The traps are about where scripts come from. A script hard-coded in the HTML head is already running by the time any banner code loads. A tag manager container that loads before consent is fine only if every tag inside it is gated. Iframes need the same treatment as scripts: a placeholder with a “load video” button that creates the iframe on click. Server-side tracking and first-party proxies do not change the EU rule for anything they store on or read from the device. And analytics your server sends never shows in the browser’s Network tab, so the choice has to reach the server too.

The pattern in code, generic and without a vendor:

<!-- held: a script with type="text/plain" is not run -->
<script type="text/plain" data-category="analytics" src="/analytics.js"></script>
<script>
  function releaseCategory(category) {
    document.querySelectorAll(`script[type="text/plain"][data-category="${category}"]`).forEach((held) => {
      const live = document.createElement('script');
      if (held.src) live.src = held.src; else live.textContent = held.textContent;
      held.replaceWith(live);
    });
  }
</script>

Call releaseCategory('analytics') from the code that saves an accepted choice, and on each later page load when the stored choice already allows it.

A consent-aware analytics setup with Google consent mode

Google consent mode is a signal that tells Google tags how to behave, not a banner. The page sets 4 parameters to denied before any tag sends data, then updates them when the visitor chooses. Google’s docs say consent defaults do not work when the consent code runs out of order.

Google’s consent mode setup guide says to call gtag('consent', 'default', ...) “on every page of your site before any commands that send measurement data (such as config or event)”, and to send gtag('consent', 'update', ...) when the visitor chooses. The four parameters in its default call are these.

The last column is my working rule for EU and UK visitors, not Google’s. Google calls it best practice “to scope the default consent settings to the regions where you are surfacing consent banners to your visitors”, which its region option does.

Google describes two setups. In basic consent mode “you prevent Google tags from loading until a user interacts with a consent banner”, and when the user refuses “no data is transferred to Google at all”. In advanced consent mode “Google tags load when a user opens the website or app”, and “While consent is denied, the Google tags send measurements without cookies.” Google’s pages describe what the tags do, not whether cookieless requests before consent satisfy Article 5(3), and the regulator documents quoted on this page do not settle it either, so for a small team my reading is that the basic setup is the conservative choice. If the banner loads asynchronously, Google’s wait_for_update setting tells the tags how many milliseconds to wait for the update before sending data.

The alternative is a cookieless analytics tool. One that stores nothing on the device removes the EU storage question for that tool, while the UK statistics exception keeps its own conditions. What to instrument once consent is given, and how SDKs other than Google’s wait for the choice, belongs to product analytics when you have no idea where users drop off.

How to add a cookie banner

A cookie banner arrives by one of 3 routes: a hosted consent platform, an open-source library you host, or a few lines of your own. The inventory, the wiring of each script to a category, the equal refuse button and the test stay your job on all three.

OneTrust’s product page lists auto-blocking and scheduled site scans among its features. Auto-blocking is a convenience that still needs the test, because in my reading it works from what a scan saw and misses what the scan did not, such as a widget added after the last scan. Some platforms can show different banners by region (OneTrust’s page mentions geolocation rules); a geotargeted banner adds one more state to test, and showing the banner to everyone is the simpler default.

Vanilla CookieConsent: what a consent library has to do before the first script fires

A consent library has 6 jobs before the first script fires: load from your own origin, define categories with everything optional off, hold tagged scripts, run callbacks on consent and on change, clear a category’s cookies when it is switched off, and re-ask when the revision changes.

Vanilla CookieConsent is Orest Bida’s open-source consent library, released under the MIT License. The CookieConsent repository holds the code, the CookieConsent documentation is at version 3.1.0, and the package installs from npm as vanilla-cookieconsent. Using it as the worked example, the six jobs look like this:

1. 01 Serve it from your own origin, through the npm package or the release files in your build, so the library itself is not a request to another host before consent.
2. 02 Define categories: necessary with readOnly: true, and every other category left off, since enabled marks a category as on by default.
3. 03 Mark each optional script with type="text/plain" and data-category, which the library turns into a running script when that category is accepted.
4. 04 Use the onFirstConsent, onConsent and onChange callbacks to act on the choice; the Google consent mode update call goes there.
5. 05 Give each optional category an autoClear list, for example every cookie starting with _ga, so switching it off removes those first-party cookies.
6. 06 Set a revision number and raise it when the tag list changes, so everyone who chose under the old revision is asked again.

Job 1 is my own rule; the docs also offer a CDN build. Job 5 matters for the test: a withdrawal that leaves _ga behind fails it. Some things stay outside the library in my reading of its docs. They say “There is no built-in API for consent logging”, so a server-side log is your own fetch call from the callbacks. Scanning your site for scripts is not stated in its docs, so the inventory stays yours, and an equal refuse button is a matter of how you configure the banner’s buttons.

What to keep as the record of a choice

Article 7(1) of the EU GDPR reads: “Where processing is based on consent, the controller shall be able to demonstrate that the data subject has consented to processing of his or her personal data.” The UK GDPR carries the same sentence.

My working rule for a small team is a three-part record: the consent cookie itself, holding the choice per category, the timestamp and the banner revision; the banner text and the tag inventory under version control, so you can show later what a given revision asked for; and, where a reviewer asks for more, a server-side log of consent events keyed to a random ID, not to the user’s account. CookieConsent’s own logging example sends a consentId with the accepted and rejected categories, which fits that shape. Do not collect more personal data to prove consent than the tracking itself would have collected, and put that log on your retention schedule. Fields your app sends to model providers are a separate control: how to redact personal data before LLM calls.

How to verify it

Cookie consent is verified with the browser’s developer tools in 4 states after a clean first load, where nothing optional may load: after accept the scripts load, after refuse they never load on any page, after withdrawal they stop and their cookies are cleared, and after a restart the choice still holds.

Run each state in a fresh browser profile with the developer tools open: the Network tab with “Preserve log” checked, so requests survive page loads, and the Application tab for cookies and localStorage. Run it on the marketing site and inside the app. The withdrawal state needs an accepted profile to start from: you cannot test consent withdrawal on a website from a fresh one.

The pass lines hold for a site using Google consent mode’s basic setup or plain script blocking. Under the advanced setup, Google’s cookieless requests before consent are expected by design, so the Google lines pass when no _ga cookie is written and the requests carry the denied state. That state travels in the gcs request parameter, which Google says may be encoded and may change, so read it through Tag Assistant’s Consent tab and its On-page Default and On-page Update columns rather than by eye.

Start with the baseline, State 0, before any choice: it passes when the Network tab shows no request to any host on the inventory’s needs-consent list and the Application tab shows only necessary cookies and storage, and it fails on a single analytics or pixel request. Then run the four states.

1. 01 State 1, accept: the optional scripts load, the consent cookie is written with the categories, the date and the revision, and with consent mode the On-page Update column shows the types as granted.
2. 02 State 2, refuse (new profile): click refuse on the first layer, then browse three pages including a logged-in one; pass when nothing on the list ever loads; fail when a route change or a later page injects a tag.
3. 03 State 3, withdraw (accepted profile): use the footer link, switch analytics off and save; pass when _ga and the other optional first-party cookies are gone, no optional request fires on the next navigation and consent mode shows denied; fail when _ga remains or the script keeps sending until a manual reload.
4. 04 State 4, persist: close the browser, reopen it and visit the app; pass when the choice holds without a banner in both the accepted and the refused profile, and when raising the banner revision brings the banner back.

Cookies set by embedded third-party frames cannot be cleared by your code, so the State 3 pass line covers your own domain. An app on a separate domain from the marketing site asks again in State 4, which is not a fail; an app on a subdomain only sees the choice if the consent cookie is set for the shared parent domain. For UK visitors, a script run under a Schedule A1 statistics or appearance exception replaces State 2 with “object”: use the simple means of objecting and check that the script stops. If the banner is geotargeted, repeat State 0 from an EU or UK location; Google’s Tag Assistant guide gives the same advice for region-specific defaults.

Keep the evidence dated: a HAR export or a Network-tab screenshot per state, the consent cookie’s value per state, the tag inventory, and the banner revision you tested. Chrome’s default HAR export is “sanitized” and leaves out the Cookie and Set-Cookie headers, so read the consent cookie’s value from the Application tab or export the version with sensitive data. Re-run the test after any change to the layout, the tag manager container or the site builder’s integrations; in my reading those are the three places a new script arrives without anyone deciding it should. Server-side analytics sits outside what this test can check.

In the Production Hardening Sprint, deliverable 12.4 is verified this way: “Test consent, refusal, withdrawal, and persistence; verify optional scripts respect those choices.”

Where the sprint does this

Deliverable 12.4, Cookie consent controls, is to implement consent controls for the application’s audience and tracking configuration, including EU visitors where relevant. It sits in area 12, Privacy & compliance foundations, which contains 8 of the 123 deliverables on the published scope, area 12. Deliverable 13.1, the production readiness report, delivers the result for every scope item, the work completed and its verification evidence. Legal advice and certification are separate services; the sprint implements and documents the technical data-handling controls. Hosting, paid tools and API usage remain in your accounts, and any required third-party costs are explained before they are enabled.

Common questions about cookie banners and consent

Does the US require cookie consent?

Not as a single federal rule: the Congressional Research Service writes that “Rather than adopting a single comprehensive consumer privacy law, Congress has enacted various privacy statutes that apply to particular industries and subcategories of data.” California’s rule, quoted in the next answer, is an opt-out from the sale or sharing of personal information rather than a yes collected before cookies are set. EU and UK rules still apply to your EU and UK visitors wherever your company is registered.

Is cookie consent required in California?

Not as an EU-style opt-in, in my reading of the California Privacy Protection Agency’s FAQ: it describes a right to ask a business to stop selling or sharing personal information “for cross–context behavioral advertising”, including through a user-enabled opt-out preference signal such as the Global Privacy Control. In most instances businesses must also show a “Do Not Sell or Share My Personal Information” link (or “Your Privacy Choices”) in the footer or header. Whether the CCPA covers your business at all is a separate threshold question.

Is it illegal to not have a cookie banner?

Not if the site sets only strictly necessary cookies: neither EU Article 5(3) nor UK Schedule A1 paragraph 4 asks for consent to those. With optional cookies and EU visitors, consent is required and a banner is the usual way to collect it. For UK visitors, a statistics or appearance cookie under Schedule A1 needs clear information and a simple, free way to object instead of consent.

What happens if consent is withdrawn?

Processing that relied on consent before the withdrawal stays lawful, and from the withdrawal on it has no consent to rest on: EU GDPR Article 7(3) says the withdrawal “shall not affect the lawfulness of processing based on consent before its withdrawal”. Data already collected is then a deletion and retention question, not a banner question. The technical side, scripts stopping and cookies cleared, is State 3 of the test above.

Can you provide an example of a cookie consent message?

Here is one, written for a site whose only optional cookies are analytics: “We use cookies that keep you signed in and secure. With your permission we would also use Google Analytics cookies to see how the site is used. Accept, refuse or choose by purpose, and change your mind any time from the footer.” Under it sit three buttons of equal weight: Accept all, Refuse all, Choose.

What is OneTrust auto blocking?

OneTrust auto-blocking is a feature of OneTrust’s consent platform that, in OneTrust’s words, lets a site “Use no-code cookie blocking, tag manager integrations, or script re-writing to block trackers until explicit consent is gained.” In my reading it is a convenience, not proof: the four-state test still applies, because blocking can only hold what the platform knows about.