Cookie Policy


1.1 Bundling of Consents under TTDSG and GDPR
1.2 Consent to Different Purposes
1.3 Multilayered Design
1.4 "Accept All" Option
1.5 Overall Required Information
1.6 Revocation Option Directly on the Website
1.7 No Storage/Reading Before Consent
1.8 "Remember" Consent/Rejection

JURISPRUDENCE 2.1 Design of the Consent Button


The requirements for the design of cookie banners listed in this section stem from the "Guidance for Providers of Telemedia from Data Protection Authorities dated December 20, 2021" (hereinafter also referred to as "Guidance").

The following quotes (printed in italics) are taken from the Guidance, unless otherwise stated.

For more detailed information, please refer to the Guidance itself. You can access it at the following link:

The opinion of data protection authorities is not legally binding. The decision ultimately lies with the courts. To the extent possible, the Guidance incorporates the requirements arising from previous case law regarding the design of cookie banners.

1.1 Bundling of Consents under TTDSG and GDPR

For the use of cookies, two types of consents may be required:

  • firstly, the consent required under § 25 para. 1 sentence 1 TTDSG for the storage of information on the user's terminal device or access to such information already stored on the terminal device,
  • secondly, the consent, which may be required as the legal basis for a planned further processing of the data read out in accordance with Art. 6 para. 1 lit. a GDPR.

The former consent may be required regardless of whether personal data is processed or not, whereas the latter consent specifically concerns the processing of personal data.

According to the Guidance, both consents can be obtained through the same action, such as clicking a button.

However, for the request, it must be clearly recognizable that the consent also applies to subsequent processing, and the information provided in connection with obtaining consent must clearly refer to data processing processes (and not just the technical use of cookies or similar).

According to the Guidance, the requirements for obtaining consent are comparable for both of the aforementioned consents.

1.2 Consent to Different Purposes

Regarding the integration of processing operations requiring consent, the Guidance states:

"Only if end-users are provided with sufficient information about all purposes for which access to the terminal device is to be granted, can they understand for which cases they give their consent. End-users must then also be able to consent or decline to the different purposes separately. If the necessary granularity is missing, this also has further implications for the voluntariness and thus the effectiveness of the consent."

"...that the requirement of specificity cannot be met by vague or general indications such as "Improvement of user experience", "Advertising purposes", "IT security purposes", or "future research."

"When website or app operators use such consent banners to request consent, the following requirements must be observed in particular:

  • When a website or app is first opened, the consent banner appears, for example, as a separate HTML element. This element typically consists of an overview of all processing operations requiring consent, which are explained sufficiently, including the involved actors and their functions, and can be activated via a selection menu. Activation in this context means that the selection options must not be pre-set as "activated".
  • [...]"

1.3 Multilayered Design

Regarding the question of a multilayered design, the Guidance states:

"In principle, it is possible to design consent banners in a multilayered manner, i.e., to provide more detailed information only on a second level of the banner that users can access via a button or link. However, if there is already a button on the first level of the banner that allows consent to be given for various purposes, specific information about all individual purposes must also be included on this first level. It would be too indefinite to provide only generic, general, or vague information about the purposes here, such as "To provide you with a better user experience, we use cookies"."

1.4 "Accept All" Option

Furthermore, it follows from the Guidance that an "Accept All" option or similar should generally only be permitted if there is also the possibility on the same level to decline consent. This could be implemented, for example, by a button on the same level with the label "Reject non-essential cookies".

It remains unclear from the content of the Guidance whether, when including an "Accept All" button, the selection menu with the processing operations requiring consent must be provided on the same level or whether this selection menu can be moved to a subordinate level (so that only a "Settings" button or similar appears on the first level).

However, it is clear from the content of the Guidance that in the case of an "Accept All" option on the same level, specific information about all individual purposes of the processing operations that are to be accepted must be provided, as mentioned under "Multilayered Design" above.

1.5 Overall Required Information

According to the content of the Guidance, in order to obtain effective cookie consent, the following information must be provided overall, possibly including the detailed level:

  • who is accessing the respective terminal device, in what form and for what purpose,
  • what is the duration of the cookies' functionality and whether third parties can access them,
  • whether and to what extent access serves further data processing processes falling under the requirements of the GDPR, with the specific purposes of the subsequent processing processes to be described precisely
  • that a later revocation, in accordance with Art. 7 para. 3 sentence 3 GDPR, no longer affects the lawfulness of access or storage up to the time of revocation.

Since this information is largely included in the privacy policy, a corresponding reference to the privacy policy should be included in the cookie banner, and the privacy policy should be linked in the cookie banner with a clearly labeled link that is recognizable as such.

1.6 Revocation Option Directly on the Website

Furthermore, the Guidance requires that if cookie consent is obtained directly on the website, a revocation option must also be provided directly on the website (emphasis added by the author):

  • "If consent is given directly when using a website, its revocation must also be possible in this way. Refusal options exclusively via other communication channels such as email, fax or even by letter do not meet the requirements. It is also impermissible to refer users to a contact form, as in this case, although the same communication channel (i.e., via the website) is used, the requirements are significantly higher than when obtaining consent (and data would be collected via the contact form that is not required for revocation). If consent is requested via a banner or similar means, it is therefore also impermissible if a privacy policy is initially called up and then has to be scrolled to the correct section to find a revocation option. Such a search process as an intermediate step would be a hindrance that is not compatible with the legal requirements. This detour is also not due to a technical impossibility, since a large number of websites display a constantly visible direct link or icon that leads directly to the relevant settings. It does not even meet the legal requirements if opt-out options on different external websites are mentioned at various points in the privacy policy."

1.7 No Storage/Reading Before Consent

Information may only be stored on end devices or read from them, and the processing of data requiring consent may only take place once users have given consent.

1.8 "Remember" Consent/Rejection

The granting or refusal of consent should be implemented without direct identification of the user. Details can be found on pages 29/30 of the Guidance.


To the extent that previous case law provides guidelines for the design of cookie consent, these are incorporated into the Guidance referred to in Section 1, to the extent apparent.

Judgments on further aspects of the design of cookie banners are listed below.

2.1 Design of the Consent Button

The following further details of the design of the consent button have been criticized by courts as follows:

  • Reject button is completely overshadowed by the accept button Rostock Regional Court judgment of September 15, 2020, case no. 3 O 762/19:

"The fact that the user now has the option with the current cookie banner to limit consent to technically necessary cookies via the 'Use only necessary cookies' section does not change the assessment. It should be noted that this button is not even recognizable as a clickable button. Furthermore, it is overshadowed by the green-highlighted 'Allow cookies' button, which appears pre-selected. Due to this, a large number of consumers will regularly not perceive this option as an equivalent consent option."

  • In addition to the option to accept, only settings are available for selection; a multitude of setting options; the "accept all" button is prominently designed, while the "reject all" button is inconspicuously designed Munich Regional Court judgment of November 29, 2022, case no. 33/O 14776/19:

"Consent can only be considered voluntary if the data subject actually has a choice, i.e., can refrain from giving consent without any disadvantages [...]. This is not the case given the structure of the CMP used by the defendant. On the first page of the CMP […] consent can only be given in full or a separate selection can be made by clicking the 'Settings' button. The 'Accept' button is once again highlighted by a blue marker, making it obvious to the user that clicking it is the fastest way to use the website. The fact that a visitor cannot use the defendant's website without further interaction with the CMP already speaks against a voluntary decision. Furthermore, it is only apparent from the text flow on the first level of the CMP that consent can also be declined. However, the user cannot recognize whether a rejection is associated with disadvantages or additional effort. In any case, refusal of consent is only possible after clicking the 'Settings' button on a second level of the CMP, and therefore involves more effort than simply 'accepting' data processing. Although the described effort seems relatively low, such additional effort is not insignificant given the usual speed and low attention of users on the Internet. It should also be taken into account that the multitude of setting options on the second level of the CMP further complicates the refusal of consent. Once again, the 'Accept All' button is highlighted due to its color and positioning and size, while the 'Reject All' button is inconspicuously designed. There is neither a factual justification for the differential treatment of the options 'grant consent' and 'refuse consent,' nor is one presented or apparent."