What security must a pharmacy actually have?
Three obligations operate together, and a pharmacy treating website security as a discretionary technical matter has usually noticed only the third.
The UK GDPR requires appropriate technical and organisational measures to protect personal data, assessed against the risk, and pharmacy data is special category health data at the highest end of that scale. The NHS Terms of Service require an annual information governance declaration through the Data Security and Protection Toolkit, which is contractual rather than advisory. And the GPhC standards require that risks associated with providing pharmacy services are identified and managed, which our analysis of inspection outcomes identifies as among the most commonly failed standards.
None of the three mentions websites specifically. All three cover them, because a website which collects health information, processes payments and connects to a dispensing system is a place where pharmacy data lives.
Which DSPT category is a community pharmacy?
Community pharmacies fall within Category 3, covering community providers alongside domiciliary care providers and residential care homes. The distinction matters more than it appears, because Category 1 organisations have been required since 2024/25 to complete their submission using the Cyber Assessment Framework, which is a materially heavier, outcome-based standard.
Version 8 of the Toolkit, released in September 2025, was aligned with the National Cyber Security Centre's Cyber Assessment Framework, described as the most significant change since the Toolkit launched in 2018. The direction of travel is therefore toward evidence that controls actually operate rather than that policies exist, and a pharmacy relying upon a document asserting that all staff complete annual training should expect the question to become whether records demonstrate that they did.
Community Pharmacy England worked with the NHS Toolkit team specifically to keep the pharmacy workload proportionate, which is why Category 3 completion remains manageable. It is not a reason to assume it will remain unchanged.
What changed in the DSPT for 2026?
The 2026 submission fell due on 30 June 2026, which has passed. A pharmacy which has not submitted is in breach of a contractual requirement under the Terms of Service rather than merely behind on administration, and that should be the first item addressed by anyone reading this having missed it.
The changes themselves were characterised as a small number of targeted updates intended to make completion clearer and quicker, the most notable being a new question concerning multi-factor authentication. That single question is the thread connecting this article's two halves, since a pharmacy answering it accurately must know whether multi-factor authentication is enforced across its systems, and its website administration is one of those systems.
Two practical points assist completion. Owners with three or more pharmacies were advised to verify that the premises linked to their NHS Parent Organisation Code are accurate before using batch submission, since an inaccurate list produces delays. And organisations which have kept the sector GDPR workbook templates current can satisfy the criteria for around half the Toolkit questions, which makes maintaining those documents through the year considerably cheaper than reconstructing them each June.
Why does the declaration cover your website?
The Toolkit is not a questionnaire about the dispensary. It is an annual declaration about the pharmacy's handling of data, made under the NHS Terms of Service, and its assertions concerning access control, authentication, staff leavers, incident response and supplier arrangements are expressed at the level of the organisation rather than at the level of a particular room. A pharmacy which asserted that access is removed promptly when staff leave, whilst a former dispenser retains a working login to the website's admin panel, has made an assertion which is not true. A pharmacy which answered the new multi-factor authentication question affirmatively, whilst its website administration is protected by a shared password known to the agency which built it three years ago, has done the same. This is the reframing that matters. Website security is not an optional refinement recommended by a developer with an interest in selling it. It is one of the things the pharmacy has already put its name to, in a contractual declaration, in June. The practical consequence is that the baseline below is not a wish list. It is the set of arrangements which make the declaration accurate.
What is the website security baseline?
| Control | What good looks like |
|---|---|
| Encryption in transit | HTTPS across the entire site with no mixed content, certificates renewing automatically, and no page collecting data over plain HTTP |
| Authentication | Individual named accounts with multi-factor authentication on every administrative login, and no shared credentials of any kind |
| Least privilege | Each account holds the minimum role required, with administrator rights held by as few people as the work permits |
| Patching | Platform, plugins and dependencies updated on a defined cadence, with a named owner and a record of what was applied |
| Backups | Automated, stored separately from the live environment, and periodically restored to verify that they work |
| Logging | Administrative actions and access recorded and retained long enough to investigate an incident discovered weeks later |
| Data minimisation | Forms collect only what is needed, retention is defined per form, and nothing sensitive is stored which the service does not require |
| Supplier control | Written arrangements with anyone holding access, covering security obligations, breach notification and removal of access at the end of the engagement |
None of these is exotic and most map onto the widely recognised baseline controls covering firewalls, secure configuration, update management, access control and malware protection. The reason to state them in a pharmacy context is that the consequences differ, since a compromised retail site loses orders whilst a compromised pharmacy site loses health records.
Should card details ever touch your website?
No, and this is the single most valuable architectural decision available. Card data should be captured directly by the payment provider through hosted fields or a hosted page, such that it never reaches the pharmacy's own servers.
Two benefits follow. The pharmacy remains within the lightest compliance category for card security, which our payments criteria guide sets out, and it removes an entire category of breach, since data never held cannot be stolen.
Two practices should accordingly be refused outright. Accepting card numbers into the pharmacy's own forms, however convenient the integration appears. And recording card details anywhere within order notes, patient records or email, which happens more often than the sector admits, usually because a member of staff was solving a real problem at a counter and nobody had told them not to.
Where do pharmacy websites actually leak data?
Rarely through sophisticated attack. Five ordinary arrangements account for most of it.
The general contact form carrying health information. A patient describes a symptom in a message which routes to a shared inbox and a marketing platform, neither of which was designed to hold special category data, upon no identified lawful basis and with no retention period.
Consultation answers travelling by email. Where a form emails its contents rather than writing to a controlled system, the health data now exists in every mailbox that message reached, indefinitely.
Analytics and marketing tags on clinical pages. A third-party script on a page whose URL reveals the condition being treated transmits that association outward, which is a disclosure rather than a measurement.
Attachments and uploads left publicly reachable. Patient-supplied photographs or documents stored at predictable, unauthenticated addresses, which is a configuration failure rather than a breach of anything clever.
Staging and backup copies. A test version of the site containing real patient data, left online without authentication because it was only meant to exist for a fortnight, which is among the most common findings in any website security review.
Who has access, and who left?
Access control is where the declaration and reality most often diverge, and the audit takes an hour.
List every account with administrative access to the website, the hosting, the domain registrar, the DNS, the analytics and the payment dashboard. For each, establish whether the person still works with the pharmacy, whether the access level is still required, and whether multi-factor authentication is enforced. Remove what is not needed, which will be more than expected.
Two categories deserve particular attention. Former agencies frequently retain administrative access years after an engagement ended, sometimes through accounts registered in an individual developer's name at a company which no longer exists. And shared accounts defeat the entire control, since an account used by several people cannot be attributed, cannot be removed when one of them leaves, and cannot honestly be described as protected by multi-factor authentication.
The ownership clause our agency brief requires exists partly for this reason, since a pharmacy which does not hold the top-level accounts cannot conduct this audit at all.
What happens in the first 72 hours of a breach?
The obligation is well known and the timing is routinely misunderstood, since the seventy-two hours run from becoming aware of the breach rather than from completing the investigation.
The sequence is contain, assess, notify, inform, record. Contain by revoking access, taking affected components offline and preserving evidence rather than tidying it away. Assess whether the breach is likely to result in a risk to individuals' rights and freedoms, which for health data is a low threshold to cross. Notify the Information Commissioner's Office within seventy-two hours where that risk exists, submitting what is known and supplementing later rather than delaying to be complete. Inform affected individuals without undue delay where the risk is high. And record every breach internally, including those not reported, since the record is itself a requirement and its absence is a separate finding.
Two pharmacy-specific points complete the position. The superintendent should be involved from the outset, since a data breach involving clinical records is a patient safety matter as well as a regulatory one. And the incident should feed the same review process as dispensing incidents rather than sitting in a separate technical file that nobody reads.
Are those GDPR complaint emails real?
Some are not, and the sector body has warned about them specifically, which makes this worth knowing before one arrives.
The fraudulent messages share recognisable characteristics, comprising urgent deadlines, threats of enforcement action, and origination from non-official email addresses. Some purport to come from investigative bodies. Others purport to come from patients or members of the public alleging that personal data was submitted online or mishandled, in circumstances where the sender had no genuine prior interaction with the pharmacy at all.
The correct response is neither to panic nor to ignore. Verify the sender through published contact details rather than those in the message, check whether the alleged interaction actually occurred against the pharmacy's own records, and never make a payment or disclose information in response to pressure. Genuine information governance enquiries from real patients do arrive and deserve a proper answer, which is precisely why a pharmacy needs to be able to tell the difference rather than adopting a blanket posture toward either.
What should you ask your web developer?
Seven questions, and the answers double as evidence for next year's Toolkit.
Who currently holds administrative access to the site, hosting, domain and DNS, and can we see the list? Is multi-factor authentication enforced on every one of those accounts? What is the patching cadence for the platform and its plugins, and who owns it? Where are backups stored, and when was a restore last tested? Which third-party scripts run on pages that reveal a health condition? Where does data from each form actually go, and how long is it kept? And what is your breach notification commitment to us, in hours, in writing?
This site's publisher builds pharmacy websites, which is disclosed here as it is throughout this library. These seven questions should be put to this publisher on identical terms, and a developer who treats them as an insult rather than as a specification has answered the more useful question first.
Key takeaways
- Three obligations cover pharmacy website security, comprising the UK GDPR, the NHS Terms of Service through the Toolkit, and the GPhC requirement to identify and manage service risks.
- Community pharmacies are Category 3 for Toolkit purposes rather than facing the Cyber Assessment Framework applied to Category 1 since 2024/25, though version 8 has moved the Toolkit toward outcome-based evidence.
- The 2026 submission was due 30 June and is a contractual requirement, with the notable change being a new multi-factor authentication question which reaches website administration.
- The declaration already covers the website, so a former employee retaining an admin login or a shared password held by a past agency makes an assertion already submitted untrue.
- Card data should never reach the pharmacy's servers, which keeps the lightest compliance category and removes a class of breach entirely.
- Most leaks are ordinary, comprising contact forms carrying health information, consultation answers sent by email, analytics on clinical pages, publicly reachable uploads and forgotten staging copies holding real data.
- Seventy-two hours run from awareness rather than from investigation, every breach is recorded whether reported or not, and fraudulent data protection complaints are circulating and should be verified rather than paid.
FAQs
A declaration that is actually true.
Disclosure repeated: Our publisher builds pharmacy websites and Dataforge PMR. Consultation answers write to a controlled record rather than to an inbox, administrative access is per-person with multi-factor authentication, and access lists are exportable, which is what the Toolkit question is really asking for. Put the seven questions above to us on the same terms as anyone else.
See Dataforge PMR