LW IT Solutions
« Blog Overview /Data Privacy / Germany’s Consent Management Regulation: What a Recognised...

Germany’s Consent Management Regulation: What a Recognised Service Must Do and What Stays Voluntary

Germany's Consent Management Regulation: What a Recognised Service Must Do and What Stays Voluntary
Contents
  1. What the regulation demands
  2. The question that stays open
  3. Why it is remarkable anyway
  4. What a site can do with this today
  5. Questions and answers
  6. Sources

The idea is old and obvious: a person decides once what they permit, and every site abides by it instead of asking again. In Germany that has become a legal basis – Section 26 TDDDG and the consent management regulation belonging to it, in force since 1 April 2025.

Since 17 October 2025 there is also a first recognised service. The mechanism therefore exists in full: a regulation, a register, a provider, a plug-in. What it does not bring along is a reason for a website to use it.

A sequence diagram with four lifelines for person, browser plug-in, recognised service and website; numbered arrows show the one-time setting of preferences, the storing of the decision and the page visit, with two dashed frames below for the case where the site queries the service and the case where it does not
Messages one to three always run. Whether the fourth runs is decided by the site alone – and the lower frame shows what happens when it does not.

What the regulation demands

A service is recognised only if it meets certain requirements, and those are visibly designed to make it unobjectionable. It must offer a transparently designed interface in which settings can be viewed, changed and revoked at any time. It must operate in a competitively neutral way – every provider of digital services can request data under the same conditions. And the person must be able to switch to another recognised service at any time and easily.

Those three points answer the obvious objection that a central consent store is itself an instrument of power. They answer it properly. They simply do not answer a different question.

The question that stays open

Integration by providers of digital services is voluntary. No site is obliged to query the service before showing its own banner, and the effectiveness of the whole construction hangs on exactly that.

For a site the arithmetic is uncomfortable. A banner it puts up itself yields a consent whose wording and defaults it knows. A signal from outside may yield a refusal it did not word. Weighing the two while looking only at one’s own revenue does not lead to integration – which is why participation sits where it sits.

Who obliges whom to what

  regulation -> service    requirements on interface,
                           competitive neutrality, switchability
  regulation -> website    nothing

  person     -> service    sets preferences, revocable at any time
  website    -> service    queries, if it feels like it

  Exactly one edge in this list is voluntary, and it is the only
  one without which the rest has no effect.

Why it is remarkable anyway

Something similar was meant to appear at European level. The Digital Omnibus of November 2025 provided in Article 88b for a machine-readable consent signal – a preference expressed once in the browser or the operating system, to which sites would adhere. Reports have it that the Council compromise of June 2026 struck that article; Parliament has not settled its position, so nothing is decided, and compromise texts are negotiating drafts.

The situation therefore stands the wrong way round. At the level that could oblige, the obligation is contested. At the level that already has a working mechanism, it is absent from the start. Germany has the technology without the lever; the EU is negotiating the lever without the technology.

What a site can do with this today

The honest answer for most is: watch. As long as adoption is small, integrating changes nothing measurable about the number of banners, and the work does not pay for itself out of the benefit.

Two reasons nonetheless argue for knowing the procedure. The first is direction: a consent setup that stores its own decision cleanly per purpose, and could draw it from an interchangeable source, is better prepared for any future rule than one in which the purposes are fused in the banner text. The second is how supervisory authorities see it: a site that ignores a machine-readable refusal while one is technically present argues from a weaker position at the next inspection.

What stands here is a description of the legal position and not legal advice. The state of play summarises easily: the mechanism is finished, the register is public, and the decisive edge is dashed.

Questions and answers

Does integrating a recognised service replace the site’s own banner?

No, it supplements it. A signal exists only for people who use a recognised service and have set preferences there; everyone else is still asked through the site’s own banner. As long as adoption is low, the banner therefore stays the same for almost every visitor.

What does storing consent “cleanly per purpose” mean in practice?

It means the decision exists as a record and not merely as a click on a button. Such a record holds, separately for each purpose:

  • the purpose itself, such as statistics, marketing or embedded content, each with its own value for granted or refused;
  • the source of the decision, that is the site’s own banner or a signal from outside;
  • the time and the version of the banner text the decision refers to.

The tags on the page then read only the value for their purpose and do not know where it came from. That is exactly what makes the source interchangeable: a recognised service or a future browser signal fills the same fields as the banner, and nothing changes in the tags.

Where the purposes are fused in the banner text instead and a single button permits everything at once, a signal from outside that, say, permits statistics and refuses marketing cannot be represented at all. Such a setup would have to be rebuilt for every new source.

Lukas Wojcik

Lukas Wojcik

Systems architect and technology enthusiast specializing in scalable tracking solutions, GMP Stack (GA4 & GTM), and robust backend architectures. Advocate for clean code and privacy-first design.

Get in Touch

Briefly describe your project or inquiry for a tailored response. This site is protected by reCAPTCHA.

Write a comment

Observations from other implementations, objections and questions are welcome here.

The email address is not published. Required fields are marked with an asterisk.

ALL ARTICLES & CATEGORIES

CCTV

Follow this category by RSS

Cloud & AI

Follow this category by RSS

Data Privacy

All 15 articles in this category Follow this category by RSS

Digital Analytics

All 53 articles in this category Follow this category by RSS

Digital Marketing

All 35 articles in this category Follow this category by RSS

IT & Networks

All 17 articles in this category Follow this category by RSS

Music Production

All 12 articles in this category Follow this category by RSS

Raspberry PI

Follow this category by RSS

Smart Home

All 18 articles in this category Follow this category by RSS

Web Development

Follow this category by RSS

WordPress Plugins & Tricks

Follow this category by RSS