Cookie Consent for Healthcare Websites UK: What PECR and UK GDPR Require in 2026

Usually, you need consent when your website stores or accesses information on a user's device for a purpose that does not fall within a PECR exception. However, not every technology requires consent.

The ICO's 2026 guidance identifies 5 exceptions:

These exceptions are purpose-specific. If the actual use of a technology goes beyond the relevant exception, consent may be required.

For healthcare organisations, the practical question is therefore not simply, "Does this website use cookies?" It is, "What does each technology do, why is it used, what information does it access, and does an exception apply?"

A technology can fall within the strictly necessary exception when its purpose is essential to provide a service requested by the user.

Examples can include functionality required to maintain an essential session, support requested website functionality, or provide necessary security.

However, convenience does not automatically mean necessity. A technology that improves marketing measurement, audience profiling, personalisation, or advertising performance should not be classified as strictly necessary simply because the organisation finds it useful.

During healthcare implementations, this distinction often becomes important when development teams inherit scripts from previous websites. A technology may have started as an essential function but later gained additional analytics or marketing purposes.

The purpose of the actual implementation should therefore be documented rather than relying on the technology's product name or its original reason for installation.

The Data (Use and Access) Act 2025 introduced changes to PECR, including new exceptions covering certain statistical purposes, appearance or functionality preferences, and emergency assistance. The ICO finalised its updated Storage and Access Technologies guidance on 29 April 2026.

The ICO also reported that 99% of the UK's top 1,000 websites met its cookie-banner compliance standards following focused work with industry.

That figure is not a healthcare compliance rate, but it provides useful context. Cookie consent has become an established implementation concern for organisations operating substantial public-facing websites.

Healthcare websites can contain pages, journeys, and services that reveal more context about a visitor than a general commercial website.

Consider:

The presence of these pages does not automatically mean every visitor's activity is special category data. The assessment depends on what information is collected, whether it relates to an identifiable person, what the organisation intends to infer or do with it, and how the information is used.

The 2026 ICO guidance uses the broader concept of storage and access technologies rather than focusing only on browser cookies. PECR can apply where technology stores information on a user's device or accesses information already stored there.

For healthcare organisations, that means your audit should start with actual technical behaviour rather than the cookie list shown in your website policy.

The ICO identifies several technologies that can fall within the rules, including:

A website can therefore create tracking exposure without relying on a conventional cookie.

For example, a marketing script loaded through a tag manager can create storage or access activity even when the development team does not describe it internally as a "cookie".

Where consent is required, non-exempt storage and access technologies should not activate before the user has provided valid consent.

The ICO states that consent must involve clear positive action and that organisations must not use non-exempt technologies before consent has been obtained.

A common implementation failure occurs when the consent banner loads correctly but the underlying tags fire earlier in the page lifecycle.

For development teams, the correct test is therefore technical. Open the website with no previous consent, inspect storage and network activity, reject optional categories, then verify that the relevant technologies remain inactive.

PECR and UK GDPR operate together, but they answer different legal questions.

Where PECR requires consent for a storage or access technology, you cannot simply replace that PECR consent requirement with legitimate interests under UK GDPR. The ICO explicitly confirms this position.

Legitimate interests may still be relevant to separate processing where PECR does not require consent, but it should not be used as a workaround for a PECR consent requirement.

A compliant consent mechanism should give users meaningful control over non-exempt technologies.

The ICO expects organisations to provide:

A banner that says "By continuing to browse, you agree" does not provide the same control as a mechanism that allows users to actively accept, reject, or customise non-exempt technologies.

The answer changed significantly with the 2026 PECR framework.

The statistical purposes exception can allow certain analytics activity without consent where the technology is used solely to collect statistical information about how a service or website is used, with the purpose of improving it. The exception is narrower than simply saying "analytics cookies are exempt".

The ICO explains that the exception focuses on aggregate statistical information about visitors and service use.

To rely on it, organisations need to consider requirements including:

The exception is not intended for identifying, tracking, monitoring, or profiling individual visitors.

Where individual-level information is collected temporarily for aggregation, it should not be retained longer than necessary for that aggregation process.

The ICO gives examples such as:

The technical configuration matters. An analytics platform may offer hundreds of settings, but only some may align with the statistical purposes exception.

A healthcare organisation should therefore assess its actual configuration rather than assuming that an analytics product is automatically exempt.

The exception does not cover analytics used to identify, track, or profile individual visitors.

Examples include:

Once the purpose extends beyond the narrow statistical purpose, the organisation needs to reassess the PECR position and whether consent is required.

Healthcare analytics creates a different risk profile because the subject matter of the page itself can be sensitive.

For example, an organisation may want to understand which pages receive the most visits. That is different from creating identifiable profiles of people who repeatedly visit pages about a particular condition.

The first activity may potentially fit the statistical purposes exception when correctly configured. The second requires a much more detailed privacy and data protection assessment.

For a broader assessment, see our UK GDPR Article 9 requirements for health data, particularly where tracking could intentionally infer health information.

The most important healthcare distinction is context.

A cookie is not automatically health data simply because it exists on a healthcare website. However, the information generated by tracking can become more sensitive when it is linked with an identifiable person, health-related activity, or intentional inference.

Website addresses can sometimes contain meaningful information about the subject of a visitor's activity.

A URL structure referencing a specific treatment, condition, clinic, or service could therefore become relevant to a privacy assessment if tracking tools transmit that information elsewhere.

Avoid placing unnecessary health information in URLs, event names, campaign parameters, or analytics dimensions.

Search behaviour can create a similar issue.

A visitor searching for information about a particular health condition does not automatically mean that every resulting technical record is special category data. The assessment becomes more significant where identifiable information is linked with health-related searches or the organisation intentionally uses the activity to infer health status.

Healthcare teams should therefore assess what search terms are captured, where they are sent, and whether the data is identifiable.

Booking journeys can contain more context than a standard website visit.

For example, a booking category, clinic type, treatment pathway, or service selection may reveal information about the reason someone is seeking healthcare.

The safest implementation approach is to avoid sending unnecessary booking details to general analytics systems. Track aggregate completion behaviour where possible instead of transmitting clinical or patient-specific information.

Form tracking deserves particular scrutiny.

Do not send symptoms, diagnoses, treatment names, free-text responses, patient identifiers, or other sensitive values into general analytics platforms merely to measure form performance.

Instead, define events around the technical action. For example, an organisation may need to know that a form was successfully submitted without sending the contents of that form to an analytics provider.

Advertising technologies require particular caution on healthcare websites.

Retargeting based on visits to health-related content can create significant privacy concerns, especially when tracking connects identifiable information with health-related interests or behaviours.

The ICO confirms that online advertising purposes are not covered by the statistical purposes exception and require consent where PECR applies.

For organisations serving US audiences as well, a separate review of HIPAA tracking pixels and healthcare analytics may also be relevant. The UK PECR assessment should remain separate from any HIPAA assessment.

Not every visit to a healthcare page automatically constitutes processing of special category data.

The UK GDPR assessment depends on the information involved, its relationship to an identifiable individual, the purpose of processing, and whether health information is revealed or intentionally inferred. The ICO recognises that intentionally creating inferences about health status can constitute processing special category data.

NHS guidance also highlights the confidentiality concern that can arise when identifiable information, such as an IP address, is linked with searches for information about a specific health condition.

The practical lesson is straightforward. Do not assess cookies in isolation from the information and context produced by the website.

A cookie banner is only one part of the implementation. Its job is to communicate choices and capture consent, while the underlying website must enforce those choices technically.

Use categories that reflect the actual technologies deployed.

Common categories may include:

Avoid creating categories that hide several unrelated purposes under a vague label such as "functional".

Where consent is required, users should be able to refuse optional technologies without navigating through unnecessary screens.

The acceptance and rejection journey should be straightforward and understandable.

Different purposes require meaningful choices.

The ICO expects consent mechanisms to provide granular options for different purposes rather than bundling unrelated processing into one decision.

Continuing to browse does not constitute valid consent.

Neither does a pre-selected option that the visitor must actively disable.

Consent should involve a clear positive action after the user receives appropriate information.

Consent management should not end after the initial banner.

Provide an obvious method for users to revisit their choices and withdraw consent. The withdrawal process should be as easy as the original consent process.

Healthcare websites should also consider the accessibility of the consent mechanism itself.

Check:

A technically compliant consent model can still create accessibility problems if users cannot understand or operate it.

Users should receive clear information about the technologies being used, their purposes, relevant third parties, and applicable duration information.

The ICO's guidance specifically addresses transparency around storage and access technologies and the information organisations should provide.

Cookie Consent Management Platforms can be useful implementation tools, but selecting a platform does not complete the compliance assessment.

Depending on the platform and configuration, a CMP can support:

The important word is configuration. A CMP can enforce a policy that has been correctly designed, but it cannot independently determine whether the organisation's data processing is appropriate.

A CMP cannot determine:

Those decisions require organisational and technical assessment.

A consent platform can be installed correctly while individual scripts remain incorrectly configured.

For example, a tag manager may load before the CMP has established a user's preferences. A third-party video, chat tool, map, or social plugin may also introduce storage or access technologies outside the original consent design.

The ICO notes that organisations need to understand changes to technologies, third parties, and purposes because existing consent may not cover a new purpose.

Ask your implementation team:

The right CMP is therefore the one that supports your architecture and governance model, rather than simply the platform with the longest feature list.

A proper audit should examine what the website actually does, not only what its cookie policy says.

Include more than the homepage.

Review:

Healthcare organisations often have several digital properties that were introduced by different teams at different times.

Test the site under different consent states.

At minimum:

This is where development and information governance teams need to work together. A policy review cannot identify every premature network request.

Record each relevant technology with fields such as:

The register should reflect the live implementation rather than an old vendor inventory.

Review integrations such as:

Each third party should be assessed according to what the implementation actually sends.

Look specifically for:

One useful control is to create a prohibited analytics data list. Development teams can then use it during implementation and testing rather than discovering sensitive event parameters after launch.

A cookie audit can become outdated quickly.

Retest after:

A new script can change the site's PECR position even when the cookie banner itself has not changed.

Use this checklist before launch or after a significant tracking change.

Where the assessment identifies personal data, the organisation should also consider its wider UK GDPR data protection compliance obligations rather than treating PECR as a standalone exercise.

Cookie consent should be treated as an ongoing governance responsibility rather than a one-time banner installation.

Review the setup when you introduce:

Across recent compliance projects, the highest-risk tracking changes are often introduced outside the original website build. Marketing teams add campaigns, developers add scripts, and third-party services change their implementation.

A practical governance model therefore gives Information Governance, marketing, development, and digital teams a shared process for approving tracking changes.

Qrolic Health treats tracking as part of the website's data architecture rather than simply a marketing configuration.

Our work with healthcare platforms and healthcare-sector organisations involves considering how website functionality, forms, third-party integrations, analytics, authentication, and data flows interact.

For example, healthcare platforms such as Herexa Health involve patient-facing workflows and sensitive healthcare boundaries. Experiences across healthcare projects including IPPF and RxHere also reinforce the importance of understanding how information moves between website components and external services.

The implementation principle is simple: map the technology first, identify what information moves through it, assess the regulatory position, then configure the website to enforce the required controls.

Cookie consent for healthcare websites UK is no longer a question of placing a banner above the homepage and adding a cookie policy.

The 2026 PECR framework requires organisations to understand storage and access technologies, identify applicable exceptions, obtain consent where required, and give users meaningful control. Healthcare organisations also need to consider how tracking interacts with patient journeys, health-related content, identifiable information, UK GDPR, and Article 9 where applicable.

The strongest implementation approach connects governance with technical architecture. Your organisation should know which technologies run, what information they access, where information is sent, why each technology is used, and what happens when a visitor rejects optional tracking.

That approach reduces the risk of discovering tracking problems after a website launch, campaign deployment, or analytics migration.