Not always. A UK healthcare website needs consent before using cookies or similar technologies for purposes that are not covered by a PECR exception. Essential booking or security functions may operate without consent, and some tightly limited analytics may now qualify for a statistical purposes exception. Advertising pixels, profiling and cross-service tracking still require valid consent before they run.
The practical question is therefore not simply whether the site has cookies. Clinics need to know every technology the website stores on, or reads from, a visitor's device, why it is used and whether that purpose meets an exception. The Information Commissioner's Office finalised new Storage and Access Technologies guidance on 29 April 2026, reflecting changes introduced by the Data (Use and Access) Act 2025.
This article is practical website and marketing guidance, not legal advice. Healthcare providers should obtain advice for their particular systems, suppliers and processing activities.
The 2026 guidance changes the decision, not the need to audit
PECR regulation 6 applies to technologies that store information on, or access information stored on, a person's device. This is wider than browser cookies. It can include tracking pixels, scripts and tags, local storage, link decoration, device fingerprinting and technologies used inside mobile apps or connected devices.
The 2025 Act added exceptions beyond the long-established communication and strictly necessary exceptions. The ICO's final guidance explains narrow exceptions for statistical purposes, appearance preferences and emergency assistance. Statistical analytics can sometimes operate without consent, but only if the sole purpose is to create aggregate information about how a service is used so that the service or website can be improved.
That is not a general permission for all analytics. The clinic must give clear and comprehensive information and a simple, free way to object. It must not use the data to identify, monitor, profile or target people. If the same technology also supports advertising or visitor-level decisions, the exception does not fit and consent is required.
Audit technologies by purpose, not by supplier label
Start with evidence from the live website. Review source code, tag-manager containers, network requests, browser storage and every embedded supplier. Include the main site, booking system, contact forms, payment pages, chat tools, video embeds, maps, patient portals and campaign landing pages. Test before and after each consent choice on desktop and mobile.
Do not assume a product is exempt because its supplier describes it as “cookieless”, “privacy-first” or “essential”. PECR focuses on storage or access and purpose. A script can access device information without setting a traditional cookie. Server-side processing may reduce browser activity, but it does not make remaining device access exempt.
Record each technology, provider, information accessed, purpose, duration, recipient, legal assessment and the behaviour before consent. If one tool serves several purposes, separate them technically where possible. A necessary booking session should not become a route for an advertising pixel to start early.
A purpose-by-purpose cookie decision table
| Website purpose | Possible PECR position | Practical action |
|---|---|---|
| Load balancing, fraud prevention or an essential booking session | May meet the communication or strictly necessary exception | Document why the requested service cannot work without it and explain the technology clearly |
| Remembering an accessibility or display preference | May meet the appearance exception | Use it only for the requested preference, provide clear information and a simple, free objection route |
| Aggregate page and journey statistics used only to improve the site | May meet the statistical purposes exception | Avoid visitor identification and profiling, aggregate promptly, explain the use and offer a simple, free objection |
| Session replay or visitor-level behaviour monitoring | Normally requires consent unless genuinely limited to another specific exception | Keep it off before consent and assess whether the intrusion is proportionate at all |
| Advertising conversion tags, retargeting or audience building | Requires consent | Block before consent, separate the marketing choice and check every campaign landing page |
| Third-party maps, videos, chat or booking widgets | Depends on every purpose within the embed | Audit supplier activity, use privacy-preserving modes where available and gate non-exempt functions |
Exceptions are purpose-specific and narrow. A technology that qualifies for aggregate service-improvement statistics cannot quietly feed advertising measurement as well. When the purpose changes, the consent or exception assessment must change with it.
Healthcare websites need a wider data-protection view
PECR and the UK GDPR sit alongside each other. If a storage or access technology also processes personal data, the website must meet UK GDPR requirements as well. Health information is special category data, so a clinic should take particular care with pages, forms and event names that can reveal a condition, treatment interest or appointment type.
Avoid sending form contents, free-text symptoms, treatment names or patient identifiers into routine marketing platforms. A conversion event called “form submitted” may reveal less than one labelled with a sensitive treatment. Data minimisation applies to tracking design, not just to the privacy notice.
Third-party tools remain the clinic's responsibility to understand. Review contracts, controller and processor roles, international transfers, retention and supplier access. A consent-management platform can help capture choices, but installing one does not fix tags that fire too early or information that is too vague.
A valid consent journey must work in practice
Where consent is required, obtain it before the non-exempt technology operates. Explain purposes in plain language, provide granular choices and make rejection as usable as acceptance. Do not rely on pre-ticked boxes, inactivity or a design that hides the alternative.
Test the published website rather than trusting a dashboard setting. Open a clean browser session, reject optional purposes and confirm that advertising, profiling and other non-exempt requests remain blocked. Then change the choice and verify that only the selected purposes start. Provide an obvious route to withdraw consent later.
The banner should not obstruct urgent contact details, accessibility controls or essential patient information. On mobile, check that the choice buttons and explanation fit without trapping keyboard or screen-reader users. Clear privacy choices are part of a trustworthy patient experience, not an overlay to add at the end.
Use the least intrusive analytics that answers the business question
A clinic rarely needs a detailed profile of every visitor to learn whether service pages are useful. Aggregate visits, page journeys, device categories, loading performance and broad referral sources may be enough to improve navigation and content. The ICO says the statistical purposes exception can cover aggregate measures such as page visits, average scroll depth, loading speed and broad regional information when its conditions are met.
It does not cover advertising attribution, linking a visitor identifier to a conversion, demographic profiling or cross-service monitoring. If the clinic wants those capabilities, use consent and assess whether the data is genuinely necessary. A platform's default configuration is not automatically the correct one.
For clinics commissioning a redesign, privacy choices should be settled alongside forms, booking flows and measurement, not after launch. Kay & Co.'s SEO-first healthcare website design service connects patient-friendly content, search foundations and proportionate measurement from the start.
A practical healthcare website cookie checklist
- Map the whole estate. Include subdomains, booking and payment suppliers, campaign pages, embeds, portals and mobile experiences.
- Observe the live behaviour. Test device storage and network activity before any choice, after rejection and after each consent category.
- Write down every purpose. Do not group essential delivery, statistics, personalisation and advertising under one vague analytics label.
- Assess each exception. Record the specific conditions and why the purpose fits. If it does not fit, obtain consent before use.
- Minimise health-related signals. Remove treatment details, form contents and identifiers from routine analytics and advertising events.
- Control third parties. Check roles, contracts, retention, transfers, default settings and what the supplier does with the information.
- Make choices usable. Keep accept and reject routes clear, granular and accessible, with an easy way to change a decision.
- Retest after change. New plugins, tags, campaigns and booking features can alter the assessment, so review regularly and after every release.
The most useful output is a living technology register linked to release checks. It gives the clinic, developer and marketing team one source of truth and makes it easier to spot when an innocent-looking campaign addition changes the privacy position.
A banner is not the objective. The objective is a website that uses only proportionate technology, gives people meaningful control and still supplies enough evidence to improve the patient journey.
Frequently asked questions
No. A healthcare website does not need consent for storage or access technologies that meet a specific PECR exception. Strictly necessary functions may qualify, and narrow statistical or appearance purposes may qualify if their conditions are met. If the site uses advertising tags, profiling, cross-service tracking or another non-exempt purpose, it needs valid consent before those technologies operate.
Potentially, but only within the narrow statistical purposes exception. The sole purpose must be aggregate statistics used to improve the service or website, not identifying, profiling or targeting visitors. The clinic must provide clear information and a simple, free way to object, minimise individual-level data and meet UK GDPR duties where personal data is involved.
No. A session or security technology that is essential to provide the booking service requested by the user may meet the strictly necessary exception. Analytics, advertising, profiling or convenience features bundled into the same booking tool do not automatically qualify. Assess every purpose and prevent non-exempt technologies from operating before consent.
