Consent Logging vs Cookie Banner — What's the Difference?
Ask most founders if they're GDPR compliant, and the answer is usually "yeah, we have a cookie banner." It's an understandable assumption — the banner is the visible, front-facing part of consent, so it's easy to mistake it for the whole requirement. In reality, a cookie banner and a consent log do two completely different jobs, and having one says nothing about whether you have the other.
This confusion is one of the most common gaps in small SaaS products with EU users, and it's usually invisible until someone — an auditor, a data subject request, or an enterprise customer's security review — asks a question the banner alone can't answer.
A Cookie Banner Is an Interface
A cookie banner (or any consent prompt — signup checkboxes, marketing opt-ins) is the mechanism through which you ask for consent. Its job is to:
- Inform the user what you're asking permission for
- Present clear, unbundled choices (analytics vs. marketing vs. essential cookies)
- Capture the user's immediate response
That's it. Once the user clicks "Accept" or "Decline," the banner's job is done. It doesn't retain a record of what happened. If you check your database right after a user interacts with your banner, in most implementations there's nothing durable stored beyond, at best, a single cookie in the user's browser noting their local preference.
A Consent Log Is a Record
A consent log is a separate system whose only job is to answer, at any point in the future: did this specific user consent to this specific purpose, when, and under what terms?
A proper consent log entry includes:
Who — a user or session identifier
What — the specific purpose (analytics, marketing, third-party sharing — logged separately, not bundled)
When — a precise timestamp
Under what terms — which version of your privacy policy or consent copy was live
Evidence — some record of what was actually shown to the user at that moment
This is backend infrastructure, not UI. A user never sees it. It exists purely so that you can answer the question later, whether that's six days or two years after the fact.
Why Having a Banner Doesn't Mean You Have a Log
Here's the gap that catches most teams: they build a nice-looking cookie banner with a consent management library, and it correctly shows unbundled choices and respects the user's selection in-session. But under the hood, the only thing persisted is a browser cookie storing local preference — nothing durable on the server tied to that specific user, timestamped, versioned, and exportable.
That means if a user clears their cookies, switches devices, or a regulator asks "prove this user consented to analytics on March 3rd," there's no answer. The banner did its job perfectly at the moment of interaction. It just never handed that moment off to a permanent record.
This is precisely the gap GDPR Article 7(1) is written to close: the accountability burden is on the controller to demonstrate consent was given, not just to have asked for it nicely.
Why You Need Both, Not One or the Other
A banner without a log means you're asking correctly but can't prove anything afterward. You have a good UI and zero audit trail behind it.
A log without a banner isn't really possible in the first place — you can't log consent you never actually captured through some interface. But it's worth noting: a badly designed banner (bundled choices, pre-checked boxes, consent implied by scrolling) produces invalid consent, and logging an invalid consent event just gives you a well-documented record of non-compliance. The banner has to be correct and the logging has to happen.
They're sequential, not interchangeable: the banner captures the decision, the log preserves it.
What This Looks Like in Practice
A working system does both, connected:
- User is shown unbundled, clearly worded consent choices (the banner's job)
- User makes a decision for each purpose
- That decision is immediately written to a persistent, append-only log — who, what, when, policy version, evidence of what was shown (the log's job)
- If the user later changes their mind, that's a new log entry, not an edit to the old one
If you're auditing your own setup, the fastest way to check which half you actually have is simple: pick any user, and try to answer "when did they consent to marketing emails, and what did the form say at that time?" If your cookie banner tool can't answer that with a specific timestamped record — only a currently-set browser preference — you have the interface but not the proof.
Closing the Gap
Most teams already have the banner half solved reasonably well — consent management libraries for cookie banners are common and mostly get the UX right. The log half is where solo founders and small teams tend to fall short, because it's invisible infrastructure with no immediate user-facing payoff, right up until the day it's the only thing standing between you and an unanswerable audit request.
If you're building the logging layer yourself, the core of it is straightforward: a purpose-scoped, append-only event table with a timestamp, policy version, and some snapshot of what was presented. If you'd rather not build and maintain that piece separately from your banner, ConsentKeep exists specifically to be the log half of this equation — proof-of-consent recording with screenshot evidence, IP hashing, and instant export, so the banner you already have finally has a record behind it.