Does the consent banner have to be adjusted after every plugin update?

It has to be adjusted when the cookies used or the third-party services embedded change - in the view of the supervisory authorities a new consent is then required for the new case (German Data Protection Conference, guidance for telemedia providers). Whether an update crosses that line is shown by the diff: the same page load without consent before and after deployment. If the list of storage accesses and domains is identical, nothing needs doing; if a new line appears, it needs categorising, blocking or removing.

How do I recognise that a script loads before consent?

Most reliably in a fresh profile without a stored decision: load the page without clicking anything in the banner and log which cookies, localStorage and sessionStorage entries are set and which domains are contacted. The breadth of the check matters - home, category, product, cart, checkout entry and campaign landing pages behave differently because widgets are only loaded there. Tracking pixels count too: delivering them already qualifies as storage (European Data Protection Board).

Is a Content Security Policy enough to satisfy the consent requirement?

No, it serves a different purpose. A policy limits which sources may be loaded and contacted, but it knows nothing about a user's decision and nothing about purposes. It is the second control alongside actual enforcement, which happens server-side or through tag control that is blocked by default. Its greatest benefit for consent upkeep lies in report mode: every unknown script source produces a report and makes drift visible before someone notices it by chance.

How often should the script inventory be audited?

A quarterly rhythm for the full inventory plus a diff after every major update has proven itself (project experience). The quarterly run catches gradual change, for instance resources pulled in by an extension; the diff attributes each deviation to a trigger straight away. In phases with many campaigns an additional run before the promotion starts is worthwhile, because campaign tags are typically added at short notice and rarely removed again.

What does the digital omnibus procedure change about the cookie rules?

Where the rules sit is currently being renegotiated; the Council position of June 2026 deleted the intended article on machine-readable consent signals (Council of the European Union). For operations that means the banner remains a mandatory task for now and the final text is still pending. It is therefore sensible to keep the foundation clean - unambiguous purposes, a versioned inventory, enforcement outside the banner. A future signal could then be connected without rebuilding the configuration.

Does Section 25 TDDDG also apply to localStorage and pixels without personal data?

The provision attaches to storing information in terminal equipment and accessing it, not to personal data (TDDDG, Section 25). It is therefore technology-neutral and covers localStorage, sessionStorage, cache entries and comparable techniques alongside cookies. The European Data Protection Board additionally places URL and pixel tracking, local processing, IP-based tracking and unique identifiers within the scope (European Data Protection Board). Whether the GDPR applies on top is decided separately, based on whether personal data is involved.

Consent Maintenance 2026: Banners and Script Drift

The consent banner belongs to the building blocks that get set up once and are then considered done. The shop underneath keeps evolving: every plugin update, every new campaign and every theme release brings scripts that do not appear in the categories of the consent tool. 92 percent (HTTP Archive, Web Almanac 2024) of the pages analysed include at least one third party, and inclusion chains have a median depth of 3.4 levels - scripts load further scripts (HTTP Archive, Web Almanac 2024). This is where script drift comes from: the banner describes the shop of the day before yesterday, while the page load before consent has long been contacting other domains. This article shows how to audit the actual state, which legal framework applies in 2026 and how the readjustment becomes plannable as GDPR updates inside the maintenance contract.

Key takeaways

A consent banner describes the script landscape of the day it was set up. Plugin updates, theme releases, campaign tags and restores add calls that appear in no category; 92 percent of sites embed at least one third party (HTTP Archive, Web Almanac 2024).
Testing happens in a fresh profile with no stored decision, across home, category, product, cart, checkout entry and campaign landing pages: log storage access and contacted domains, then compare them line by line against the consent tool's declared list.
Section 25 TDDDG attaches to storage access rather than to personal data, and requires consent before that access. It also covers localStorage and tracking pixels; the fine ceiling is 300,000 euros (TDDDG, Sec. 28).
A category in the banner states intent, not state. Enforcement happens server-side by not shipping the script at all, and through tag management that blocks by default. A Content Security Policy governs sources, not purposes, and never replaces consent.
Timestamp, purposes, configuration version and the banner text shown must live in a versioned record. Withdrawal has to be as easy as granting: a permanently visible direct link, not an email address, a contact form or a hunt through the privacy policy.
A workable rhythm is a full script inventory every quarter plus a diff before and after every major update. The dialog itself must be keyboard operable, keep focus inside, and present rejection with the same size, colour and contrast as acceptance.

Script drift: what shifts underneath the banner

A consent banner is a snapshot. It knows the purposes, providers and storage accesses that existed in the shop at the time it was configured. German supervisory authorities put it in a sentence that is easily lost in day-to-day maintenance: where a bundled consent is obtained for numerous cases, every change - in particular to the cookies used and the third-party services embedded - means that a new consent has to be obtained for the new case (German Data Protection Conference, guidance for telemedia providers). A configuration that stays untouched for twelve months while the shop is updated three times and redesigned twice therefore describes a state that no longer exists.

The surface this happens on is large. 92 percent (HTTP Archive, Web Almanac 2024) of the pages analysed include at least one third party; the median is 27 distinct third parties per page across the top million sites and 66 across the top thousand (HTTP Archive, Web Almanac 2024). 30.5 percent of all third-party requests are scripts, meaning executable code with access to the page (HTTP Archive, Web Almanac 2024). And because inclusion chains have a median depth of 3.4 levels - with the longest measured chain reaching 2,930 steps - the shop operator is not the only one deciding which domains are contacted in the end (HTTP Archive, Web Almanac 2024).

Extensions with built-in tracking

A review, recommendation or shipping extension often ships its own counting, error or telemetry calls. They appear in no category list because they were installed with the extension rather than embedded separately.

Lazily loaded widgets

Chat, maps, videos, rating stars and fonts fetch their resources at runtime, sometimes only after a user interaction. A quick look at the homepage misses them; a visit to the product or contact page does not.

Chained inclusions

An approved script loads a second one that pulls in a third. The banner category covers the first provider, while the actual connection goes to a domain nobody has ever categorised.

In practice, a handful of predictable events trigger the drift. Knowing them lets you attach the audit to those moments instead of scheduling it by feel:

Plugin or app update: a new version activates a telemetry or recommendation feature that was not there before
Theme release: fonts, icon libraries or animation files are loaded from an external domain after the switch
New campaign: a conversion or retargeting tag is added at short notice, often right before a promotion period
Testing and personalisation: A/B testing tools act before rendering and set their own identifiers to do so
Payment and shipping widgets: calculators, instalment displays or parcel tracking contact their own domains
Rollback or restore: an older state brings back tags that were removed long ago, without anyone noticing

Drift stays invisible as long as nobody checks without consent

Teams test in their own browser - and there the decision has long been stored. The critical state is the very first page load without any decision, and that is exactly the state editors, agencies and shop operators rarely see in routine operations. If you already audit your extensions regularly, this view can be folded into the same pass without much extra effort.

The audit method: the page load before consent

The audit itself is technically unremarkable and therefore easy to standardise. It needs a fresh profile state without a stored decision, a fixed selection of page types and a log that records two things: which storage accesses happen and which outbound connections are established. Everything else is comparison work against the target list of the consent tool.

Create a fresh state: private window or new profile, cleared storage, no existing consent - otherwise you audit your own routine instead of first contact
Page types instead of the homepage: home, category, product detail, cart, checkout entry, contact and at least one campaign landing page
Log storage accesses: cookies, localStorage, sessionStorage, IndexedDB and cache entries with name, setting domain and lifetime
Log outbound connections: every domain contacted with its trigger, including the calls that only originate from an already loaded script
Hold the target list against it: compare the provider and purpose list stored in the consent tool line by line with the log
Document the difference: every deviation with date, trigger and decision - categorise, block or remove

The scope does not end at cookies. In Guidelines 2/2023 on the technical scope of Article 5(3) of the ePrivacy Directive (version 2.0, adopted on 7 October 2024) the European Data Protection Board names three criteria for applicability and analyses five common techniques: URL and pixel tracking, local processing, tracking based on IP only, intermittent and mediated IoT reporting, and unique identifiers (European Data Protection Board). Delivering a tracking pixel already counts as storage there, at the very least through the caching mechanism of the client software - and sending the appended identifier back counts as gaining access (European Data Protection Board). A log that only collects cookie names therefore misses a substantial share of what is happening.

Entry in the consent tool	What the load without consent shows	Consequence
Statistics: one counting method	two counting calls, one of them embedded via an extension	add the purpose and provider, or configure the extension without telemetry
Marketing: one campaign tag	the tag additionally pulls in a profiling domain	document the chain and give the tag a blocked-by-default setting
External media: one embed	additional fonts and icons from external domains	serve the resources locally instead of categorising them
Necessary: session and cart	the cart identifier is set while the visitor is merely browsing	move the moment of setting to the actual interaction
not listed	a chat widget writes to local storage on load	block before consent, release afterwards
not listed	an old tag is active again after a restore	remove it and repeat the diff after every restore

The audit belongs in a log, not in someone's memory

An audit result without a date, page list and version state is a recollection. What belongs on record: the time, the page types checked, the state of shop version, theme and extensions, and the revision of the banner configuration. Only then can you answer later from when an access existed - a question that is far easier to answer with continuous monitoring than with spot checks.

The 2026 legal framework without alarmism

The relevant German provision is short: storing information in the terminal equipment of the end user, or accessing information already stored there, is only permitted if the end user has consented on the basis of clear and comprehensive information (TDDDG, Section 25). Two aspects matter for maintenance. First, the rule attaches to the storage access, not to personal data - it applies even where no personal data flows. Second, it requires consent before the access: setting consent-requiring cookies on the very first page load and only then showing the request is impermissible according to the supervisory authorities' guidance (German Data Protection Conference, guidance for telemedia providers).

Section 25(2) TDDDG provides two exemptions: the mere transmission of a message, and access that is strictly necessary to provide a digital service explicitly requested by the user (TDDDG, Section 25). The authorities read this strictly in technical terms - economic necessity for the business model does not create an exemption - and examine four dimensions: the moment of storage, the content of the information, the storage period and the setting domain (German Data Protection Conference, guidance for telemedia providers). For shops one point follows directly: cart and payment functions are only strictly necessary in temporal terms once an item has actually been added to the cart or the payment process has been initiated, not while a visitor is browsing (German Data Protection Conference, guidance for telemedia providers).

Categories are not a free pass

A label such as "audience measurement" does not carry the classification on its own. The supervisory authorities explicitly note that any statement about consent-free use could only apply to a precisely defined configuration and purpose - and no longer holds as soon as further information about users or an additional analysis result is added (German Data Protection Conference, guidance for telemedia providers). That is precisely what happens whenever an analytics tool gains a feature.

The sanction range is well known but often misread. For a breach of Section 25(1) sentence 1 the law provides for a fine of up to 300,000 euros (TDDDG, Section 28). Where personal data is processed in the process - the norm with identifiers in cookies and IP addresses - the GDPR range is added: up to 20 million euros or 4 percent of worldwide annual turnover (GDPR, Article 83). That is the statutory ceiling, not the expectation for an individual case. For most shops the practical relevance lies in complaints, information requests from the authority and deadlines for remediation - all three cost time during ongoing business.

At the same time the framework is in motion. The digital omnibus procedure is renegotiating where the cookie rules sit; the Council position of June 2026 deleted the intended article on machine-readable consent signals (Council of the European Union). Two things follow for practice: the banner remains a mandatory task for now, and preparing for machine-readable signals remains worthwhile anyway. Anyone keeping clean purposes, a versioned configuration and a reliable inventory today can connect a future signal without rebuilding the foundation. The share of pages using a standardised consent framework rose from 1.9 percent to 4 percent between 2022 and 2024 (HTTP Archive, Web Almanac 2024) - standardisation is growing, but it does not replace your own upkeep.

What this article is - and what it is not

This is not legal advice. Whether a specific access requires consent, which purposes may be combined and how a fine risk should be assessed in an individual case are questions for your legal counsel and the competent supervisory authority. What is covered here is the technical side: which accesses happen before consent, how they become visible, and how to keep the configuration in step with the shop's development.

Technical enforcement instead of trust

A category in the consent tool is first of all a statement of intent. Whether a script really stays silent before consent is decided by what gets delivered. Every category therefore needs an enforcement mechanism - ideally two independent ones, so that a single configuration mistake does not immediately reach the public site.

Do not deliver it server-side

The most effective lever: the markup only contains the script call once the matching decision exists. What is not in the HTML cannot trigger any loading behaviour, regardless of how a front-end tool is configured.

Tag control, blocked by default

Where tags are embedded through a central control layer, the default is "blocked". Every new tag starts blocked and is released only after it has been assigned to a purpose. Drift then becomes a conscious decision.

Content Security Policy as a second control

An allowlist in script-src and connect-src limits which sources may be loaded and contacted at all. An unknown script then fails against the policy rather than passing by chance.

The Content Security Policy is more than a lock: in report-only mode it reports violations without blocking anything. Collecting those reports gives you a drift alarm for free - every new source appearing after an update creates an entry. That is the bridge between security hardening and consent upkeep, because both ask the same question: which sources is this page allowed to contact? The technical setup including nonce handling is described in the article on HTTP security headers and CSP.

Two controls, two purposes

A Content Security Policy is not a consent mechanism: it governs sources, not purposes, and it knows nothing about a user's decision. Conversely, a consent tool does not replace a policy, because it only controls the scripts it knows about. Only together do they cover the case that occurs most often in maintenance: a script nobody added on purpose.

A tag that is disabled in the tool but present in the source code is a tag that loads. The difference between configuration and delivery is the difference between intention and state.

From project experience in shop operations

Evidence: records, retention and the withdrawal path

Anyone relying on consent must be able to demonstrate it (GDPR, Article 7). The supervisory authorities make clear that this does not require long-lived cookies with a unique identifier: as a rule it is enough to be able to set out which processes were implemented to obtain consent and to store the result without excessive information (German Data Protection Conference, guidance for telemedia providers). Evidence is therefore less a database question than a question of disciplined documentation.

Time and scope: when the decision was made and which purposes it covers
Configuration version: which revision of the provider and purpose list applied at that moment
Text revision: which information was visible in the banner, so that "informed" stays verifiable
Retention period: how long the record is kept and when it is deleted
Renewal: when a decision expires and which change triggers obtaining it again
Withdrawal as an event: withdrawal belongs in the same history as the approval, with a timestamp

Withdrawal is where many banners get sloppy. It must be as easy as giving consent (GDPR, Article 7(3)). The supervisory authorities are explicit: pointing to email, fax or a contact form is not sufficient, and the detour via the privacy policy followed by a search is an impermissible obstacle; a permanently visible direct link or an icon leading straight to the settings is the expected route (German Data Protection Conference, guidance for telemedia providers). Likewise, refusal must be recognisable as an equivalent alternative - comparable in size, colour, contrast and typography (German Data Protection Conference, guidance for telemedia providers).

The banner configuration is a versioned artefact

Provider list, purposes, texts and blocking rules belong in the same version control as the rest of the code - with date, author and reason for the change. You can then show which revision applied on any given date, and the diff after an update is a text difference instead of a feat of memory. Without that history the question "since when has this been loading?" stays unanswerable.

The routine: inventory, diff and cleanup

Consent upkeep rarely fails on knowledge and often on cadence. Two rhythms have proven themselves: a complete script inventory every quarter and a diff after every major update. The first catches gradual change, the second immediately attributes each deviation to a trigger - and that is the difference between a ten-minute root cause analysis and a two-hour one.

Quarterly: full inventory

Load all page types without consent, log storage accesses and connections, compare against the target list and file the result with a date. With a well-kept estate the effort stays modest, because only the difference creates work.

After every update: diff

The same check on a reference page before and after deployment. New domains, new storage entries and changed lifetimes stand out immediately - while the change is still fresh and attributable.

Continuously: alert on unknown sources

Reports from the Content Security Policy and from tag control feed into the same alerting as other operational events. An unknown script source becomes an incident with a recipient rather than a chance discovery.

Cleanup pays off twice. At the median a mobile page ships 558 KB of JavaScript, of which 375 KB come from third parties versus 168 KB first-party (HTTP Archive, Web Almanac 2024). 206 KB or 44 percent of the delivered bytes go unused during page load (HTTP Archive, Web Almanac 2024). Every tag removed therefore shrinks both the upkeep list in the banner and the load time - something that is on the list in performance maintenance anyway. The decision order is robust: remove it if unused; serve it locally if only one resource is needed; categorise and block it if the purpose remains.

Drift is not limited to the banner

The same movement affects every embedded external system: they fail, change interfaces or disappear. How a shop guards against third-party outages and how payment APIs with deprecations and webhooks are maintained belong in the same routine as the script inventory - it is the same question about foreign code inside your own operation.

The banner is a control element

A consent dialog is the first interactive element a visitor reaches - and frequently the least tested one. That is delicate, because it blocks the entire page while it is open. The error picture on the web is well documented: 95.9 percent (WebAIM Million 2026) of the home pages analysed had detectable WCAG 2 A/AA failures, with an average of 56.1 errors per page, and 83.9 percent of pages contained low-contrast text (WebAIM Million 2026). Both error types hit banners particularly often, because secondary buttons tend to be styled in light grey.

Fully keyboard operable: every button and switch reachable, in a sensible order, without a mouse
Focus visible and contained: clearly recognisable focus ring, focus stays inside the dialog and returns to the trigger on close
Refusal designed as an equal: comparable in size, colour, contrast and typography to the consent option (German Data Protection Conference, guidance for telemedia providers)
Contrast verified: text and controls meet the minimum ratios, including in dark mode and on coloured surfaces
Not colour alone: active and inactive switches also distinguishable by label or icon
Usable on small displays: the dialog must not permanently obscure content or render it inaccessible (German Data Protection Conference, guidance for telemedia providers)
Announced to screen readers: dialog role, labelling and switch states are exposed correctly

Since June 2025 the topic has had an additional legal edge for many shops: the German accessibility act covers electronic commerce, and the consent dialog is part of the ordering path. What that means for maintenance and evidence is set out in the article on shop accessibility under the EAA; the technical implementation runs in the same workflow as the other maintenance services.

Consent upkeep as a fixed deliverable

Each of the steps described is unremarkable on its own, and they still fail regularly - because they sit between marketing, development and operations and are not firmly assigned to anyone. As part of a maintenance contract they get a date, a responsible role and a result document. With us they run as GDPR updates with three fixed components:

Quarterly script inventory

A complete list of storage accesses and contacted domains across all relevant page types, mapped to purpose, trigger and the extension responsible.

Audit log before consent

A documented page load without any decision, compared against the target list of the consent tool, plus a dated difference list that evidences the state on that day.

Readjustment with sign-off

Add categories, adjust blocking rules, remove unused tags, update texts and the withdrawal path - each with sign-off and an entry in the version history.

That moves the consent question from one-off setup to ongoing upkeep - which is where it belongs, because the shop keeps changing. For Shopware installations the workflow is part of Shopware maintenance, for content systems part of WordPress maintenance; dates, response times and responsibilities are governed by the SLA maintenance contract. If you deploy security updates on the same cadence, both questions get answered in one pass: what the shop loads, and whether it is up to date while doing so.

Sources and studies

This article is based on data from: the German Telecommunications Digital Services Data Protection Act (TDDDG, Sections 25 and 28), the German Data Protection Conference (guidance for telemedia providers, version 1.1), the European Data Protection Board (Guidelines 2/2023 on the technical scope of Article 5(3) of the ePrivacy Directive, version 2.0 of 7 October 2024), the Council of the European Union (position on the digital omnibus package, June 2026), the General Data Protection Regulation (Articles 7 and 83), HTTP Archive (Web Almanac 2024, chapters on third parties, JavaScript and privacy), WebAIM (WebAIM Million 2026) and our own project experience in shop operations.