What security must a pharmacy actually have?
Three obligations operate together. 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. 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. That is contractual, not advisory. And the GPhC standards require that risks associated with providing pharmacy services are identified and managed. Our analysis of inspection outcomes identifies that 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. Category 1 organisations have been required since 2024/25 to complete their submission using the Cyber Assessment Framework — 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. That was described as the most significant change since the Toolkit launched in 2018. The direction of travel is toward evidence that controls actually operate, not just that policies exist. A pharmacy relying on a document asserting that all staff complete annual training should expect the question to become whether records show that they did.
Community Pharmacy England worked with the NHS Toolkit team specifically to keep the pharmacy workload proportionate. That is why Category 3 completion remains manageable. It is not a reason to assume it will stay unchanged.
What changed in the DSPT for 2026?
The 2026 submission fell due on 30 June 2026, which has passed. A pharmacy that has not submitted is in breach of a contractual requirement under the Terms of Service, not merely behind on administration. If you have missed it, that is the first item to address.
The changes themselves were characterised as a small number of targeted updates to make completion clearer and quicker. The most notable is a new question concerning multi-factor authentication. That single question is the thread connecting this article's two halves. A pharmacy answering it accurately must know whether multi-factor authentication is enforced across its systems. 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. An inaccurate list produces delays. And organisations that have kept the sector GDPR workbook templates current can satisfy the criteria for around half the Toolkit questions. Maintaining those documents through the year is 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. Its assertions on access control, authentication, staff leavers, incident response and supplier arrangements are made at the level of the organisation, not of a particular room. A pharmacy that asserted access is removed promptly when staff leave, while a former dispenser retains a working login to the website's admin panel, has made an assertion that is not true. A pharmacy that answered the new multi-factor authentication question yes, while its website administration sits behind a shared password known to the agency that 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. So the baseline below is not a wish list. It is the set of arrangements that 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. 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. A compromised retail site loses orders. 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, so it never reaches the pharmacy's own servers.
Two benefits follow. The pharmacy stays within the lightest compliance category for card security, which our payments criteria guide sets out. And it removes an entire category of breach, because data never held cannot be stolen.
Two practices should be refused outright. Accepting card numbers into the pharmacy's own forms, however convenient the integration appears. And recording card details anywhere in order notes, patient records or email. That 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 that routes to a shared inbox and a marketing platform. Neither was designed to hold special category data. There is no identified lawful basis and 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. That is a disclosure, not a measurement.
Attachments and uploads left publicly reachable. Patient-supplied photographs or documents stored at predictable, unauthenticated addresses. That is a configuration failure, not 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. It 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. 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. It will be more than you expect.
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 that no longer exists. And shared accounts defeat the entire control. 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. A pharmacy that does not hold the top-level accounts cannot run this audit at all.
What happens in the first 72 hours of a breach?
The obligation is well known and the timing routinely misunderstood. The seventy-two hours run from becoming aware of the breach, not 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. For health data that is a low threshold to cross. Notify the Information Commissioner's Office within seventy-two hours where that risk exists. Submit what is known and supplement 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. 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. 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, not sit in a separate technical file that nobody reads.
Are those GDPR complaint emails real?
Some are not. The sector body has warned about them specifically, which makes this worth knowing before one arrives.
The fraudulent messages share recognisable characteristics: urgent deadlines, threats of enforcement action, and 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 those cases 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, not those in the message. Check the pharmacy's own records for the alleged interaction. Never make a payment or disclose information in response to pressure. Genuine information governance enquiries from real patients do arrive, and they deserve a proper answer. That is precisely why a pharmacy needs 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, disclosed here as it is throughout this library. Put these seven questions to this publisher on identical terms. A developer who treats them as an insult rather than a specification has answered the more useful question first.
Key takeaways
- Three obligations cover pharmacy website security: 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, not subject to the Cyber Assessment Framework applied to Category 1 since 2024/25. Version 8 has still moved the Toolkit toward outcome-based evidence.
- The 2026 submission was due 30 June and is a contractual requirement. The notable change is a new multi-factor authentication question, which reaches website administration.
- The declaration already covers the website. 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. That keeps the lightest compliance category and removes a class of breach entirely.
- Most leaks are ordinary: 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, not from investigation. Every breach is recorded whether reported or not. Fraudulent data protection complaints are circulating — verify them rather than paying.
Sources and further reading
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