Cookie Banners and Consent Management: Legally Compliant Implementation

TL;DR

The consent requirement for cookies arises from Section 25 TDDDG (formerly TTDSG), which transposes the ePrivacy Directive into German law. The GDPR applies additionally for the processing of the collected personal data.
Technically necessary cookies (session cookies, shopping cart, language settings) may be set without consent. For all other cookies (analytics, marketing, social media), prior consent is required.
Dark patterns in cookie banners (hidden reject button, misleading colors, nudging) violate the voluntary consent requirement and are sanctioned by supervisory authorities.
A Consent Management Platform (CMP) automates the collection, documentation, and enforcement of consent. The CMP must actually block cookies until consent is given.
Settings must be changeable at any time. A permanently visible element (icon, link in the footer) for accessing consent settings is best practice.

Legal foundations: Why cookie banners exist

Cookie banners are not the invention of overzealous data protection advocates but the consequence of two legal frameworks working together: the ePrivacy Directive (2002/58/EC) and the GDPR.

Section 25 TDDDG (formerly TTDSG): Consent for device access

Since December 2021, Section 25 TDDDG (Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz, formerly TTDSG) transposes the ePrivacy Directive into German law. The core rule: storing information on the user's device or accessing already stored information is only permitted with consent.

This applies not only to cookies in the strict sense but to all technologies that store or read information on the user's device: cookies, local storage, session storage, fingerprinting, pixel tags, web beacons.

Consent under Section 25 TDDDG must meet the GDPR requirements: freely given, informed, unambiguous, through an affirmative action.

The exception: Technically necessary cookies

Section 25(2) TDDDG defines two exceptions for which no consent is required:

Transmission of a message. Cookies that are strictly necessary for the technical transmission of a message over an electronic communications network. Example: load balancer cookies that direct the user to a specific server.

Service explicitly requested by the user. Cookies that are strictly necessary to provide a service explicitly requested by the user. Examples: session cookies for login, shopping cart cookies in an online shop, language setting cookies, CSRF tokens.

Everything else requires consent: analytics cookies (Google Analytics, Matomo with cookies), marketing cookies (Google Ads, Meta Pixel, retargeting), social media cookies (like buttons, share buttons), personalization cookies.

GDPR as the second layer

As soon as the cookies process personal data (which is practically always the case with analytics and marketing cookies), the GDPR applies. The GDPR then governs on which legal basis the processing of the collected data occurs — typically based on consent (Art. 6(1)(a)).

In practice, this results in a double consent requirement that can be obtained with a single consent mechanism: consent under Section 25 TDDDG for setting the cookie, and consent under Art. 6(1)(a) GDPR for processing the collected data.

Requirements for a lawful cookie banner

No pre-selection, no opt-out

Cookies must only be set after active consent, not before. Technically this means: on the first page load, no consent-required cookies may be set. The cookie banner appears, the user makes their choice, and only then are the corresponding cookies activated.

Pre-ticked checkboxes ("Marketing cookies: enabled") are impermissible. The user must actively consent, not actively object.

Equal rejection option

The user must have the option to reject non-essential cookies, and this option must be as easily accessible as acceptance. This is the point where most cookie banners fail.

Impermissible:

"Accept all" as a prominent green button, "Reject" as a small gray text link in the corner
"Accept all" on the first layer, "Reject" only after clicking "Settings" on the second layer
No reject button, only "Accept" and "Individual settings"
"Continuing to browse = consent" (this is not an active action)

Permissible:

"Accept all" and "Reject all" as equal buttons side by side on the first layer
"Accept all" and "Only necessary" as equal buttons on the first layer

The French supervisory authority CNIL fined Google and Facebook in 2022 for 150 million and 60 million euros respectively because rejecting cookies required more clicks than accepting them. The message is unmistakable: reject must be as easy as accept.

Granularity: Purpose-specific consent

The user must have the option to consent separately for individual purposes. Typical purpose categories:

Necessary: Always active, not deselectable
Functional: Extended features such as embedded videos, live chats
Analytics/Statistics: Usage analysis, heatmaps, A/B testing
Marketing: Ad tracking, retargeting, conversion measurement

A blanket consent ("All or nothing") is not sufficient. The user must be able to accept analytics and reject marketing, and vice versa.

Transparent information

The cookie banner must inform the user about:

Which cookies and tracking technologies are used
For what purpose they are used
Who receives the data (particularly for third-party cookies)
How long the cookies are stored
That consent can be withdrawn at any time and how

This information does not need to appear entirely on the first layer of the banner. A second detail layer ("Cookie details" or "Learn more") is permissible, as long as the key information is recognizable on the first layer.

Technical blocking before consent

This is the technically most demanding point: consent-required cookies and tracking scripts must not be loaded until the user has consented. It is not sufficient to display a banner while loading Google Analytics in the background. The Consent Management Platform must actually block the scripts until consent is given.

Typical implementation approaches:

Script blocking: The consent-required scripts are embedded in the HTML code with a modified type attribute (e.g., type="text/plain" instead of type="text/javascript"). The CMP changes the type attribute only after consent, so the script is executed only then.

Tag manager integration: The CMP communicates with a tag manager (Google Tag Manager, Matomo Tag Manager) that only fires the scripts when the corresponding consent category is present.

Server-side tagging: Data collection occurs through your own server that only becomes active when valid consent exists. This approach is technically more complex but more privacy-friendly.

Dark patterns: What is prohibited

Dark patterns are design patterns that manipulate the user to force a particular decision. In the context of cookie banners, they are widespread and are increasingly sanctioned by supervisory authorities.

Prohibited design patterns

Color nudging: The "Accept" button is green/blue and prominent, the "Reject" button is gray and inconspicuous. The color scheme steers the user toward acceptance.

Asymmetric click depth: "Accept all" requires one click, "Reject" requires three clicks through sub-menus. The effort to reject is disproportionately higher.

Confirmshaming: Texts like "No, I don't want a better user experience" or "Without cookies, we can't help you" apply psychological pressure.

Cookie walls: "Without consent, you cannot use this website." A cookie wall that completely blocks access to the website is, according to the prevailing opinion of German supervisory authorities, impermissible because it nullifies the voluntariness of consent. In other EU countries (France, Austria), this is partly evaluated differently, especially when a paid, cookie-free alternative ("Pay or Okay") exists.

Pre-set sliders: Sliders for marketing cookies default to "on." This is functionally identical to a pre-ticked checkbox and therefore impermissible.

Repeated prompting: The user rejects, and the banner reappears on the next page load. A one-time rejection must be respected. The banner may only be shown again after a reasonable period (supervisory authorities suggest 6 to 12 months).

Consent Management Platforms (CMP): Selection and configuration

What a CMP must deliver

A CMP (also consent management tool or cookie consent solution) handles the technical implementation of consent management. A good CMP offers:

Banner creation: Configurable interface for the cookie banner with multiple layers
Purpose management: Definition and management of cookie categories and purposes
Cookie scanning: Automatic detection of cookies used on the website
Script blocking: Technical blocking of scripts before consent
Consent storage: Storage of the user's consent decision (typically in a first-party cookie)
Consent proof: Documentation of each consent decision with timestamp, version of the consent declaration, and selected options
Withdrawal mechanism: Ability for the user to change their settings at any time
Reporting: Analysis of consent rates and patterns

Well-known CMP providers

There are numerous CMP providers on the market. Some of the best known:

Cookiebot (Usercentrics): Widely used in Europe, automatic cookie scanning, TCF compatible
Usercentrics: German provider, extensive configuration options, app SDK available
OneTrust: Enterprise solution with broad functionality
Borlabs Cookie: WordPress plugin, popular in the German market
Klaro: Open-source solution, self-hosted, privacy-friendly
Osano: Focus on simplicity and compliance

Avoiding configuration mistakes

Mistake 1: Cookie scanning not current. The CMP scans the website once and identifies the cookies. If you later add new tracking tools, the scan must be repeated. Otherwise, the new cookies are not captured by the consent mechanism and are set without consent.

Mistake 2: Scripts not actually blocked. Some CMP implementations display a banner but do not technically block the scripts. The banner is then just a facade. After implementation, use the browser developer tools to check whether no consent-required cookies are actually set before the user consents.

Mistake 3: Google Consent Mode misconfigured. Google Consent Mode allows Google tags to be loaded without cookies and to activate full functionality only after consent. Configuration is complex: in "Basic Mode," the tags are completely blocked; in "Advanced Mode," the tags send cookieless pings even without consent. Which mode is privacy-compliant depends on the specific implementation.

Mistake 4: No permanent withdrawal mechanism. The user consents but wants to change their settings a week later. How do they find the settings dialog again? Best practice: a permanently visible element, typically a small cookie icon in the lower left corner or a "Cookie settings" link in the footer.

Special case: Analytics without consent

Many organizations look for ways to gather usage statistics without displaying a cookie banner. There are indeed scenarios where this is possible:

Server-side analytics

If analytics is performed exclusively on the server side — meaning no information is stored on or read from the user's device — Section 25 TDDDG does not apply. Analyzing server log files (IP address, referrer, user agent, timestamp) is technically possible and does not require cookie consent. However, you are processing personal data (IP address), for which you need a legal basis under the GDPR. Art. 6(1)(f) (legitimate interest) may apply if you anonymize or pseudonymize the IP addresses.

Cookieless analytics tools

Some analytics tools work without cookies and without storing information on the device: Plausible Analytics, Fathom Analytics, Matomo (in its cookieless configuration). Whether these tools can actually be used without consent depends on the specific configuration. If no cookie is set and no fingerprint is created, the consent requirement under Section 25 TDDDG does not apply. For the GDPR, you still need a legal basis — typically legitimate interest with an appropriate balancing of interests.

Matomo with opt-out instead of opt-in?

Matomo (formerly Piwik) is often promoted as a privacy-friendly alternative to Google Analytics that can be used without cookie consent. This is only true under certain conditions:

Matomo is self-hosted (not the cloud version)
IP addresses are anonymized before storage
No cookies are set (cookieless tracking mode)
No browser fingerprinting
Data is not shared with third parties

Under these conditions, Matomo can, according to some supervisory authorities (CNIL, DSK), be used without consent. Other supervisory authorities take a stricter view. Check the position of your competent state authority.

Documentation and proof of consent

You must be able to demonstrate that every user whose data you process via cookies has given valid consent. The TOMs for storing consent data should be documented. To this end, you must store and keep available the following information:

Consent ID: Unique identifier of the consent decision
Timestamp: When was consent given (or refused)?
Version: Which version of the cookie banner and cookie policy was in effect at the time of consent?
Selected options: Which categories were accepted, which were rejected?
Withdrawal: Was consent subsequently changed or withdrawn?

Most CMPs store this information automatically. Verify that the retention period is sufficient (at least for the duration of the data processing) and that the data can be exported (in case of an audit by the supervisory authority).

Cookie policy: Mandatory document

In addition to the cookie banner, you need a cookie policy (also cookie notice) that provides detailed information about the cookies and tracking technologies used. It can be part of the privacy notice or published as a standalone document.

Mandatory contents:

Which cookies and tracking technologies are used?
For what purpose?
Who is the provider (first-party or third-party)?
How long are the cookies stored (expiration date)?
What data is collected and to whom is it disclosed?
How can the user manage cookies (browser settings, CMP)?
How can consent be withdrawn?

Keep the cookie policy current. When you add a new tracking tool, the policy must be updated. A regular cookie scan (quarterly) helps maintain oversight. In ISMS Lite, the cookie policy can be maintained as a versioned document with change history, so you can demonstrate during an audit which version was in effect at which point in time.

Audits by supervisory authorities

Supervisory authorities are increasingly auditing cookie banners systematically. The Bavarian supervisory authority (BayLDA) has examined hundreds of websites in several audit waves and issued orders for violations. Your Data Protection Officer should also regularly review the cookie configuration. The CNIL in France and the AEPD in Spain also conduct regular mass audits.

Typical audit checkpoints:

Are cookies set before consent?
Is the reject button equally accessible?
Does script blocking work technically?
Is the cookie information complete and current?
Is consent documented in a provable manner?
Can the user change their settings at any time?
Are dark patterns being used?

A simple self-test: open your website in incognito mode, open the browser developer tools (F12, "Application" or "Storage" tab) and check which cookies are set before clicking the banner. If anything beyond your consent cookie and technically necessary cookies appears there, you have a problem.