Does the support widget need consent? § 25 TDDDG

Key insights

• § 25 (1) TDDDG requires consent as a matter of principle for storing and reading information on a terminal device.
• Two unsettled positions exist: the widget as a necessary contact form, or as a service requiring consent.
• The Datenschutzkonferenz reads the exceptions narrowly and often treats automatically loading scripts as requiring consent.
• Breaching the consent requirement is an administrative offence and can be fined under § 28 TDDDG.
• The lowest-risk route is to load the chat script only after the visitor has actively agreed.

Not legal advice, but a clear legal framework

This article is not legal advice. It sets out the legal position around support widgets pragmatically and shows which technical decisions you have to take as a support lead or website owner. Anyone embedding a chat widget in their own website sooner or later faces the question from legal or the data protection officer: does the widget belong in the consent banner, or may it load straight away?

The legal pivot is § 25 of the Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz (TDDDG), Germany's telecommunications and digital services data protection act. This section governs the protection of privacy on terminal equipment and draws a precise line between operations requiring consent and statutory exceptions.

The principle under subsection 1. The exception under subsection 2.

Under § 25 (1) sentence 1 TDDDG, storing information on the end user's terminal equipment or accessing information already stored there is permitted only where the user has consented beforehand on the basis of clear and comprehensive information¹. Supervisory authorities read the provision as technology-neutral, so it covers every technique and procedure by which information can be stored and read, including Local Storage, Session Storage or IndexedDB².

§ 25 (2) no. 2 TDDDG carves out a narrow exception to that principle: consent is not required where the storage or access is strictly necessary in order for the provider of a digital service to make available a digital service expressly requested by the user¹.

A clean separation between the TDDDG and the General Data Protection Regulation (GDPR) matters here: the TDDDG protects the integrity of the terminal device entirely regardless of whether the data read or set is personal. The GDPR applies on top, as soon as personal data such as IP addresses or chat content is processed.

Position 1: the widget as a necessary contact form

The first legal view treats the support widget essentially as a modern, always-present contact form. Its proponents argue that customer support is a fundamental core function of any digital offering. Anyone visiting a website or web app expects a way to make direct contact.

Session persistence as a technical necessity.

Technically, an interactive support widget needs an identifier in the browser's Session Storage or Local Storage. Without it, the chat history would break off the moment the visitor changes page or reloads the tab. Position 1 therefore argues: if support is being offered, setting this purely functional session identifier is technically indispensable to keep the conversation alive across several pages.

On that premise, companies rely on the exception in § 25 (2) no. 2 TDDDG, which dispenses with consent where access is strictly necessary to make available a digital service expressly requested by the user¹. The script is filed under Necessary or Essential in the consent management tool and loads immediately on the first page view, without the visitor having to tick a box in the banner first.

• The support channel is treated as a standard route of contact, comparable to email links or contact forms.
• Storing the session ID serves solely to provide the dialogue and involves no tracking.
• The handover and help functions are available to customers immediately, with no barrier and no prior consent click.
• The script is listed in the consent banner as an essential service and loads automatically with the page.

Position 2: the strict view of the Datenschutzkonferenz

The Datenschutzkonferenz (DSK), the joint body of the independent federal and state data protection authorities in Germany, takes a markedly stricter view. In its guidance for telemedia providers it holds that § 25 (1) establishes the principle that consent is required, and that only the two narrowly drawn exceptions in subsection 2 depart from it². The legislature deliberately stayed very close to the wording of the European rule and added no further exceptions, so only a few services can be embedded without consent².

Automatic loading without interaction is not an express request.

In the authorities' view, that is precisely the sticking point with an automatically loading chat widget: the visitor opens a website to find out about a product or to read an article. At that moment she has not expressly requested the support service at all. On the wording of the law, the exception applies only where access is strictly necessary in order to make available a digital service expressly requested by the user¹. The Datenschutzkonferenz stresses that these two elements are inseparably linked and that strict necessity must always be assessed in relation to the specific service requested, which calls for a granular look at individual functions of a website². If the script already loads in the background and sets a device identifier before the user has actively clicked the chat symbol, then on this reading the express-request criterion is missing.

Authorities also point out that many common widget scripts already collect device and browser data on initialisation, transmit IP addresses to third-party servers, or load fonts and third-party resources. The consent requirement applies regardless of whether the information stored or read is personal². Timing matters too: consent must be in place before the terminal equipment is accessed. On this strict reading, loading a widget across every page as a matter of course requires consent.

Practical consequences: load on click, or a banner category?

The legal classification is not a theoretical exercise. It dictates exactly how your widget has to be implemented technically and wired into your consent management system. Whichever of the two legal views you settle on, you have to pick the matching technical architecture.

Option A: immediate loading as an essential service.

If your company classifies the widget as strictly necessary, you file the script under Essential or Necessary in your consent tool. The widget loads asynchronously on page view. The visitor sees the support button in the corner of the screen straight away. The benefit: maximum availability and no barrier to entry for people looking for support.

Option B: control through the consent banner.

If your company follows the data protection authorities' view, the widget belongs in the Functional or External Media category. In practice that means the script is blocked by the consent banner and injected only once the user actively clicks Accept all or selects Functional in the banner. If the visitor declines, the widget stays completely invisible to her. In that case it is worth providing static contact options in the footer or a public Help Centre as a fallback.

Option C: the two-click solution with a placeholder.

An elegant alternative to blocking via the banner is loading on click. Here no external script and no cookie is loaded to begin with. All that sits on the page is a local placeholder icon. When the visitor actively clicks that chat symbol, she thereby confirms an express request for the support service. Only that click triggers the widget script being loaded dynamically. This fits the wording of the exception in § 25 (2) no. 2 TDDDG, which exempts access only for a digital service that has been expressly requested¹.

1. 01Variant 1 (essential): the script loads directly. High reachability, requires solid documentation within the company.
2. 02Variant 2 (banner opt-in): the script loads only on agreement in the banner. Losing the chat channel whenever the banner is declined.
3. 03Variant 3 (two-click loading): a placeholder loads the script only on active interaction. High legal certainty while visibility is preserved.

Documentation: why a decision on its own is not enough

Whichever route your team picks: an informal decision in the support Slack or a verbal agreement will not stand up to an authority's inspection. Art. 5 (2) GDPR imposes the accountability principle. You must be able to demonstrate and justify at any time why a tool is deployed the way it is.

Entry in the record of processing activities.

Every support system in use must be entered in the record of processing activities (RoPA) under Art. 30 GDPR. The purposes of processing, categories of data subjects, recipients of the data, retention periods and the legal bases relied on under the TDDDG and the GDPR all have to be set out there transparently.

On top of that, your website's privacy notice has to break down the use of the widget in detail. Where identifiers are set, the retention period, the way it works and the service providers involved have to be named precisely. This is also the basis for answering later user enquiries or formal GDPR access requests confidently and within the deadline.

• A documented justification of the classification under § 25 TDDDG (essential, banner opt-in or two-click).
• Maintaining the entry in the record of processing activities under Art. 30 GDPR.
• A complete clause in the privacy notice naming the service provider, retention periods and purpose of the data.
• A data processing agreement under Art. 28 GDPR concluded with the widget provider.

The lowest-risk route for website owners

Anyone wanting to minimise legal risk has to weigh the possible consequences soberly. Breaches of § 25 (1) TDDDG are not trivial. Under § 28 (1) no. 13 in conjunction with subsection 2 TDDDG, storing or accessing information without consent can be fined up to three hundred thousand euros⁴.

The risk of warning letters from associations and competitors.

Besides fines from the authorities, scripts embedded without transparency always carry the risk of competition-law warning letters from consumer associations or competitors. Scripts that set tracking cookies without banner consent, or transfer data to third countries without an adequate level of protection, are what automated crawlers look for.

By some distance the lowest-risk route is therefore twofold: either you embed the widget with genuine two-click logic, so that no data flows until the chat is clicked, or you assign the widget to the consent-requiring category in your banner. If, on the other hand, you want to load the widget directly as essential, make sure the provider runs no third-party tracking whatsoever, that the data is processed entirely within the EU, and that the justification is documented without gaps in the record of processing activities.

GDPR-compliant AI support with Comlayer

If you want to automate modern customer support without straying into legal grey areas, the right technical foundation matters. What counts is a solution that cleanly separates the interface from the data processing and leaves you full flexibility in how you embed it.

A lean script and flexible loading modes.

The Comlayer widget is embedded through an asynchronous JavaScript snippet. You decide for yourself whether the snippet loads directly in the source, is released by your consent management system after consent, or is initialised dynamically only through a click event on your page. The domain allowlist ensures that your widget key cannot be misused on other domains.

What such a decision looks like once it has actually been taken can be read off Comlayer itself. In its own consent register the support chat is classified as necessary under § 25 (2) no. 2 TDDDG, on the grounds that it is the only support channel on the site and is therefore treated like a contact form. The opposing position is recorded expressly alongside it: the Datenschutzkonferenz counts automatically loading chat widgets among the services requiring consent, because the script loads without any action by the visitor and sets an identifier. Anyone assessing it differently moves the entry into the functional category, ties loading to consent, and raises the banner version so that the question is asked again. That too is not a settled point of law but a reasoned and documented decision — precisely the one this article describes.

Processing in the EU and no model training.

Behind the widget sits a clean European infrastructure for security and privacy: conversations, file attachments and the AI processing all run in European data centres. A data processing agreement under Art. 28 GDPR is provided directly. One essential point for companies: your customer data and support conversations are not used to train AI models. The answers are based on RAG (Retrieval-Augmented Generation) and always supply the link to the source.

The plans are transparently structured: the Free plan gets you started at no cost with the support widget, the Help Centre and two team seats. The Pro plan is aimed at teams putting AI support into production and comes with 500 AI answers included plus your own Help Centre domain. For higher volumes, the Scale plan offers 5,000 AI answers included.

• Flexible embedding: direct loading, coupling to the banner, or a two-click trigger via JavaScript.
• Hosting and AI processing in European regions, with a data processing agreement.
• No training of public AI models on your customer conversations.
• Transparent pricing from the free Free plan through Pro to Scale, with a base price per month, a price per seat and AI answers billed by usage.

Frequently asked questions