Cookies in a web application serve a different purpose from those on a marketing website. Rather than supporting advertising or basic analytics, application cookies typically manage authentication sessions, hold user preferences, maintain form state and support integrations with third-party services. This distinction matters because it changes which cookies require consent and how the consent mechanism fits into the application's architecture.

Decision summary: Classify every cookie, SDK and storage technology by purpose, record the exception or consent route, and test withdrawal before launch.

The current PECR position is purpose-specific: storing or accessing information on a user’s device requires consent unless a defined exception applies. Strictly necessary technologies remain one important exception, and the 2025 reforms added limited exceptions for certain other purposes. The team must classify each technology honestly and document why consent or an exception applies.

The Data (Use and Access) Act 2025 changed PECR and introduced additional exceptions for some low-intrusion storage and access technologies. That does not create a blanket exemption. The team must classify each cookie, SDK, local-storage item or comparable technology by purpose, assess whether an exception applies and obtain valid consent where it does not. Personalised advertising and comparable tracking still require particularly careful consent design.

The consent service must also respect withdrawal, avoid setting non-exempt technologies before a valid choice, preserve evidence and keep the user interface as easy to reject as it is to accept where consent is relied upon.

Essential versus non-essential in an application context

In a web application, essential cookies generally include:

  • Session identifiers that keep a user logged in as they move between screens
  • Security tokens that prevent cross-site request forgery
  • Load-balancing cookies that route requests to the correct server
  • Preference cookies that remember a user's choice of language or accessibility settings, where the application cannot function without applying a default

Non-essential cookies typically cover analytics, error monitoring, feature-flagging services, third-party embedded content and any tracking that extends beyond the immediate session. If the application would still operate without the cookie—even with a degraded experience—it is not essential.

Recording consent is itself a form of data processing. The application must store evidence of what the user consented to, when they consented, which version of the cookie policy was presented and how they indicated their choice. This record needs to be retrievable if a regulator or data subject requests it. For a multi-tenant SaaS product, the question of who holds these records—the platform operator or each tenant—should be addressed in the contract and data-processing agreement rather than left ambiguous.

The consent mechanism should appear before any non-essential scripts execute. In practice, this means the application's front-end code must hold back loading analytics tags, third-party widgets or tracking pixels until the user has made a choice. A common architectural approach is to use a tag-management layer or a consent-state variable that scripts check before initialising.

The interface itself needs to offer genuine choice. Presenting a single "Accept" button alongside a barely visible "Manage options" link does not meet the standard for specific consent. Users should be able to accept all, reject all non-essential cookies, or select individual categories.

Handling authenticated users

Web applications introduce a complication that marketing sites do not: logged-in users. When a user authenticates, the application already knows who they are, which raises the question of whether consent can be assumed from a previous session or a general terms acceptance.

It cannot. Consent for cookies is separate from consent to terms of service. A user who agreed to terms last month has not necessarily consented to a new analytics provider added this week. The application should check the user's current consent record each time they log in and re-prompt if the cookie categories have changed or if the record is missing or outdated.

Integrations and third-party scripts

Business systems frequently embed third-party components: payment processors, chat widgets, document viewers, mapping services or CRM tracking pixels. Each of these may set its own cookies. The application owner remains responsible for ensuring consent is obtained before those cookies are placed, regardless of whether the script is hosted externally.

When specifying integrations, ask the supplier which cookies their service sets, what each one does and whether they offer a consent-aware initialisation mode. Some third-party services provide a delayed-load option that only activates once the parent application signals that consent has been granted.

Consent must be as easy to withdraw as it was to give. In a web application, this usually means providing a persistent consent-management link in the navigation or account settings—not just a banner that disappears and cannot be found again. When a user withdraws consent for a category, the application should immediately stop setting those cookies and, where technically feasible, delete the existing ones. It does not need to retroactively delete historical analytics data, but the forward-looking change must take effect without requiring a page reload or re-authentication.

Pre-ticked boxes and default-on settings

Pre-ticked consent boxes do not constitute valid consent. The user must take a positive action. Some applications circumvent this by making the "Accept all" button large and colourful while burying the reject option, but regulators have made clear that the design must not nudge users towards consent. Check that every non-essential category defaults to off.

Blocking access to the entire application unless the user accepts non-essential cookies is problematic. If the application is a public-facing service, refusing entry unless tracking is accepted may not count as freely given consent. Essential-functionality gates—such as requiring authentication—are separate from cookie-consent gates and should not be conflated.

This is the most frequent technical failure. The application's HTML includes a third-party script tag in the header, the browser executes it immediately, and cookies are set before the user sees the consent banner. Audit the application's page load sequence: every script that is not essential should be gated behind the consent state. Automated scanning tools can detect cookies set before the consent interaction, and these are the checks regulators look for.

Ignoring subdomains and embedded content

If the application runs across multiple subdomains—such as app.example.co.uk and docs.example.co.uk—consent collected on one may not automatically apply to the other unless the consent mechanism and cookie scope are designed to cover the full domain. Similarly, if the application embeds content from another domain via an iframe, that embedded page may set its own cookies independently. Map every domain and subdomain the application touches and verify that consent covers the full footprint.

When a new integration is added or an analytics provider is replaced, the set of non-essential cookies changes. Existing consent records may no longer cover the current configuration. The application should version its cookie categories and re-prompt users whose consent record predates the current version.

Questions to put to a development supplier

  • How does the application prevent non-essential scripts from executing before consent is collected?
  • Where is the consent record stored, who owns it and how long is it retained?
  • Does the system version cookie categories and re-prompt when they change?
  • How is consent withdrawal handled for authenticated users across sessions?
  • Can you demonstrate a test that proves no non-essential cookies are set before interaction?
  • How are third-party embedded components managed within the consent flow?

Cookie consent in a web application is not a one-time compliance checkbox. It is an ongoing architectural consideration that affects how scripts are loaded, how user sessions are managed and how integrations are controlled. Treat it as a functional requirement with the same rigour applied to authentication or data migration, and review it whenever the application's technology stack or third-party dependencies change.

Checks before relying on the system

  • Document the precise processing scenario and who is authorised to approve exceptions.
  • Design a workable complaints, rights-request and evidence process rather than relying on a privacy notice alone.
  • Confirm the organisation’s role for each processing activity rather than labelling every supplier a processor.
  • Record the purpose, lawful basis, data categories, recipients, retention rule and international-transfer position.

Primary guidance checked for this edition

Sources for “How to Handle Cookie Consent in a Web Application” were checked on 22 July 2026. Recheck the applicable rules, product documentation and contractual terms before implementation because these can change after the review date.