UK GDPR for pharmacy websites: health data is special category data

Why pharmacy website data is special category data

UK GDPR divides personal data into two tiers, and health data sits in the protected one: Article 9 defines special category data to include data concerning health, alongside categories such as ethnicity and sexual orientation, and prohibits processing it unless a specific condition applies on top of an ordinary lawful basis. The reasoning is proportional to the harm: a leaked email address is a nuisance, while a leaked record that an identifiable person sought treatment for erectile dysfunction, weight management or an STI is a disclosure that can damage relationships, employment and dignity, which is why the law demands more than ordinary care.

The consequence is a mindset shift this article will keep returning to: a pharmacy website is a clinical data environment with a shopfront attached, not a shop with some sensitive products, and every design decision, from analytics tags to form storage to the marketing stack, has to survive that classification.

Lawful basis, twice over: Article 6 plus Article 9

Processing special category data lawfully requires two documented decisions rather than one. First, an Article 6 lawful basis, as for any personal data: for a pharmacy delivering a service a patient has requested, this is typically contract, with legal obligation covering the record-keeping duties pharmacy law imposes and legitimate interests available for limited operational purposes. Second, an Article 9 condition permitting the special category processing: for the clinical journey itself, the natural fit is Article 9(2)(h), processing necessary for the provision of health care, read with the Data Protection Act 2018's health and social care condition, which is available precisely because a registered pharmacy's processing happens under the responsibility of professionals subject to a duty of confidentiality. Explicit consent, Article 9(2)(a), is the condition for processing that goes beyond delivering care, health-related marketing being the clean example, and it must be specific, informed, unbundled from the service and as easy to withdraw as to give.

Two disciplines make this real rather than theoretical. The bases and conditions are written down per processing activity in the record of processing your DSPT documentation already requires, questionnaire handling, order fulfilment, marketing, analytics, each with its pairing. And the privacy notice on the website says the same thing in plain language: what is collected, why, under what basis, who it is shared with, how long it is kept and what rights the person has, positioned where patients will actually encounter it, not buried three clicks deep.

Cookies and consent: the rules being enforced right now

Cookies sit under PECR, the Privacy and Electronic Communications Regulations, alongside UK GDPR, and the operative rules are short: strictly necessary cookies, those genuinely required to deliver the service the visitor asked for, such as the basket and login session, need no consent; everything else, analytics, advertising, social media embeds, personalisation, requires informed, freely given consent before the cookie is set. Consent by scrolling, pre-ticked boxes and banners whose reject route takes three clicks against accept's one do not meet the standard, and the ICO has said so while acting on it: its programme of writing to the operators of the UK's most-visited websites reached its next 1,000 sites in 2025, with public statements that most of the earlier cohort changed their practices and that enforcement continues.

For a pharmacy the banner mechanics are table stakes; the real question is what the cookies are attached to, which is the next section. But get the mechanics right first: reject as easy as accept, non-essential tags firing only after consent, a cookie policy that lists what actually runs, and periodic re-checks, because marketing plugins have a habit of adding tags nobody consented to reviewing, let alone setting.

Trackers on health pages: where analytics becomes disclosure

The most consequential design decision on a pharmacy website is which third parties can see which journeys. An advertising pixel on a condition-specific page does not just count a visit; it transmits to the ad platform that an identifiable or re-identifiable person viewed, added to basket or purchased a treatment that reveals their health, and at that point the pharmacy is disclosing special category data to a third party, with all the Article 9 machinery that entails and, realistically, no condition that covers it. This is not a hypothetical reading: regulators on both sides of the Atlantic have acted against health websites over advertising trackers, and the ICO's audit work on period, fertility and health apps has repeatedly flagged exactly this pattern, consent and transparency failures around tracking technologies in health contexts.

The defensible architecture is a split. General pages, home, about, delivery information, blog content, can run consented analytics like any retailer. Health journeys, condition pages tied to identifiable users, questionnaires, consultation flows, baskets and order confirmation for treatment purchases, run clean: no advertising pixels, no social embeds, no third-party tags beyond what the service strictly needs, with analytics either excluded or configured so nothing identifying and nothing condition-revealing leaves your control. This costs some marketing attribution, and the honest position is to accept that cost as the price of the category you trade in; the pharmacies that would not accept it are well represented in our analysis of why pharmacy websites fail.

Forms, accounts and retention: the data you deliberately hold

Beyond the tracking layer sits the data the website collects on purpose, and three principles govern it. Minimisation: a consultation questionnaire asks what the prescriber's decision requires and nothing else, a contact form asks for a name and a way to reply, and every additional field is a liability collecting itself. Security in transit and at rest: HTTPS everywhere without exception, health data flowing directly into the clinical system that will process it rather than resting in web-form inboxes, email accounts or plugin databases, and hosting arrangements that keep data in the UK or a jurisdiction with adequacy, documented so you can answer the where-is-it question. Retention with an end: clinical records keep to pharmacy record-keeping requirements, but marketing signups, abandoned baskets, chat transcripts and server logs each need their own shorter clock, written into the retention schedule and actually executed, because "we keep everything forever" is both a GDPR breach and a growing attack surface.

Patient accounts deserve one specific mention: an account that displays order history is displaying health data, so it belongs behind proper authentication, with password standards, session expiry and, as it becomes available, multi-factor authentication, the same control the DSPT now asks about for clinical systems.

Breaches and the 72-hour clock

A personal data breach is any incident of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data, which on a website includes the unglamorous cases: a misconfigured plugin exposing form submissions, an order confirmation emailed to the wrong address, a compromised admin account, a marketing list sent with recipients in CC. Where a breach is likely to result in a risk to individuals, it must be reported to the ICO within 72 hours of the pharmacy becoming aware; where the likely risk is high, a bar health data reaches quickly, the affected individuals must also be told without undue delay, in clear language, with advice on protecting themselves. Every breach, notifiable or not, goes in the internal breach record with the assessment and reasoning.

The operational requirement hiding in the deadline is detection and rehearsal: 72 hours is generous for a pharmacy that logs access, monitors its website and has an incident SOP with a named owner, and impossible for one that learns about the breach from a patient's complaint three weeks later. Website incidents belong in the same incident process as dispensing errors, feeding the same learning loop, which is also precisely what the DSPT declaration says your pharmacy does.

DPOs, registration and who owns all this

Three accountability anchors close the framework. ICO registration: every pharmacy processing personal data must be registered and paying the annual data protection fee, and non-registration is a criminal offence, not an oversight. The DPO question: a Data Protection Officer is mandatory where core activities involve large-scale processing of special category data, a threshold a substantial online pharmacy can meet, and many pharmacies appoint one, or a named data protection lead where the formal test is not met, because the duties exist either way and unowned duties lapse. The governance seam: none of this is separate from pharmacy regulation, since the GPhC's online pharmacy standards expect secure handling of user details as part of safe distance services, and the same evidence, records of processing, access controls, incident logs, serves both regulators. Data protection on a pharmacy website is not an IT annex to the compliance file; it is a chapter of it, with a name at the top.

The ten-point website audit

Run this against your live site quarterly, alongside the display-requirements check the GPhC guidance demands; each row is a pass or a task.

Key takeaways

FAQs