Most UK clinic websites — independent practices in podiatry, dentistry, physiotherapy, mental health, fertility, cosmetic, and veterinary care — were built by a high-street web agency a few years ago on whichever SaaS stack carried a template. WordPress on a US host, a Mailchimp signup, a HubSpot form embed, Google Analytics, perhaps Calendly for appointments. The site works. Patients find it. Bookings come in.
It also quietly fails UK GDPR. That gap is the question a patient — and, increasingly, a professional indemnity insurer, or any ICB or PCN reviewing clinical data flows — will eventually ask. The practice is the data controller. The agency is not on the hook; the practice is.
This briefing sets out what is actually wrong on a typical clinic site, and what a regulated-grade estate puts in its place.
The Four Clinic Failure Modes
Every non-compliant UK clinic site fails on one or more of the same four points. We call it The Four Clinic Failure Modes — the framework Custodiance applies on every clinic-site review:
- Patient enquiry forms processed on US infrastructure — HubSpot, Mailchimp, Typeform, or a WordPress plugin routing to a US inbox.
- Analytics and tracking pixels with no lawful basis — Google Analytics, Facebook Pixel, LinkedIn Insight Tag.
- A CRM exporting patient identifiers to US tooling — HubSpot Free, Salesforce, or Pipedrive Lite holding names, contact details, and clinical context in the notes field.
- Email marketing mailing patients from US servers — Mailchimp, ConvertKit, or ActiveCampaign.
Where a clinic site fails any two of The Four Clinic Failure Modes, the Article 30 and Article 28 documentation gap is something a DPO will flag inside an hour.
The statute, in its own words
UK GDPR Article 9(1) — special category data:
“Processing of personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person’s sex life or sexual orientation shall be prohibited.”
A patient enquiry that names a condition — “I would like to ask about your fertility services”, “my son sees a mental-health clinician” — is special category data the moment it lands. Article 9(2) carves out the lawful bases (explicit consent, healthcare provision under 9(2)(h)), but the special-category bar is the floor, not the ceiling.
The Caldicott Principles (2020 update, National Data Guardian) add the NHS-adjacent layer. Principle 1: “Justify the purpose for using confidential information.” Principle 4: “Access to confidential information should be on a strict need-to-know basis.” A US-resident enquiry form fails Principle 4 the moment a CLOUD Act request becomes lawful access by a third party the clinic never named.
What the clinic is accountable for
As an independent UK clinic, the practice is a data controller under UK GDPR. That is the same law as before Brexit, enforced by the ICO under the Data Protection Act 2018. Three specific obligations follow:
- Article 30 — keep records of processing activities: a written list of what personal data the practice processes, why, where it lives, who has access, and how long it is retained.
- Articles 28 and 44–49 — where the practice uses a sub-processor (the website host, the form processor, the CRM), a Data Processing Agreement must be in place; and where the sub-processor transfers data outside the UK and EU, a transfer mechanism is required, comprising Standard Contractual Clauses plus a Transfer Risk Assessment.
- Article 32 — appropriate technical and organisational measures to keep the data secure.
In addition, where the practice is NHS-adjacent — most clinics are, at least for referrals — it is expected to align with the Caldicott Principles (justify every use of identifiable patient information) and to meet the Data Security and Protection Toolkit (DSPT) baseline.
None of those laws explicitly requires a website hosted in the UK or the EU. But every one of them eventually asks the same question: where does the data live, who has access, and can the practice prove it? On a typical clinic site, that is the question the practice cannot answer.
The four specific failures on a typical clinic site
1. Patient enquiry forms processed on US infrastructure
The “Contact us” form on most clinic websites is a HubSpot embed, a Mailchimp form, a Typeform widget, or a WordPress plugin sending to a US-resident inbox. Patient names, telephone numbers, and the conditions mentioned in the message are all processed and stored on US servers.
US-resident SaaS is subject to the US CLOUD Act (2018), which allows US authorities to compel disclosure of stored data even where that data physically sits in the EU. The US Department of Justice has exercised this power against Microsoft, Google, and Amazon since 2019. A patient writing to a clinic about a sensitive condition does not expect that letter to be subject to a US request. Neither does the ICO.
The standard: an enquiry form that posts to the estate’s own endpoint rather than a US form tool, relayed by Scaleway in France to the practice’s own mailbox, in its Microsoft 365 or Google Workspace tenant or at Proton in Switzerland, a country the UK and EU recognise as adequate; where submissions are stored, they sit on a server we operate at Hetzner in Germany. Every provider in the path, US-incorporated ones included, is named in the sub-processor list. The same experience for the patient; a very different posture for the controller.
2. Analytics and tracking pixels that are not lawful-basis-anchored
Google Analytics, Facebook Pixel, and the LinkedIn Insight Tag are all US-resident, and all process IP addresses and behaviour data that qualify as personal data under UK GDPR. The CJEU’s Schrems II ruling (2020) made bulk transfer of EU personal data to US infrastructure legally precarious. Several EU data protection authorities — Austria, France, Italy — have since ruled that Google Analytics is incompatible with GDPR without significant additional measures.
The standard: cookieless analytics on a server in the UK or EU. Custodiance runs its own Plausible Community Edition server on OVHcloud hardware in France: no cookies, no personal profiles, no US-resident pipeline. It is configured where a practice wants analytics, with reporting for the practice.
3. A CRM that exports patient identifiers to US tooling
Where a clinic uses HubSpot Free, Salesforce, or Pipedrive Lite to track enquiries, the practice is maintaining a US-resident database of patient names, contact details, and — often — clinical context in the notes field. The DPA in place (if any) was probably auto-signed during signup; the Transfer Risk Assessment almost certainly is not on file.
The standard: a CRM opened in the practice’s own name, under its own contract, with a provider that holds the data in the UK or EU (Capsule, in Manchester, or Pipedrive on its EU plan are the usual candidates): the same workflow, with the data-residency position intact and documented in the practice’s sub-processor schedule. The enquiry form is wired to the CRM contact record within the same UK and EU data-residency envelope.
4. Email marketing that mails patients from US infrastructure
Mailchimp, ConvertKit, and ActiveCampaign are all US-resident. Where a clinic sends a newsletter — “our new podiatrist starts next month” — to patients who opted in, that mail goes via US servers. The contents carry identifying information (name and clinic relationship) at minimum, and often health-adjacent context.
The standard: transactional mail relayed by Scaleway in France, and patient broadcasts on an EU-established newsletter platform (MailerLite, in Lithuania) with a separate, explicit opt-in and the list held there, named in the practice’s sub-processor schedule. The same workflow, with the list and the sending both in the EU.
How a regulated-grade estate handles this
Custodiance runs this as a managed estate, with UK and EU data residency, to your regulator’s standard. The work that puts a clinic’s site right is the work the estate carries continuously, not a one-off remediation:
- Audit. The current site and every third-party service it uses — forms, analytics, CRM, email, booking widget. Each sub-processor and its residency, set against the practice’s current Article 30 records, or built from scratch where none exist.
- Hosting. The site pinned to a London region (lhr1), content and structure carried over, with no change to the patient-facing experience.
- Intake. The enquiry form migrated to the estate’s own endpoint, relayed by Scaleway in France to the practice’s own mailbox, with lawful-basis and retention copy added, and the practice’s privacy notice linked on every form.
- Analytics. Google Analytics replaced with our own Plausible Community Edition server in France (cookieless). Tracking pixels stripped.
- CRM. Opened in the practice’s own name with an EU-plan provider such as Capsule, with the enquiry data exported, transformed and imported, and the form wired to the contact record.
- Email. Patient broadcasts moved to an EU newsletter platform (MailerLite, Lithuania) with a separate opt-in, with the relay and the list both in the EU.
- Documentation. Article 30 records of processing and an Article 28 DPA pack (our data processing agreement and sub-processor list) ready for the practice’s DPO or counsel to review, mapped to the sub-processor list.
This is the floor of a Growth engagement, quoted after a scoping call. Where the practice runs online booking with deposits across multiple sites, that is scoped on a call.
What the clinic keeps
Patient relationships. Clinical reputation. The domain. The content. All of it. The practice is not migrating away from anything — it is moving the website the practice runs on to infrastructure that holds up when an enquiry lands from someone who is, quietly, testing the data-handling posture.
The patient who asks “where does the form land?” is increasingly common, particularly among the data-aware professionals who fill private-clinic books. Having the answer is increasingly the price of keeping them.
Where this fits
This is the cornerstone of the clinics cluster. The plain-English special-category detail is in health data on your clinic website; the NHS-scope decision is in does your private clinic need the DSPT, and the practical NHS-adjacent checklist in the DSPT website-side checklist. The publish-versus-private balance is in the CQC-ready clinic website briefing, and the booking-specific rules in online booking for clinics without breaking data rules. The equivalent regulatory failures for solicitors, accountancy practices, schools, and estate agencies follow the same residency-gap pattern. The published posture behind all of this, including the documented sub-processor list, is the Custodiance framework, and the overview for practices is Custodiance for clinics. When a clinic is ready, the next step is to request a scoping call.
Sources & methodology
The Four Clinic Failure Modes framework is built from clinic-site audits and the primary regulatory text. Source attribution is given where rules are quoted.
- UK GDPR Article 9(1) — Information Commissioner’s Office, “Special category data” — https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/lawful-basis/special-category-data/
- The Caldicott Principles (2020 update) — National Data Guardian for Health and Social Care — https://www.gov.uk/government/publications/the-caldicott-principles
- CJEU Schrems II ruling — Case C-311/18, Data Protection Commissioner v Facebook Ireland and Maximillian Schrems, 16 July 2020 — https://curia.europa.eu/juris/liste.jsf?num=C-311/18
- US CLOUD Act (2018) — Clarifying Lawful Overseas Use of Data Act, Pub. L. 115-141 (Mar. 23, 2018) — https://www.congress.gov/bill/115th-congress/house-bill/4943
- Data Security and Protection Toolkit (DSPT) baseline — NHS England — https://www.dsptoolkit.nhs.uk/
- Methodology: failure-mode framework derived from independent UK clinic-site audits, 2025 to 2026. Last updated 1 June 2026.