How it works today in most organizations
The cookie banner arrived with the website relaunch. The agency installed a WordPress plugin or embedded a free banner tool, kept the default texts and adjusted the buttons to the corporate design. Alongside, someone in marketing started a list, "Cookie_List_Website.xlsx", with the name, provider, lifetime and purpose of every cookie. The data protection officer turned that list into the cookie section of the privacy notice, by hand, in the website's content management system.
Since then the website has moved on and the documentation has not. Marketing added a pixel for a campaign, sales added a chat widget, HR embeds YouTube videos on the careers page. Each of these changes made sense on its own. None was reported to data protection. The typical sentence goes: "It's just a small script, the agency put it in."
This produces three versions of the truth that do not match: what actually runs on the website, what the banner asks for and what the privacy notice says. The Excel list has not been opened since the relaunch. Nobody in the organization knows for sure whether the plugin blocks a cookie until consent or merely lists it. And which consents visitors actually gave sits, if anywhere, in a database table of the plugin that nobody can evaluate.
Ask around and you get different answers. Marketing points to the agency, the agency to the plugin's default settings, the data protection officer to the privacy notice. The shared drive still holds "Cookie_List_Website_old.xlsx" and a screenshot of the banner from go-live.
The moment it becomes apparent
It becomes apparent when someone outside asks a specific question. A visitor complains to the supervisory authority that an analytics cookie was set even though it had been rejected. A business customer sends a questionnaire as part of a supplier review and wants to know how consent on the website is documented. Or the agency is replaced, and with it goes the knowledge of which script was added for what.
At that point it is not enough to point at the banner. For cookies that are not strictly necessary, Section 25 of the German TDDDG (called TTDSG until May 2024) requires consent, and that consent has to meet the requirements of the GDPR. Under Art. 7(1) GDPR, the controller must be able to demonstrate that consent was given. So the question is not "Do you have a banner?" but: which version was live on that day, which services did it list, and what did this person choose?
Neither the plugin nor the Excel list can answer that. Banner, list and privacy notice know nothing about each other, and none of them keeps earlier versions.
The analysis
Five Gaps Between Website, Banner and Documentation
They do not come from carelessness. They arise because banner, cookie list and privacy notice are maintained in three places by three different people.
View preeco | data protectionNo proof of consent
Art. 7(1) GDPR requires the controller to be able to demonstrate consent. If decisions sit only in a plugin table without version or export, all that remains after a complaint is the claim that the banner worked.
Services data protection does not know about
Pixels, chat widgets and videos reach the website through marketing or the agency. What data protection does not know about appears neither in the banner nor in the privacy notice, and may load before any consent.
Blocking is never checked
A banner that only lists cookies does not stop them from being set. Whether a script really waits for consent is something nobody checks day to day, until a complaint shows otherwise.
The cookie list goes stale
The Excel list reflects the state of the relaunch. Lifetimes, providers and third-country transfers change without anyone opening the list again, and the gap grows with every campaign.
Privacy notice updated by hand
The cookie section is typed into the content management system. It matches the banner only until one of the two changes, and then the website contradicts itself.
The target process in six steps
1. Set up the banner where the documentation lives. In preeco | data protection the cookie banner sits in the "Websites" menu next to the privacy notices, alongside processing activities and data processing systems. An administrator creates one per website: name, up to three domains, home page for the scan and the banner's languages. The privacy notice for the same domain is suggested for linking. The banner is a paid add-on, with tariffs by monthly page views.
2. Scan what the website really sets. The first scan starts with the order. After the release it runs on the first of every month, or by hand when needed. Cookies found are assigned to the services whose scripts set them. Whatever is left appears under "Unassigned cookies".
3. Take services from the template library. For common services such as Google Analytics or YouTube, the team picks a template library entry, which brings provider, purpose and documented cookies. Anything else becomes an in-house service. Every service belongs to one of the categories Required, Preferences, Statistics or Marketing and can be linked to its processing activity and data processing system.
4. Define design and integration. Layout and colors are set once, texts per language, with a live preview. "Reject all" and "Accept all" sit side by side as equals on the first level. IT adds one script to the head of every page, marks scripts that need consent with their category and has embedded videos and maps show a placeholder until consent. The next scan checks the integration.
5. Release and version. Release requires links to the privacy notice and legal notice and a purpose for every service in every language. Each release creates a version; after significant changes, all visitors can be asked for consent again. The "Cookie Policy" chapter of the privacy notice takes over the most recently released version.
6. Prove consent. Every decision is stored with time, version and choice, the IP address truncated. The records can be filtered by period, version, decision and domain and exported as CSV.
How the team works together
Marketing no longer has to report a new service; the next scan shows the new cookie. The data protection officer checks assignment, category and purpose and links the service to the processing activity. Open points go to IT as a task with a due date. Then someone with release rights releases the new version. The versions show why a service has been in the banner since March.
Before and after in direct comparison
| Criterion | Before | After |
|---|---|---|
| Maintenance effort | Cookie list and privacy notice updated by hand | Services maintained once, the cookie policy follows the release |
| Currency | State of the last relaunch | Monthly scan, new cookies reported as unassigned |
| Completeness | Only what marketing reports | What the scan finds, plus cookies from the template library |
| Evidence | Decisions in a plugin table, no export | Consent records with version and choice, CSV export |
| Versions | Earlier states are lost | Every release creates a version |
| Collaboration | Calls between marketing, agency and data protection | Tasks, release and links to processing activities |
| Answers to authorities and customers | Screenshots of the banner | Version, cookie policy and consent records for the period |
| Continuity risk | Knowledge sits with the agency | Services, purposes and history live in the system |
In practice
What this looks like in preeco | data protection
The three building blocks that carry the process described above.
Scan and template library
The scan finds the cookies on your website and assigns them to the services whose scripts set them. Services come from the template library with their documented cookies or are created in-house.
Release and consent records
Every release creates a version that each consent record refers to. The records can be filtered and exported as CSV, and the "Cookie Policy" chapter follows the latest release.
Processing activities and systems
Every service in the banner can be linked to the processing activity and the data processing system that document it. That is how the website and your records of processing activities stay connected.
What the switch means in practice
The switch does not start with an empty banner but with a scan. It shows what the website actually sets today, and usually also how far the Excel list has drifted from reality. The cookies found are assigned to services, the purposes completed in every language, and then comes the first release. Only after that is the old plugin removed, so the website is never without a banner.
Most of the work is about content: which services does the website really need, which category does the chat widget belong to, and who decides in future whether a new script gets added? Settle that before the first release, not afterwards.
Three mistakes that make the switch unnecessarily hard
Leaving the old plugin running in parallel. Two banners on one page ask twice and block unreliably. Remove the old tool in the same change that adds the new script.
Adding the script but marking nothing. The banner reliably blocks only what is marked as requiring consent. Scripts and embedded content without that marking keep loading as before; the review of the integration after the next scan shows where that is still the case.
Keeping the privacy notice maintained by hand. If the old cookie section stays, you are back to two versions. Replace it with the "Cookie Policy" chapter and release the privacy notice again after every release of the banner.
How to tell it is time
A plugin is not wrong in itself. It is time to switch when one of these points applies:
- Nobody in the organization can say whether your banner blocks cookies until consent or only lists them.
- The cookie list is older than the last marketing campaign.
- New services reach the website through the agency or marketing without data protection hearing about it.
- You could not show which version of the banner was live on a given day.
- Customers or auditors ask how consent on your website is documented.
FAQ
Frequently asked questions about cookie banners and consent
Yes. Section 25 TDDDG requires consent for access to the end device that is not strictly necessary, and that consent follows the GDPR. Under Art. 7(1) GDPR, the controller must be able to demonstrate that consent was given. In practice this means the time, the banner version and the visitor's choice must be verifiable.
Cookies that are strictly necessary to provide a service the user has explicitly requested, for example for the shopping cart, the login or storing the cookie decision itself (Section 25(2) no. 2 TDDDG). In the banner they belong to the Required category, which cannot be deselected. Statistics and marketing services generally need consent.
There is no fixed statutory period; proof must be possible for as long as you rely on the consent and may face questions about it. In preeco | data protection, consent records are kept for twelve months after the decision, or 36 months for a surcharge. If a consent remains valid for longer, retention extends until it expires.
The cookie banner is a paid add-on to preeco | data protection and is booked per banner. The tariff depends on the website's monthly page views, and one banner covers up to three domains. If the quota is exceeded, the banner keeps running and stores every consent; if it stays above the quota, the tariff is adjusted after advance notice. We will give you the current terms in a consultation.
In terms of content, yes, because the cookie policy must match the services in the banner. In preeco | data protection, the chapter with the master data type "Cookie Policy" automatically takes over the most recently released version of the banner. It appears in the published privacy notice with the notice's next release; the banner's overview shows whether both are on the same version.
Review your website together
Bring your current cookie list. In 30 minutes we show how scan, release and consent records work together in preeco | data protection.