TDDDG (German Telecommunications Digital Services Data Protection Act)

The core of the regulation is Section 25 TDDDG: without consent, such access is only permitted if it is strictly necessary for the service expressly requested by the user.

Until May 2024, the same law was called the TTDSG (Telekommunikation-Telemedien-Datenschutz-Gesetz). The renaming was an adjustment to European digital services law and did not change the cookie rules in substance. If you still read "Section 25 TTDSG" in older articles, contracts or privacy notices, it means the same section as "Section 25 TDDDG" today. In practice, this mainly means: documents bearing the old name are not automatically out of date — but updating the name does no harm to credibility with supervisory authorities and auditors.

Section 25 TDDDG: consent before accessing the device

Section 25 TDDDG is the German implementation of the European ePrivacy requirement on device protection. It protects not primarily personal data but the device itself — laptop, smartphone, tablet — as the user's private sphere. That is why the provision applies regardless of whether the stored or read information relates to a person. This is the point at which many discussions in companies take a wrong turn: the objection "but our statistics are anonymous" is simply not the right question for Section 25 TDDDG.

The principle: consent first, then access

The principle is: storing information on the device and accessing information already stored there are only permitted if the user has consented on the basis of clear and comprehensive information. Every technique by which data is stored on or read from the device is covered — not just classic HTTP cookies. Local storage, session storage, IndexedDB, pixels that set an identifier, and methods that read device properties in order to create a recognition value all fall under it as well.

The chronological order is important. Consent must be in place before the technical access, not at the same time and not afterwards. A banner that is displayed while tags are already firing in the background does not meet the requirement. This is exactly where many set-ups that look clean on paper fail in practice: the consent tool is installed, but the tags are not really blocked and are merely "informed afterwards".

The exception: "strictly necessary"

Section 25(2) TDDDG has two exceptions. First, the case where access serves solely to transmit a message over a telecommunications network. Second — and this is the case of practical relevance — where access is strictly necessary for the provider to be able to provide a digital service expressly requested by the user.

"Strictly necessary" is to be understood narrowly. The yardstick is not what is useful for the business model or makes economic sense, but what is technically necessary for the function requested by the user to work at all. Reach measurement, conversion attribution or personalisation are not functions requested from the user's point of view — they serve the provider. That is why they require consent, even if they are economically important for the company.

The right-hand column is not a free pass. Technically necessary storage must also be described transparently in the privacy notice, and the classification must be correct in each individual case. A session cookie that also carries an analytics feature on the side is no longer a necessary cookie — it is an analytics cookie with a second function. The label in the cookie banner does not decide the legal classification; the actual purpose does.

TDDDG and GDPR: two checks, not one

One of the most common false assumptions in projects is that you check either under the TDDDG or under the GDPR. In fact, there are two consecutive steps, both of which must be passed.

The two-step test in practice

Step one is Section 25 TDDDG and concerns access to the device: may anything be stored or read at all? Step two is the GDPR and concerns the subsequent processing of the data collected in this way: on what legal basis is it processed, how long is it stored, to whom does it flow, and how are data subject rights implemented?

In practice, this means: even if a cookie may be set without consent under Section 25(2) TDDDG, the processing of the associated data is not yet legitimised by this. Conversely, a legitimate interest under Art. 6(1)(f) GDPR does not get you past the consent requirement of Section 25 TDDDG. Anyone who wants to base tracking on legitimate interest is confusing the two levels. For the first step, there is only one route for non-essential technologies: consent.

Then there is third-country transfer. If the data flows to a provider outside the EU, Chapter V GDPR adds a third level of checks. This too must be passed regardless of whether the banner is clean.

Range of fines and risk of cease-and-desist letters

Breaches of the consent requirement are regularly sanctioned via the GDPR, because the subsequent processing then takes place without an effective legal basis. The range of fines under Art. 83 GDPR extends in the higher tier to up to 20 million euros or 4 per cent of worldwide annual turnover, whichever is higher; in the lower tier to up to 10 million euros or 2 per cent.

For mid-sized companies, the theoretical maximum is rarely the real risk. Two other effects are more relevant: the effort of proceedings by a supervisory authority, which can quickly tie up months, and exposure under competition law. Faulty cookie banners are a well-known field for cease-and-desist letters (Abmahnungen) in Germany, and checking is trivial for third parties — a look in the developer console to see whether tags are already firing before consent is enough.

The case law that sets the framework

What constitutes effective consent is only set out in broad terms in the text of the law. The details come from case law — and it is now considerably more specific than many banners reflect.

Planet49 and the BGH ruling "Cookie-Einwilligung II"

The starting point is the 2019 judgment of the European Court of Justice in the Planet49 case (C-673/17). The CJEU clarified that a pre-ticked box does not constitute effective consent. Consent requires an active act; silence, inactivity or a box pre-filled by the provider are not enough. Germany's Federal Court of Justice (BGH) adopted this line for German law with its judgment "Cookie-Einwilligung II" of 28 May 2020 (ref. I ZR 7/16).

These two decisions give rise to the basic pattern of every banner today: no pre-selection, no implied consent by scrolling, no consent through mere continued use of the site.

Administrative Court of Hanover 2025: tag manager and an equivalent reject button

Much more specific for implementation is the judgment of the Administrative Court of Hanover of 19 March 2025 (ref. 10 A 5385/22). The court ruled on two points that affect many existing set-ups. First: the use of Google Tag Manager in itself requires prior consent. The widespread argument that the tag manager is a pure management tool without its own tracking and may therefore load in advance does not hold according to this ruling. Second: a cookie banner needs an equivalent "Reject" button on the first level. A prominent accept button next to a hidden link to the "settings" is not enough.

A practical example of the kind that regularly turns up: a B2B online shop embeds Google Tag Manager directly in the head section of the template and runs Analytics and the Ads conversion tag through it. The consent tool is installed and correctly blocks the two downstream tags — but the container itself is still loaded immediately. On the first banner level there is "Accept all" as a green button and below it a grey text link "Settings". By the standard of the Hanover court, two points are open to challenge here: the container loaded in advance and the lack of an equivalent reject option. The fix is to place the container itself under consent and to offer two visually equivalent buttons on the first level. A detailed account of the judgment can be found at IT-Recht Kanzlei (in German).

A further guideline concerns models in which users are to choose between consent and paid access. The European Data Protection Board took a position on this in its Opinion 08/2024 on "consent or pay" and clarified the requirements for the voluntariness of such constellations.

EinwV and recognised consent management services

Section 26 TDDDG provides that consent can also be managed centrally — via recognised services that store a user's preferences and pass them on to websites. The idea behind this is to reduce banner fatigue: the user decides once, and the decision applies across sites.

Consenter as the only recognised service so far

The Consent Management Ordinance (Einwilligungsverwaltungsverordnung, EinwV) came into force on 1 April 2025 and governs the recognition procedure for such services, often referred to as PIMS (personal information management services). The Consenter service was recognised on 17 October 2025 by the Federal Commissioner for Data Protection and Freedom of Information and, as of August 2026, is the only service entered in the public register. The register is kept by the BfDI (in German).

For operators, the assessment is sober: using a recognised service is voluntary, and adoption has so far been low. The model is currently no substitute for your own consent management. It is a building block worth watching, not a foundation on which to base an architecture today.

Digital Omnibus: planned changes, not yet applicable law

In November 2025, the European Commission proposed a reform with the so-called Digital Omnibus that also affects the cookie rules. Among other things, it is planned to transfer the rule from Art. 5(3) of the ePrivacy Directive into the GDPR as a new Art. 88a, to create exceptions for low-risk purposes such as simple reach measurement, to make one-click rejection mandatory, to introduce a waiting period of around six months before asking again after a rejection, and to recognise machine-readable browser signals.

State of negotiations in August 2026

What is decisive for practice is the state of the procedure: the data protection part of the Digital Omnibus has not been adopted as of August 2026. It is stuck in negotiations between the Council and Parliament, an agreement is expected at the earliest towards the end of 2026, and the final text may differ from the proposal. Everything described above is therefore a draft and not the applicable legal position. The AI-related part of the omnibus package has already been adopted but does not affect the cookie rules.

What this means for planning

Anyone building a consent set-up today plans according to Section 25 TDDDG in its current version. Two preparations are nevertheless sensible because they have no disadvantage even under current law: one-click rejection on the first level, which in any case corresponds to the line taken by the Hanover court, and a clean separation of purposes in tag management, so that individual categories can later be treated differently without rebuilding. What you should not do is run tracking today by invoking a possible future exception.

Distinction: law, tool and implementation

The TDDDG determines what is permitted. Technically, consent is usually implemented via a consent management platform (CMP), which displays the banner, documents consent and blocks tags before consent is given. The platform is the tool, not the legal basis: an installed tool does not make a set-up compliant if the cookies are categorised incorrectly or tags load past the consent.

The operational implementation — which services belong in which category, how tags are blocked correctly, what the documentation looks like and where an existing set-up typically fails — is the subject of a separate practical guide: Section 25 TDDDG in detail. This glossary entry classifies the term; you will find the implementation checklist there.

Finally, the most important classification for decision-makers: the TDDDG is not a niche topic for the legal department but an architectural decision. Anyone who sets up tracking in such a way that every data source becomes worthless without consent shifts their entire steering onto a consent rate they do not control. Anyone who instead separates early between what works without consent — server-side order and revenue data from their own system — and what requires consent remains able to act even as consent rates fall.