EU cookie consent compliance checklist for SaaS websites

If you ship a SaaS product to European users — whether B2B or B2C — your cookie banner is the most legally exposed surface on your website. The cookie consent compliance checklist below condenses what European Data Protection Authorities (DPAs) actually look for, drawn from binding decisions issued between 2024 and 2026.

Three patterns cause most of the cookie-consent fines that EU DPAs have issued in the last 24 months. A “Reject all” button that is harder to find or use than “Accept all” on the first layer. Non-essential tracking scripts that fire before any consent is recorded. A withdrawal flow that demands more effort than the original opt-in. None of these are theoretical — each has produced six- and seven-figure penalties from regulators in France, Italy, the Netherlands, and Spain since 2024 (see our 2026 cookie consent fines roundup).

The legal basis sits in Article 5(3) of the ePrivacy Directive 2002/58/EC and the conditions for valid consent in GDPR Article 7. Together, they require informed, specific, freely given, unambiguous, and equally easy-to-withdraw consent before any non-essential storage or read on a user’s device. Operationally, that has been condensed into the EDPB Cookie Banner Task Force Report (January 2023) — the reference every European DPA cites when evaluating banner design.

The 18 items below assume a typical SaaS shape: a marketing landing page, a product/login surface, occasional in-app help docs, and a stack that includes analytics, product analytics, an embedded chat widget, and one or two advertising tags. Adjust scope where your architecture differs.

Banner design and placement (5 items)

1. First layer offers at least one accept option AND at least one reject option, with equal visual prominence. Same colour treatment, same size, same font weight, same position type. A grey “Reject all” link beneath a brightly coloured “Accept all” button is the single most common defect across recent enforcement decisions.

2. No pre-ticked boxes for non-essential categories. GDPR Art. 4(11) requires consent to be a “clear affirmative action”. Pre-checked equals no consent at all.

3. The banner does not gate access to ordinary content unless an equivalent service path exists. Modal banners that block interaction until a choice is made are tolerated; “cookie walls” that force acceptance to read a marketing page are generally unlawful (see EDPB Guidelines 05/2020 on consent).

4. No “by continuing to browse, you accept” wording. Implied consent through scrolling or further navigation has been explicitly rejected by every major EU DPA since 2020.

5. The banner reappears on every device and every cleared-storage state. A user who clears cookies has no record of prior consent — re-prompting is mandatory, not optional.

Consent recording and storage (4 items)

6. Each consent decision is logged with timestamp, banner version, choices selected, and the consent string passed to downstream tags. This is the evidence you produce when a DPA asks for proof of consent under GDPR Art. 7(1). Pattern: store the record server-side, not only in a third-party cookie a user can clear.

7. Consent records are stored on the controller side, not only in a third-party CMP cookie. A user-cleared cookie cannot be your sole proof of consent.

8. Consent expires and re-prompts at a defined cadence. The EDPB and most national DPAs converge on no more than 6–12 months without re-confirmation, or earlier on any material change to processing purposes or vendors.

9. A unique consent ID is assigned to each decision and is queryable for at least 24 months for audit and right-of-access requests. GDPR Art. 15 access requests sometimes ask “what consent did I give and when?” — you need to be able to answer with a record, not a screenshot.

Tag and script firing behaviour (4 items)

10. No non-essential script makes a network request before the user has actively chosen. This includes Google Analytics, advertising pixels, A/B testing, session replay, embedded social widgets, customer-data platforms, and any third-party fingerprinting. The Italian Garante and Spanish AEPD have repeatedly fined sites specifically for pre-consent loads.

11. “Essential” is scoped narrowly. Essential covers what is strictly necessary for the service the user requested — login session, CSRF protection, load balancing, fraud prevention. Analytics is not essential, even when self-hosted.

12. Granular toggles work granularly. If the banner offers separate toggles for analytics, marketing, and personalisation, each must independently gate the corresponding scripts. Server-side tag managers must enforce the same toggles, not bypass them.

13. The same consent state is honoured across subdomains and across SPA route changes. A consent registered on www.example.com must be honoured on app.example.com and on a client-side route push that loads new tags.

User-facing controls (3 items)

14. A persistent “Cookie preferences” link is available on every page footer, and reopening it shows the user’s current state. Re-engagement of consent must be at least as easy as the original choice (GDPR Art. 7(3)).

15. Withdrawing consent triggers immediate cessation of the affected processing. “Stop within 30 days” is not lawful — withdrawal is effective from the moment it is registered, with downstream tags unloaded in the same browsing session.

16. The cookie policy enumerates every cookie or storage key with its purpose, category, retention period, and recipient (including any third-party processor). Generic “we use cookies for analytics” descriptions have repeatedly been found inadequate in DPA decisions, particularly where multiple sub-processors are involved.

Audit and evidence (2 items)

17. A periodic automated audit runs against the live site and reports new tags, new vendors, and any non-consented loads. Manual audits drift; site changes — a new marketing tag added by a non-engineering team, a third-party widget that injects a fingerprinting library in a minor version bump — are the most common source of regression. For the underlying mechanics of “Reject all” testing, see our technical breakdown of cookie rejection.

18. The audit output is retained for at least 24 months as evidence of due diligence. When a DPA opens an inquiry, the difference between “we audit monthly and here are the reports” and “we believe we are compliant” is often the difference between an administrative order and a financial penalty.

How to use this checklist

Run through the 18 items in order on a quiet morning. The banner-design items (1–5) usually surface defects within minutes — they are visible to the naked eye and to a tab in the browser dev-tools. The script-firing items (10–13) require browser dev-tools or an automated audit, because the violations happen in network requests the user never sees. The audit items (17–18) are organisational, not technical — they require a recurring calendar entry and a place to store the reports.

If your team has been treating cookie consent as a one-time setup rather than a continuous-compliance surface, expect the first pass to find 5–10 defects. That is normal and recoverable. The risk is not having defects — every site has them at some point — but having no record of finding and fixing them. Regulators consistently treat documented remediation more favourably than silence.

A practical sequence for a small team: do items 1–5 yourself this week using nothing but a browser. Schedule items 10–13 for next sprint, paired with a network-request audit. Add items 17–18 to your operations cadence — quarterly is a defensible minimum for a SaaS site that ships frequently, monthly is better.

---

Want this checklist run automatically against your site, with each finding mapped to the specific ePrivacy or GDPR article it touches? Start a free audit — no registration required.