Cookie consent is where first-time builders either over-engineer or ignore the rules: a giant banner on an app that sets only a login cookie, or three analytics scripts and a pixel with no banner at all. This guide explains when you need a cookie consent banner, when you do not, and what a banner has to do to produce valid consent, based on the legal text and regulators' published positions.
This is general information, not legal advice. Cookie rules are national law, so details vary by country.
Where cookie consent rules come from
The core rule is not in the GDPR. It is Article 5(3) of the ePrivacy Directive (2002/58/EC), which requires member states to ensure that "the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent, having been provided with clear and comprehensive information".
Three things follow from that wording.
It is about the device, not about cookies. Any storage or reading of information on the user's device is covered. The UK regulator, the ICO, notes that the rule "actually applies to anyone who stores information on a user's device or gains access to information on a user's device, in either case by any method." In a web app that includes local storage, session storage and tracking pixels as well as cookies.
It applies whether or not the data is personal. Norway's data protection authority, Datatilsynet, says of the Norwegian provision that it applies "uavhengig av om det er snakk om personopplysninger eller ikke", that is, regardless of whether personal data is involved.
The consent standard comes from the GDPR. The European Data Protection Board's Cookie Banner Taskforce, which coordinated regulators' handling of cookie banner complaints, recalled that GDPR concepts such as the conditions for valid consent are "indispensable" when assessing the ePrivacy rules. Norway made this explicit in its new Electronic Communications Act, in force from 1 January 2025: Datatilsynet's page states that consent must meet the requirements of the GDPR.
When you need cookie consent, and when you do not
Article 5(3) has two exemptions. Consent is not required for storage or access "for the sole purpose of carrying out the transmission of a communication over an electronic communications network", or that is "strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service."
The second exemption is the one that matters for apps, and the word doing the work is "strictly". The ICO puts the test this way: "cookies that are helpful or convenient but not essential, or that are only essential for your own purposes, will still require consent."
Here is how common items in a small web app usually sort out:
| What it does | Consent needed? | Why |
|---|---|---|
| Keeps a signed-in user signed in | Usually not | Needed to provide the service the user asked for |
| Remembers items in a basket through checkout | Usually not | Given by the ICO as an example of an exempt cookie |
| Load balancing | Usually not | Also given by the ICO as an example |
| Security for a service the user requested | Usually not | ICO example: session cookies providing security for online banking |
| Remembers a user's chosen setting for the service | Often not | The taskforce recalled that cookies retaining preferences the user expressed regarding a service should be deemed essential |
| Product analytics | Yes | Serves your purposes, not the user's request |
| Advertising, retargeting and conversion pixels | Yes | Not necessary to provide the service |
If your app only sets an authentication session and maybe a preference, you may not need a consent banner at all. You still have to tell people what you store. The ICO's basic rule is that you must "tell people the cookies are there" and "explain what the cookies are doing and why", which a clear cookie notice does. Our cookie page is one example.
Do not stretch the exemption. The taskforce report specifically flags controllers who classify as essential "cookies and processing operations which use personal data and serve purposes which would not be considered as 'strictly necessary'".
Legitimate interests is not an alternative either. The taskforce confirmed that "the legal basis for the placement/reading of cookies pursuant to Article 5 (3) cannot be the legitimate interests of the controller."
What a valid cookie banner must do
If you do use non-essential cookies or similar technologies, the banner has to produce consent that meets the GDPR definition in Article 4(11): "freely given, specific, informed and unambiguous", given "by a statement or by a clear affirmative action". Regulators have spelled out what that means for banners.
Nothing non-essential runs before consent
The taskforce recalled that "by default, no cookies which require consent can be set without a consent". The ICO says you "cannot set non-essential cookies on your website's homepage before the user has consented to them." In practice: the analytics script is not loaded until the user accepts.
Rejecting must be as easy as accepting
On banners that offer an accept button but no way to refuse on any layer that has one, the taskforce found that "a vast majority of authorities" considered this an infringement. Datatilsynet's Norwegian guidance says it must be "like lett å si nei som å si ja", as easy to say no as to say yes. The safe design is an Accept button and a Reject button side by side on the first layer.
No pre-ticked boxes
Recital 32 of the GDPR says: "Silence, pre-ticked boxes or inactivity should not therefore constitute consent." The taskforce applied this directly to the toggles on the second layer of cookie banners. Every optional category starts switched off.
No hidden or disguised reject option
The taskforce listed, as not leading to valid consent, a reject option offered only as a link "embedded in a paragraph of text" without "sufficient visual support" to draw attention to it. It also identified as potentially manifestly misleading a reject button whose text contrast is "so minimal that the text is unreadable to virtually any user." Style both buttons so a person can see both choices.
Scrolling is not consent
The EDPB's consent guidelines state that "actions such as scrolling or swiping through a webpage or similar user activity will not under any circumstances satisfy the requirement of a clear and affirmative action". The ICO likewise says consent "must be more than simply continuing to use the website."
No cookie walls
The same guidelines say that "access to services and functionalities must not be made conditional on the consent of a user" to storing or reading information on their device, describing these as "so called cookie walls". If a user rejects, the app should keep working.
Separate purposes, separate choices
The EDPB says that when processing serves several purposes, the solution "lies in granularity, i.e. the separation of these purposes and obtaining consent for each purpose." Analytics and advertising should be separate choices, each described plainly with the provider named.
Withdrawal is easy and always available
Article 7(3) of the GDPR requires that "It shall be as easy to withdraw as to give consent." The taskforce said website owners should provide "easily accessible solutions allowing users to withdraw their consent at any time", such as a small permanently visible icon or "a link placed on a visible and standardized place". A footer link that reopens the same choices does the job.
You can prove what was agreed
Article 7(1) requires the controller to be able to demonstrate consent. The EDPB suggests keeping a record that shows how and when consent was obtained and what information was given at the time. For a small app, store the choices, a timestamp and the notice version shown.
Implementation notes for your app
- Gate the scripts, not just the banner. A banner is useless if the analytics tag is hard-coded in the page head. Load optional scripts only after the matching choice is saved.
- Default to off. Until the user chooses, behave as if they rejected.
- Re-ask when things change. The EDPB notes that if processing operations "change or evolve considerably then the original consent is no longer valid." Adding a new advertising tool is a reason to ask again.
- Test in a clean browser profile. Load the app, do nothing, and check the storage panel and network tab; then reject and check again. Nothing optional should appear.
- Keep the notice in sync. Your cookie notice and your privacy policy should list the same tools the app actually loads.
Can you avoid the banner entirely?
Often, yes. If you can run the product without non-essential cookies or device storage, you avoid the consent question for them. The ICO's guidance also points out that where you are not using data to provide a service to the user, "for example, if you are simply counting visitors to a website", it may be possible to use anonymous data instead. Whether a given tool qualifies depends on what it stores or reads on the device, so check its documentation against Article 5(3).
Cookie consent is one part of the broader picture covered in our guide to GDPR for web apps.
Sources
- Directive 2002/58/EC (ePrivacy Directive), consolidated text, EUR-Lex
- Regulation (EU) 2016/679 (General Data Protection Regulation), EUR-Lex
- Report of the work undertaken by the Cookie Banner Taskforce, European Data Protection Board
- Report of the work undertaken by the Cookie Banner Taskforce (PDF), European Data Protection Board
- Guidelines 05/2020 on consent under Regulation 2016/679, European Data Protection Board
- Guidelines 05/2020 on consent (PDF), European Data Protection Board
- Cookies and similar technologies, ICO
- Bruk av informasjonskapsler (cookies), Datatilsynet
