How to design a cookie banner that produces valid consent

The cookie banner is the first thing a visitor sees on your site, and usually its least considered part. It is taken from a template, recoloured and forgotten. Yet it has two jobs: to obtain valid consent, and to hold back every consent-based cookie until that consent arrives. A banner that does neither is decoration, however polished it looks.

This article is about the banner itself: what belongs on the first layer, where the reject button goes, pre-ticked boxes, the second layer, consent records, withdrawal and re-asking. How to write a cookie policy is a separate article.

The rules come from the Turkish authority's Cookie Guidance (KVKK), the text of the GDPR, and the consent guidance of the EDPB and the ICO. All three point the same way: consent has to be active, granular, recorded and revocable.

What the banner does, and what it does not

A site has three separate pieces that deal with cookies. The privacy notice explains who processes personal data and for what purpose. The cookie policy lists the cookies on the site with their name, purpose, lifetime and whether they are first or third party. The banner only collects consent and applies the choice.

The KVKK guidance does not consider it appropriate to merge the privacy notice and the consent request into one text; a link from the banner to the privacy notice and the cookie policy is enough. The category names on the banner must match the categories in the policy.

No consent-based cookie may load before consent

This is the most common mistake and the least noticed. While the banner sits on screen, the analytics and advertising scripts have already run in the background. The KVKK guidance, the ICO and the EDPB say the same thing: cookies that are not strictly necessary may only be set after valid consent has been obtained.

Strictly necessary cookies, described in the KVKK guidance under Criteria A and B, need no consent: the session cookie, the basket, security, login state and the cookie that remembers the visitor's consent choice itself. As a rule, every other cookie waits for the banner's decision. In most setups analytics cookies are in that group too. The ICO adds that no advertising purpose can ever count as strictly necessary.

To achieve this you first need to know which cookies and third-party services actually run on your site. Scanning your site to see which cookies drop before consent is the first step, before the banner is designed.

What belongs on the first layer

The first layer is the panel the visitor sees on landing. The good-practice example in the KVKK guidance contains: a short statement that cookies process personal data, the purposes consent is requested for, a link to the privacy notice, and "accept", "reject" and "preferences" buttons of equal weight in colour, size and font.

Information can be layered. But the EDPB warns that if the controller's identity and the purposes are not visible on the first layer, or if it is not clearly indicated where the second layer is, demonstrating informed consent becomes difficult.

Why the reject button belongs on the first layer

For consent to count as freely given, refusing has to be as easy as accepting. The KVKK guidance shows a panel without equally presented "accept all", "reject all" and "preferences" buttons as a bad example. The ICO likewise expects the reject option without extra clicks, as prominent as accept and on the same layer.

In practice this means a large, brightly coloured "accept" next to a small grey "settings" link is not a valid design.

Pre-ticked boxes and passive use

Consent requires an active, affirmative act. The KVKK guidance states plainly that entering a site is not consent to its cookies, and that allowing cookies by way of using the site is not lawful. The EDPB goes further: scrolling or swiping through a page, or similar activity, will under no circumstances satisfy the requirement of a clear affirmative action.

Pre-ticked boxes are invalid for the same reason. Recital 32 of the GDPR does not treat silence, pre-ticked boxes or inactivity as consent, and the EDPB guidance settles it in one sentence: the use of pre-ticked opt-in boxes is invalid under the GDPR. The KVKK guidance likewise requires an opt-in rather than an opt-out system.

The cookie wall, blocking access to content until consent is given, is a separate trap. According to the KVKK guidance such a setup may impair the data subject's free will and the consent obtained may be invalid; according to the EDPB, access to a service must not be made conditional on cookie consent.

The second layer: choice by category

The "preferences" button takes the visitor to the second layer. This is where consent is collected separately per purpose. The EDPB guidance calls this granularity: asking for one consent covering several purposes makes the consent invalid. Analytics, functional and marketing cookies have to be offered as separate toggles, each switched off by default.

According to the KVKK guidance, for consent to be specific each category has to state the purpose of the cookie, a lifetime proportionate to that purpose, and whether it is first or third party. On the second layer that means at least one sentence of explanation per category and a list of vendors. The vendor list has to match the list in the cookie policy.

Consent records: what to store

Article 7 of the GDPR requires the controller to be able to demonstrate that consent was given. The checklist in the KVKK guidance has the same item: cookie consent records are to be kept for an appropriate period.

A reasonable record contains: when the choice was made, which categories were accepted or rejected, which banner and policy version the visitor saw, and an identifier tying the choice to the visitor's browser. The EDPB also reminds that the duty to demonstrate consent should not lead to excessive additional processing. How the record is kept is described on thehow it works page.

Withdrawing consent has to be as easy as giving it

Under Article 7 of the GDPR the data subject may withdraw consent at any time, and it has to be as easy to withdraw as to give. The KVKK guidance likewise treats it as good practice to keep the consent management panel permanently reachable as an icon or a small strip in a corner of the page that does not block content.

According to the ICO, when consent is withdrawn the technologies concerned must stop being used, processing must cease, and any third parties the consent was passed to must be told. When the choice changes, the banner must not only update the record but also stop the scripts concerned.

When consent has to be asked for again

Neither the GDPR nor the UK's PECR sets a fixed period for how long consent lasts; the EDPB recommends refreshing consent at appropriate intervals as good practice. The ICO gives six months as a suitable timeframe before asking a visitor who declined again.

Regardless of the period, consent has to be requested again when purposes or vendors change; the old consent does not cover the new purpose. The most reliable way to notice a new analytics tool on your site is to scan it at regular intervals. Thefeatures page shows how that monitoring works.

Five common mistakes

• Running consent-based scripts while the banner is still waiting for an answer.
• Hiding the reject button on the second layer or showing it fainter than accept.
• The sentence "by continuing to use this site you accept cookies". Passive use is not consent.
• Presenting the categories on the preference panel pre-ticked.
• Not recording the click. Consent you cannot demonstrate is, in the EDPB's words, below the GDPR standard.

Checklist

• Which cookies drop on the site before the visitor has made a choice? Only strictly necessary ones?
• Does the first layer list the purposes and link to the privacy notice?
• Are "accept", "reject" and "preferences" on the same layer, the same size and equally prominent?
• Are consent-based categories switched off by default on the second layer?
• Does each category state purpose, lifetime and vendors, matching the cookie policy?
• Is every choice recorded with a timestamp and version information?
• Can the visitor change their choice later with one click? Do the scripts concerned stop when they do?
• Is consent requested again when a purpose or vendor changes?

The first and last items on this list are the hardest to track by hand. DILAYS scans your site, shows the cookies and third-party services that fire before consent, builds the banner from that inventory and records every choice. The legal standards for the banner do not change; DILAYS ties those standards to the scan result.