Cookie consent: opt-in is mandatory
Before any non-essential cookie, active consent is required. Pre-checked boxes, hidden 'Accept' buttons and 'continue browsing means consent' have been unlawful for years — yet they keep being built.
What it's about
Cookies and comparable technologies (local storage, session storage, IndexedDB, fingerprinting, tracking pixels) may only be set if they are strictly technically necessary OR if the user has actively consented. The relevant law is § 25 TDDDG, which transposes the ePrivacy Directive. Important: TDDDG applies regardless of whether the cookies process personal data — even mere access to the end device counts.
Statistics cookies (Google Analytics, non-anonymised Matomo), marketing cookies, tracking pixels and external media (YouTube, Google Maps, Vimeo) are not strictly necessary. So before they are set, valid consent is required — and that has clear requirements: freely given, informed, unambiguous, granular, withdrawable at any time, no dark patterns. Pre-checked is unlawful (CJEU Planet49). In August 2024 the DSK also clarified that 'pay or consent' models (pay or accept tracking) are only permitted under strict conditions — e.g. the paid offer must be genuinely usable and the price reasonable.
Violations are expensive and now actively enforced: fines up to EUR 300,000 under TDDDG, parallel GDPR fines up to EUR 20m. Warnings from consumer associations, competitors and data-protection activists (e.g. noyb) have become routine. A simple 'toolbar with an Accept button' is no longer enough — supervisory authorities now also audit the reject path and check whether, after 'reject', no non-essential cookies are actually being set.
Who is affected
- Every website or web app that uses cookies or comparable storage (local storage, IndexedDB, service worker) — including B2B.
- Sites with embedded third-party content: YouTube, Vimeo, Google Maps, Twitter/X embeds, LinkedIn buttons, Facebook Like.
- Online shops with tracking pixels (Meta Pixel, TikTok Pixel, Pinterest Tag) and conversion measurement.
- Marketing-driven sites with Google Ads, Microsoft Ads, newsletter tracking pixels.
- Mobile apps with tracking SDKs (Firebase Analytics, AppsFlyer, Adjust) — the ePrivacy duty applies there too.
- Connected devices, smart-TV apps, IoT dashboards with analytics or telemetry.
- Providers outside the EU once they reach EU citizens (TDDDG market-place principle + GDPR Art. 3).
What is mandatory
- Consent Management Platform (CMP) on every page, visible BEFORE any non-essential cookies are set, with no 'disappearing' banner.
- Granular choice: at minimum 'Necessary / Statistics / Marketing / External media', better still per provider individually.
- Rejecting must have the same UX as accepting — no dark patterns, no hidden menu, no 'after three clicks' effect (DSK 2024).
- Active action required: pre-checked boxes or 'continue browsing means consent' are invalid (CJEU Planet49).
- Withdrawal possible at any time, with the same effort as granting consent (e.g. a persistent fingerprint button in the footer).
- Consent logs with timestamp, settings hash, ideally hashed IP and banner version — archive at least 3 years as evidence.
- Re-consent on changes to the cookie list, new third-party providers or changed purposes (no 'once accepted = forever').
- Privacy policy with up-to-date cookie table: provider, purpose, retention, third-country transfer, cookie name.
- Tag-manager check: no tags may fire before consent — Google Consent Mode v2 is not automatically compliant.
- Mobile app SDKs: tracking SDKs (Firebase, AppsFlyer) must also sit behind the consent gate.
- Audit the reject path: after clicking 'Reject', no non-essential cookies/LS entries may be set (browser test, supervisory authorities are now actively checking this).
What I take care of
- Selection + integration of a GDPR-compliant CMP (self-hosted or EU provider such as Usercentrics EU profile, Klaro, Cookiebot EU data centre — no pure US platform).
- Integration into Next.js with a Server-Components-compatible pattern: no hydration flash, no 'cookie set for a fraction of a second and removed again'.
- Consent logging in Supabase (EU) with audit-proof storage: hashed IP, banner version, settings JSON, timestamp, locale.
- Reject path test with a real browser (Playwright): proof that after 'reject' no non-essential cookies/LS entries are set — as a CI smoke test.
- Inventory audit of your site: which cookies are actually set (before and after consent), which are missing from the cookie table, which sneak in invisibly through third parties.
- Privacy policy update with current providers, purposes, retention periods, third-country transfers — automatically synced with the CMP configuration.
- Re-consent workflow on changes to the cookie list: bump the banner version, mark old consents as 'expired', collect new consent.
- Optional: Pay-or-Consent review per DSK guidance (Aug 2024) — genuinely voluntary, reasonable price, paid offer actually usable.
- Annual re-audit: new third parties, changed cookie lists, new authority guidance, browser-behaviour changes (e.g. third-party-cookie phase-out).
Legal basis
§ 25 TDDDG (German Telecommunications-Digital-Services Data Protection Act, formerly TTDSG, in force since 14.05.2024) · ePrivacy Directive 2002/58/EC (lex specialis to GDPR for cookies) · GDPR Art. 6(1) lit. a (consent as legal basis) and Art. 7 (requirements for valid consent) · CJEU 'Planet49' (C-673/17, 01.10.2019) · BGH I ZR 7/16 (28.05.2020, Planet49 follow-up) · DSK ruling on Pay-or-Consent (Aug 2024) · EDPB guidelines on consent
Frequently asked
- Is it enough to show the banner once and never again?
- No. As soon as the cookie list changes (new third party, new purpose, different retention), consent must be requested again. And if a user clears what your CMP set (e.g. cookies deleted), the banner comes back — which is correct.
- Can the 'Accept' button be more prominent than 'Reject'?
- No. The German DSK clarified in August 2024: rejecting must be possible with the same effort as accepting — no dark patterns, no hidden menu, no 'three clicks deep' effect. Otherwise the consent is not free and is invalid.
- What counts as a 'strictly technically necessary' cookie?
- Very little: session cookies for login, shopping cart contents, CSRF tokens, language preference on direct user request. Statistics cookies, marketing pixels, tracking, embedded YouTube/Maps frames are NOT strictly necessary — even if 'just for reach measurement'.
- I use Google Tag Manager. What do I need to check?
- The Tag Manager itself is usually not the problem — the tags it serves are. Make sure no marketing or statistics tags 'fire' BEFORE consent. Google Consent Mode v2 helps but is not automatically compliant — if you use 'Basic Consent Mode', hits are still sent (in restricted form). 'Advanced' plus a real block by the CMP is safer. Auditing via Chrome DevTools (Network tab before clicking consent) is the easiest test.
- Does the TDDDG apply to my mobile app too?
- Yes. § 25 TDDDG talks about 'end devices' — smartphones, tablets, smart TVs and IoT devices count just as much as laptops. So tracking SDKs (Firebase Analytics, AppsFlyer, Adjust, Meta Audience Network) must sit behind the consent gate just like browser cookies. iOS tracking permission (ATT) is a separate duty (Apple's App Store) and does not replace TDDDG consent.
- Is 'pay or consent' (pay instead of accepting tracking) allowed?
- Limited yes, with conditions. The DSK clarified in August 2024: only if the paid offer is a 'real' service (no feature downgrade), the price is reasonable, and users are not pushed into a de-facto forced situation. The CJEU (Meta ruling 2023) and EDPB opinion 4/2024 set strict requirements. Pure 'accept tracking or pay EUR 9.99/month' models are highly risky in practice — warning letters very likely.
Need support?
Let's talk for 30 minutes. I'll look at your situation and tell you what makes sense as a next step.
Book a slot