GDPR and consent: setting up a website lawfully

Most consent dialogues on the web were added on top of a website that was already finished. That is exactly where the familiar problems come from: scripts start loading while the dialogue is still rendering, purposes are described so vaguely that nobody can tell what they are agreeing to, and rejecting takes three clicks while accepting takes one. In legal terms, however, the dialogue is not an accessory. It is the evidence that a given processing operation has a legal basis at all. Without that evidence, the basis is missing retroactively for the entire period in which data was flowing. That is why the consent question belongs at the start of a website project rather than at the end. If you create a website with AI, map the data flows from the first sketch, because removing them later takes considerable effort.

The European coordination process shows how seriously regulators treat the topic. Following 422 complaints (European Data Protection Board, Cookie Banner Taskforce report) about consent dialogues filed with several European supervisory authorities, the European Data Protection Board set up a dedicated taskforce and published a shared assessment framework in 2023. For breaches of the processing principles, GDPR fines can reach 20 million euros (Article 83(5) GDPR) or four percent of worldwide annual turnover, whichever is higher. In day-to-day practice, complaints from visitors and unfair-competition letters are the more common risk, but the direction is clear: consent is being examined, not assumed.

Section 25(2) TDDDG contains two exemptions: access that serves only the transmission of a message over a telecommunications network, and access that is strictly necessary to provide a service the user has expressly requested. Strictly necessary has to be read narrowly. It covers what does not work technically without the stored value, not what makes operations more convenient or analytics more rewarding. The German Data Protection Conference set out this line in its guidance for telemedia providers (Datenschutzkonferenz), making clear that the provider's own view of necessity is not the deciding factor. The following cases are typically treated as exempt.

What is clearly not covered: audience measurement, marketing pixels, embedded videos, remotely loaded web fonts, map services, chat windows from outside providers and split testing of page variants. German supervisory practice also treats purely statistical measurement as not strictly necessary, even when no names are involved, because writing the value onto the device already triggers the consent requirement. Anyone who wants reach figures without a dialogue therefore needs a method that avoids reading from and writing to the browser, for example server-side evaluation without any recognition token. How strongly such decisions shape structure and loading time is covered in the article on static delivery and PageSpeed 100, and the effect of a page without external embeds can be seen in the demo websites.

Article 7(1) GDPR requires the controller to be able to demonstrate consent. That is an active demonstration rather than a claim: every consent record needs the timestamp, the purposes actually selected, the version of the dialogue and the revision of the information texts that applied at the moment of the decision. Once the list of embedded services changes, the earlier consent is worthless for the new service, so the dialogue has to be shown again. Data minimisation applies to the log itself as well: a pseudonymous record without names and without a full IP address is usually sufficient, because it evidences the decision without building an additional profile.

Under Article 7(3) GDPR, withdrawing consent must be as easy as giving it. In practice that means: if approval took one click, withdrawal must not require three nested menus. A permanent footer entry that reopens the same dialogue and shows the stored selection has proven itself in practice. Just as important, a withdrawal has to stop the affected scripts and remove the values that were set. A dialogue that stores the choice while the loaded services keep running only creates the appearance of control, and it fails a review immediately. How this differs from classic CMS installations with retrofitted extensions is explained in the overview of our approach and services.

The dialogue is only one item on the list. Alongside it sit the information duties of Article 13 GDPR, the record of processing activities under Article 30, processor agreements under Article 28 with every service provider involved in hosting, mail delivery and form handling, plus the provider identification that has been governed by Section 5 of the German Digital Services Act since May 2024. Processing outside the European Union falls under Articles 44 and following of the GDPR; after the Court of Justice of the European Union invalidated the earlier transfer arrangement in case C-311/18 in 2020, transatlantic data flows now rest on the adequacy decision adopted by the European Commission in 2023. Keeping processing and storage inside the EU avoids most of that debate. XICflow is operated by XICTRON in Söhlde, Germany; the details are set out on the company profile page.

Taking stock does not have to take weeks. In our experience a structured pass surfaces most of the open points within a few hours, because the critical cases cluster into a small number of patterns. Start with the network panel in the browser and assign a legal basis to every outgoing connection; then review the dialogue and finally the texts. Comparable review patterns show up in accessibility under the European Accessibility Act and in multilingual sites with hreflang, which is why a combined review pass usually pays off. What is included at which level is set out on the pricing page.