Guides

Security & Tech

Cookie Consent and Tracking Under TDDDG: How an Agency Implements It Correctly

Implement cookie consent and tracking under TDDDG cleanly: block scripts, keep proof, allow withdrawal, run a test protocol. Not legal advice.

  • Published:

    October 31, 2026

  • Updated:

    October 31, 2026

  • 19 min read

    Reading time

Key takeaways

  • Under § 25(1) TDDDG, information may be stored on or read from an end device only after clear and comprehensive information and prior consent, with exceptions only for strictly necessary access.
  • Technically correct means that scripts, cookies and embeds that require consent load only after the click, and are not merely hidden behind a banner.
  • According to the DSK guidance (German Data Protection Conference), declining must be as easy as accepting, and withdrawal must be possible the same way as consent.
  • Consent must be provable (Art. 7(1) GDPR), so version, purposes, time and decision belong in the log.
  • Whether an agency can really do this shows in a test protocol with the network tab before and after the decision, not in the claim "GDPR compliant".

By Edip Kilinc, founder of Webwavers. Published on October 31, 2026. Last updated on October 31, 2026. Reading time: about 16 minutes. This text is not legal advice.

Short answer: An agency implements cookie consent under TDDDG (German Telecommunications Digital Services Data Protection Act) correctly when services that require consent load technically only after the visitor has decided, declining is as easy as accepting, withdrawal is possible at any time, and every decision is logged so it can be proven. The standard is § 25 TDDDG, supplemented by the GDPR (DSGVO). Whether a site really meets this, you don't see in the banner but in the browser's network tab before and after the click.

The key points in brief

  • The banner is only the surface. What counts is what loads in the background before anyone clicks.
  • Scripts that require consent must be blocked, not hidden. This applies equally to tag managers, pixels, maps, videos and chat widgets.
  • Proof and withdrawal are not extras. Both are in Art. 7 GDPR and belong in the technical planning.
  • The cleanest solution is often less tracking. Every service you cut is a service you don't have to secure.
  • Ask every agency to show you a test protocol. "GDPR compliant" is a claim, not proof.

Important note: This guide explains the technical implementation and names the relevant legal source in each case. It does not replace legal advice. For your specific case, for example with third-country transfers, special industries or disputes, ask a specialist lawyer or your data protection officer.

Table of contents

What the law says, in three paragraphs

We already described the basics in the post Using cookie banners correctly and in the overview of tools and GDPR. Here is only the short version, so the rest of this guide stays understandable. There you'll also find the explanation of why fewer services are often better than a better banner. This page goes the other way: how do you build the technology so that it delivers what the banner promises?

First: § 25 TDDDG. Paragraph 1 requires that information may be stored on an end device, and information already stored there may be read, only if the end user has consented beforehand on the basis of clear and comprehensive information. For information and consent, the law refers to the GDPR. Paragraph 2 names two exceptions: when the sole purpose is the transmission of a message over a public telecommunications network, and when the storage or access is strictly necessary for a provider to deliver a digital service that the user has expressly requested (§ 25 TDDDG). Important: the provision is tied to storing and reading on the end device, not to personal data.

Second: the GDPR. It sets out what valid consent looks like. The controller must be able to demonstrate consent (Art. 7(1)), and withdrawing consent must be as easy as giving it (Art. 7(3)) (Art. 7 GDPR). Recital 32 requires a clear affirmative act. Silence and pre-ticked boxes do not count as consent (GDPR, recitals).

Third: case law and the supervisory authorities. In case C-673/17 (Planet49), the CJEU ruled on October 1, 2019 that a pre-ticked checkbox is not valid consent for cookies (CJEU, judgment C-673/17, EUR-Lex). The German Federal Court of Justice (BGH) confirmed this for German law in its judgment of May 28, 2020 (I ZR 7/16, "Cookie-Einwilligung II") (BGH, press release 067/2020). The German Data Protection Conference (DSK) summarized its view in guidance for telemedia providers, which it reissued in November 2024 as "Orientierungshilfe für Anbieter von digitalen Diensten" (guidance for providers of digital services) (DSK, press release of November 15, 2024). The guidance is not a legal norm, but it shows how the supervisory authorities audit.

A typical mistake looks like this: the site shows a proper banner with equal buttons. But in the background, the analytics script already runs on the very first page load, because it is hard-coded in the header. The visitor clicks decline, and data still flows. Visually everything is fine, technically it isn't.

The DSK guidance names the problem clearly: cookies that require consent must not be set on the first visit and only asked about afterward. Consent must be in place before access (section III.2.b of the Telemedia guidance 2021). For implementation, that means the banner is only worth something if it controls a technical barrier.

A second common mistake concerns design. If the first level only says "Accept all" and declining is hidden behind "Settings", the DSK sees an imbalance that puts the validity of the consent at risk. It demands that the options offered be designed as equals (sections III.2.d to III.2.f of the same guidance). An opt-out procedure, accordingly, is never suitable for establishing valid consent.

Neither can be solved in design, only in architecture. That is what the next section is about.

Hands holding a tablet with the CSM website
From our work: CSM, Corporate Identity. View case study

The architecture of clean consent

Think of consent as a gate. Everything that isn't strictly necessary waits in front of the gate. Only after the decision is it released, and only the category that was agreed to. A clean implementation consists of five building blocks.

1. Inventory. Before anything is built, there is a list of all external connections and all cookies or storage entries. You get it with the browser's developer tools (Network and Application), ideally complemented by a look at the source code and the tag manager. For each entry you need: provider, purpose, storage duration, provider location, category.

2. Categorization. Every entry is assigned to a category: strictly necessary, statistics, marketing, convenience features/third-party content. The classification "strictly necessary" is narrow. According to the DSK guidance, business model interests don't count, and access and storage must be limited to the minimum (section III.3.b.bb). Cookies with a unique identifier are rarely truly necessary. For storing the consent decision itself, a value without a personal identifier is usually enough.

3. Blocking before the decision. Scripts that aren't necessary are not loaded. Depending on the system, there are three common ways to do this: the script is delivered with a placeholder type and activated only after release, it is triggered through a tag manager only with the matching consent status, or it isn't built into the page at all as long as there is no consent. Which variant fits depends on what you use.

4. Release after the decision. After the click, exactly what was selected is released. If the selection changes later, the state must adjust immediately, without the visitor having to reload, where technically possible. A withdrawal must stop running services and prevent follow-up requests.

5. Log. Every decision is stored with time, version of the banner text, selected purposes and a decision ID. Why this is necessary, you'll see in the section on proof further below.

Which services require consent

The following table is a working aid for the inventory. It does not replace a case-by-case review. The column "Typical classification" describes how the services are usually treated in practice. It isn't binding, because the specific configuration matters.

Service or function Typical classification What to watch for technically
Storing the consent decision Usually strictly necessary Value without a personal identifier, short, justified duration
Language selection, session cookie for login Usually strictly necessary, if requested by the user Set only when the function is used
Shopping cart, payment Necessary only once the function is used Don't set on the first page load
Web analytics with a third-party script Usually requires consent Load only after consent
Advertising and conversion pixels Requires consent Tie to the status via tag manager
Embedded videos Usually requires consent Preview image instead of iframe, load only after a click
Map services Usually requires consent Static image with a click to activate
External fonts Depends on how they are embedded Host locally, then the connection to the third-party server disappears
Chat widgets Usually requires consent Load only after a click on your own button
Social media embeds Usually requires consent Link instead of embed, or two-click solution

Note: even reach measurement isn't automatically part of the basic service. The DSK writes that even the simple measurement of visitor numbers is not to be classified per se as part of the basic service, and deliberately leaves open the question of when measurement without consent can be permissible (section III.3.c). If you want to be sure here, get a legal assessment for the specific solution.

Consent solutions compared

There are essentially four approaches to consent. None is right per se. What matters is that it fits your system, your tracking scope and your internal capacity.

Approach Strengths Weaknesses Fits
Consent management platform (SaaS) Ready-made banners, logging, updates, often a cookie scanner Ongoing costs, additional third party, the script itself has to load cleanly Sites with many services and changing marketing tools
CMS plugin Quick to install, often cheap Depends on plugin maintenance, blocking not always airtight Smaller WordPress sites with manageable tracking
In-house build with your own script Full control, lean, no third-party provider Legal upkeep and documentation are entirely on you Sites with few services and a technical team
No service that requires consent at all No banner needed if nothing requiring consent runs Giving up measurement and third-party content Sites that have been consistently slimmed down

The last row is often overlooked. If a company site really runs only what is technically necessary, no consent banner is needed. Then the load-time costs and the drop-off caused by the banner also disappear. Whether that is realistic for you depends on how you measure inquiries and run campaigns.

What stays the same with every solution is the checklist for selection:

  • Does the solution really block scripts before the decision, or does it only hide content?
  • Are accepting and declining designed as equals on the first level?
  • Can withdrawal be triggered at any time through a permanently visible link?
  • Are decisions logged with version, time and purpose, and can proof be exported?
  • Are there texts in all languages of your site?
  • What data does the provider itself process, where, and is there a data processing agreement?

The last point is not a detail. If you use an external service that processes data on your behalf, Art. 28 GDPR requires a contract that, among other things, stipulates that the service provider works only on documented instructions, takes security measures under Art. 32 and supports you with data subject rights (Art. 28 GDPR).

Tag manager, consent mode and embeds

Many sites load all of their tracking through a tag manager. That is practical, because you can control it in one place. But it is also the most common place for mistakes, because a single misconfigured trigger can undo everything.

Basic rule for the tag manager: Depending on the configuration, the tag manager itself may load early, but the tags inside it may only fire once the consent status allows it. Every tag gets a condition tied to the status of the matching category. Tags without a condition are the classic mistake.

Consent mode: With Consent Mode, Google offers a way to pass the consent status to Google tags (Google, Consent Mode documentation). Technically it makes sense, because the tags adjust their behavior to the status: the usual approach is to set a default value (for example "denied") before the tags load and update it after the decision in the banner. Consent Mode itself doesn't store the selection, your consent solution has to handle that. Whether and which signals may be sent without consent is a legal question that you shouldn't leave to the default setting alone. Have the chosen configuration assessed by your data protection officer or a lawyer before you go live.

Loading embeds after a click: For videos, maps and social widgets, the two-click solution is reliable: the page first shows its own preview image and a short notice. Only when the visitor clicks is the iframe loaded. This is clean independent of the banner, because before the click there is no connection to the third-party server. Consent can then be obtained at the embed itself, as long as the notice is clear and comprehensive.

Host fonts and scripts locally: What you deliver yourself causes no connection to a third-party server. This applies to fonts, icon libraries and many helper scripts.

Tracking in forms: Check whether submitting sends data to third parties before consent is in place. How to connect forms to a CRM cleanly is covered in the guide on website CRM integration.

Tracking without access to the end device

Because § 25 TDDDG is tied to storing and reading on the end device, an obvious question comes up: what if nothing is stored on or read from the device at all? If a solution works exclusively on the server side, without cookies, without local storage and without reading device characteristics, § 25 TDDDG by its wording triggers no consent requirement. The GDPR still applies as soon as personal data is processed.

In practice, that means two things. First, in this case you need a legal basis under Art. 6 GDPR. As possible bases, the regulation names, among others, consent (point a), performance of a contract or pre-contractual steps (point b) and legitimate interests (point f) (Art. 6 GDPR). Which one holds depends on the purpose. Second, you have to inform transparently. Art. 13 GDPR requires, among other things, details on the purpose, legal basis, recipients and, where applicable, transfers to third countries, at the time the data is collected (Art. 13 GDPR).

Whether privacy-friendly statistics solutions, server-side tagging or aggregated analyses hold up legally for your project is a case-by-case question. An agency or your developer team can tell you what is technically possible. You decide on the legal basis together with your data protection officer or a lawyer.

Third countries, contracts and information

If you use services from providers in the US, the question of third-country transfers comes in. In 2023, the European Commission adopted an adequacy decision on the EU-US Data Privacy Framework. On September 3, 2025, the General Court of the European Union dismissed the action of a French member of parliament seeking annulment and upheld the decision on the basis of the facts and law at the time (IAPP, report on the judgment). The judgment can be appealed, and further proceedings are possible. So before using a US service, check whether the provider is certified under the framework, and record the basis on which you transfer data.

For your site, that means in practice:

  • For each service, list the provider, its registered office and the transfer basis.
  • Where the service processes data on your behalf, conclude a data processing agreement under Art. 28 GDPR.
  • Name the recipients and, where applicable, the third country in the privacy policy and in the banner (Art. 13 GDPR).
  • Review the list again whenever the site changes.

For the assessment of individual providers and for disputes, the same applies again: the legal assessment in a specific case is for your legal counsel or professional chamber.

Proof, withdrawal and renewed consent

Proof. Art. 7(1) GDPR requires that you can demonstrate that a person has consented. Technically, that means: per decision, you store at least the time, the version of the banner text, the selected purposes and the decision itself. From a privacy perspective, data minimization applies here again. Record only what you need for the proof. A consent platform often takes this logging off your hands. With an in-house build, you have to build it and retain it yourself.

Withdrawal. The DSK writes: if consent was given through a banner on the website, withdrawal must also be possible this way. A pointer to email, fax, post or a contact form is not enough, and neither is searching the privacy policy for an opt-out option (section III.2.g). The usual approach is a permanently visible link in the footer that reopens the banner or a settings window. After withdrawal, the affected services must stop collecting data immediately.

Renewed consent. If something material changes, such as a new service, a new purpose or a different provider, the old consent no longer fits. Plan a version number for the banner text and trigger a new prompt for relevant changes. How long consent should last is not a statutory requirement but a judgment call. You'll find the common practice in the post on the cookie banner.

The test protocol: how to check it yourself

Anyone can run this test in a few minutes, even without a developer background. You need a fresh browser window without stored cookies (the easiest is a private window) and your browser's developer tools.

  1. Open the developer tools and switch to the Network tab. Enable "Preserve log".
  2. Load the homepage without clicking anything in the banner.
  3. Look at all requests to external domains. These are all domains that aren't your own.
  4. Switch to the Application (or Storage) tab and check cookies, local storage and session storage.
  5. Click decline and repeat the check. Then load a second page.
  6. Reopen the settings through the footer link, give consent for one category and check that only this category loads.
  7. Withdraw consent and check that no new requests appear.
Check Expectation Typical mistake
First visit, before the click No requests to tracking or advertising domains, no tracking cookies Script in the header loads immediately
After "Decline" Still no requests to these domains Banner hidden, scripts keep running
First level of the banner Accept and decline as equals Decline only under "Settings"
Embeds (video, map) No connection before the click Iframe loads on page view
After a partial selection Only the selected category active All or nothing
After withdrawal No new requests Continued data leakage
Second subpage Same behavior Only the homepage is clean
Submit a form No additional third-party requests without consent Tracking pixel fires on submit

An agency that takes its work seriously hands you exactly this protocol before the site goes live, ideally with screenshots of the network tab. Repeat the test after every major update and at least once per quarter, because new scripts sneak in easily, for example through a marketing plugin or a new embed.

Multilingual sites and consent

On multilingual sites, three points are added. The banner and the privacy information must be available in every language in which the site is offered, because the information has to be clear and comprehensive. Switching languages also shouldn't lead to a contradictory prompt: plan for the decision already made to be kept when the language changes, and clarify with your data protection officer how you document that. And the services can differ per language version, for example if the English site embeds a chat. How to set up a multilingual site technically is covered in the guide on the multilingual company website.

Industries: utilities and law firms

Energy and utilities. On utility sites, information pages, calculators, customer portals and campaign pages come together. Separate the areas: calculators and forms often need no third-party scripts, campaign pages do. More on the page Web design for energy.

Consulting and law firms. Inquiries are often sensitive. A client form shouldn't trigger third-party pixels, and the privacy information at the form should say clearly where the data goes. Whether additional professional-conduct requirements apply, you clarify with a qualified person. Background: Consulting and agencies.

Questions to ask an agency

If you're choosing an agency for a relaunch or a new build, these questions help you check the quality of the consent implementation:

  • Will you show me a test protocol from a previous project, with the network tab before and after the decision?
  • How do you make sure tags in the tag manager fire only after consent?
  • How do you handle embeds such as videos and maps?
  • Which consent solution do you recommend and why? What happens if the provider goes away?
  • How is the proof stored, and who has access?
  • Who checks again after launch when there are new plugins or scripts?
  • Where does your responsibility end, and where does the legal review by my data protection officer begin?

The last question is the most important. A serious agency tells you openly that it implements the technology but does not give legal advice. Anyone who promises you "100 percent legally secure" is promising something no web agency can guarantee.

When you don't need an agency

If your site is small and uses only what is technically necessary, you don't need an agency for consent. Then a clean inventory, locally hosted fonts and a note in the privacy policy are enough. Even for a WordPress site with manageable tracking, a well-maintained plugin can be enough, if you check it regularly. An agency pays off mainly when many services are involved, when a tag manager and campaigns are running, when the site is multilingual, or when a relaunch is coming up in which you're setting up the architecture anew anyway.

The Webwavers team at the German Brand Award 2026
The Webwavers team at the German Brand Award 2026.

How we implement this

At Webwavers, a project runs through the steps on our process page: initial consultation, onboarding with a briefing, strategy session, design in Figma, development and launch with training, with a dedicated project manager and a feedback round after every milestone. Depending on the project, development happens in Webflow, Framer or WordPress.

Cookie consent is not a separate step on this process page. So bring the topic into the initial consultation deliberately: which services you use, which tools your marketing needs and who is responsible for privacy on your side. Get the scope and depth of the review in writing before you commission. Webflow is our focus, but we also implement WordPress, TYPO3 and headless systems and advise neutrally on which system fits your tracking scope. More on the page Web development. The legal assessment stays with your data protection officer or your lawyer.

Ready for a conversation? Then write to us through the contact page.

FAQ

Which web development agencies implement cookie consent under TDDDG technically correctly?

You can't tell by the name, only by the proof. An agency that does it correctly shows you a test protocol with the network tab before and after the decision, explains how scripts are blocked, and states clearly that the legal assessment lies with you and your data protection officer. The questions in the section "Questions to ask an agency" help with the selection.

Is a cookie banner enough for my site to be fine under TDDDG?

No. Under § 25(1) TDDDG, consent must be in place before information is stored on or read from the end device. A banner that only forms the surface while scripts are already loading does not meet that. What matters is that services requiring consent are technically blocked until the decision is made.

Does declining in the banner have to be as easy as accepting?

The DSK guidance demands equal options and takes a critical view when the first level only says "Accept all" and declining sits behind a settings menu. The guidance is not a legal norm, but it shows the standard the supervisory authorities apply. If in doubt in a specific case, ask a professional.

Do I always need consent for web analytics?

Not automatically, but often. The DSK does not categorically classify even the simple measurement of visitor numbers as part of the basic service. Purpose and technical implementation are decisive. If the solution does not access the end device, § 25 TDDDG triggers no consent requirement, but the GDPR still applies and needs a legal basis. Have this legally reviewed for your solution.

How long do I have to keep consents, and what must the log contain?

The law names no fixed period. Art. 7(1) GDPR requires that you can demonstrate the consent. In practice, the time, the version of the banner text, the selected purposes and the decision belong in the log. Set the retention period with your data protection officer and stick to data minimization.

How can I check myself whether my site tracks before consent?

Open a private browser window, the developer tools and the Network tab, load the page without clicking, and look at the requests to external domains. Then check cookies and storage. Repeat the test after declining, after partial consent and after withdrawal. The table in the section "The test protocol" lists all the checks.

What applies if I use services from US providers?

Then third-country transfers come in. The General Court of the EU dismissed an action against the adequacy decision on the Data Privacy Framework on September 3, 2025. Check whether your provider is certified, conclude a contract under Art. 28 GDPR for processing on your behalf, and inform under Art. 13 GDPR. The legal assessment in a specific case is for your legal counsel or professional chamber.

Sources

More guides

All guides
Chrome 3D Webwavers WChrome 3D Webwavers W

Contact

Start your next digital chapter

Request a project