Custodiance

NHS DSPT · Clinics

DSPT compliance for UK clinics — the website-side checklist 2026

By Jordan Gilbert

In brief

Independent UK clinics in the NHS supply chain inherit Data Security and Protection Toolkit obligations through their contracts, even where the toolkit is treated as a back-office concern. The website is in scope for at least ten named DSPT assertions — from staff training records to incident-response timelines to sub-processor inventories. This briefing names each one, sets out what the toolkit assessor verifies in a browser, and gives the concrete website-side standard.

Most independent UK clinics — private GPs, dental practices, physiotherapy clinics, audiology, podiatry, occupational-health providers — meet the Data Security and Protection Toolkit (DSPT) the same way: an Integrated Care Board, a Primary Care Network, an NHS commissioner, or an occupational-health contracting body sends a renewal pack with one line buried on page nine — “please attach your current DSPT submission confirmation”. The toolkit was meant to live in the practice manager’s folder, not on the website. The contracting body disagrees.

The DSPT is run by NHS England and overseen by the National Data Guardian. It applies to every organisation that handles NHS patient data, and “handles” is read generously: if a clinic receives referrals from a GP practice, supplies an occupational-health service into the NHS, or processes any data flow that originated in NHS-controlled systems, it is in scope. The website is in scope because the website is where most of those data flows start — enquiry forms, referral uploads, appointment requests, complaints submissions. The agency that built the site almost certainly never read the toolkit.

This is the website-side checklist for the 2026 toolkit: ten named assertions, what each one asks for, what the assessor actually verifies, and the concrete standard.

Why the website is in scope at all

The DSPT assessor does not visit the clinic. They read the submission, sample evidence, and spot-check the public-facing surface — which means the website. Every assertion that touches “personal data”, “supplier”, “data flow”, “incident”, or “training” has a website-side footprint the assessor can verify in a browser before any conversation with the practice happens.

The 2026 toolkit publishes its assertions under broad headings — Personal Confidential Data, Staff Responsibilities, Training, Managing Data Access, Process Reviews, Responding to Incidents, Continuity Planning, Unsupported Systems, IT Protection, Accountable Suppliers. Every heading contains assertions the website either satisfies or fails. The ten below are the ones the website most commonly fails on.

The ten website-side DSPT assertions clinics fail

1. Assertion 1.1.x — Personal data is processed lawfully, fairly, and transparently

The toolkit expects a published privacy notice that names lawful basis, retention periods, every sub-processor, and the patient’s rights. Most clinic sites carry a 2018-vintage privacy notice that pre-dates UK GDPR’s named-sub-processor expectations, does not list the form host, does not list the analytics provider, and is silent on retention.

The standard: a privacy notice generated from the practice’s actual sub-processor inventory. Every named third party — Cloudflare for routing, an EU-resident relay for transactional mail, the CRM, the analytics platform — appears with its purpose, its data residency, and the lawful basis under which it processes patient data. Retention periods are explicit (enquiry data 24 months, newsletter list until opt-out, appointment data eight years aligned with the NHS retention schedule).

2. Assertion 1.3.x — A confidentiality and security-of-personal-data notice is in place

Patients must be able to find a plain-English summary of how the practice handles their data. The toolkit calls this a “leaflet” because the assertion text predates the web; on a 2026 site the equivalent is a /privacy page and a one-paragraph block on the enquiry form itself — what happens to this form when it is submitted. Most clinic sites have neither.

The standard: a /privacy page plus a 60-word disclosure block under every enquiry form. The block names the destination (“this form posts to a UK-hosted inbox managed by the practice”), retention (“enquiries are retained for 24 months unless deletion is requested sooner”), and the right to complain to the ICO.

<aside class="enquiry-disclosure">
  <p>This enquiry posts to a UK-hosted inbox managed by [Practice Name].
  We keep enquiry data for 24 months. You can ask us to delete it sooner
  by emailing <a href="mailto:privacy@example.co.uk">privacy@example.co.uk</a>.
  Full <a href="/privacy">privacy notice</a>. You can complain to the
  <a href="https://ico.org.uk">ICO</a> at any time.</p>
</aside>

3. Assertion 4.2.x — Staff complete annual data-security training

The assertion is back-office, but the assessor sample-checks it by looking for the named Information Governance lead on the website. If the staff page lists everyone except the IG lead, or the contact page carries a generic info@ instead of a named privacy contact, the assertion is questioned.

The standard: a named IG / Caldicott Guardian contact on the contact page and in the footer — even for a five-clinician practice. The named individual need not be a dedicated DPO (most clinics that scale are not required to appoint one under UK GDPR Article 37); they have to be findable.

4. Assertion 7.1.x — A documented procedure for responding to data-security incidents exists

The website-side proof is twofold: a /security or /incident-reporting page that names the practice’s response timeline, and a mechanism for patients to report a suspected incident — a route that does not require them to phone reception during opening hours.

The standard: a dedicated /report-a-concern route with a form that posts to the IG lead’s inbox, plus a public statement of the response SLA — acknowledge within 72 hours, ICO notification within 72 hours where the threshold is met under UK GDPR Article 33. The 72-hour figure is the regulatory floor, and assessors expect to see it stated.

5. Assertion 8.x — Unsupported systems are not in use

The website-side reading: the assessor checks the WordPress version (if any), the PHP version exposed in response headers, the plugin set, and the TLS configuration. A clinic site running WordPress on an unmaintained shared host with PHP 7.4 and a 2021-vintage TLS cipher suite fails this assertion in two minutes of headless-browser scanning.

The standard: a statically rendered site on a maintained platform — Astro on a London region as the default configuration. No PHP, no plugin surface, no untracked dependency chain. The supported-stack story is provable from curl -I of the homepage.

6. Assertion 9.x — Robust IT-protection arrangements (firewall, anti-malware, patching)

For a Jamstack-style clinic site, the equivalent is a hardened CSP header, HSTS with includeSubDomains; preload, TLS 1.3, no mixed content, automated dependency updates, and a vulnerability-disclosure address. The assessor does not run nmap; they look for the headers and the .well-known/security.txt.

The standard: a security.txt at /.well-known/security.txt with a named contact, expiry, and policy URL. A CSP that names every allowed origin and excludes inline scripts where possible. Example header set:

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), microphone=(), camera=()

7. Assertion 10.x — All suppliers handling personal data are accountable for protecting it

Every named sub-processor must have a written Data Processing Agreement (DPA) on file, and the website’s privacy notice must name them. The assessor cross-checks the inventory against what they can see firing on the site — the network tab in a browser tells them in 30 seconds whether the privacy notice is complete.

The standard: a published sub-processor list at /framework (or an equivalent maintained route), named per service. The same list referenced in the privacy notice, and in the practice’s Article 30 records of processing.

8. Assertion 1.2.x — Records of processing activities are kept (UK GDPR Article 30)

The Article 30 records live in the practice’s compliance folder, but the website-side preview is the privacy notice. If the privacy notice is missing categories of data, recipients, or retention periods, the assessor infers the underlying Article 30 records are incomplete.

The standard: a privacy notice structured by Article 30 fields — categories of data subjects, categories of personal data, purposes of processing, recipients, retention, transfers outside the UK. The same structure used in the practice’s internal records. The notice is the public projection of the records.

9. Assertion 6.x — A record of business-continuity tests is maintained

The assessor wants evidence that the practice has considered what happens if the website goes down on the day of a clinic. The website-side proof is a documented incident page — a known URL that stays up when the main site is down, hosted on a different provider — or an explicit fallback on the contact page.

The standard: a status URL on a separate provider and an explicit fallback phone number on every critical page. The contact page should not be the only path to the practice.

10. Assertion 5.x — Process reviews are completed at least annually

The website-side proof is the lastUpdated field on the privacy notice and the sub-processor list. If both documents were last updated in 2023, the assessor infers no annual review happened. If both were updated in the last twelve months, the assertion is supported without further conversation.

The standard: explicit lastUpdated dates on /privacy, the sub-processor list, /cookies, and any other compliance-adjacent route, surfaced in the page footer. Updated when the underlying records change, not on a calendar tick.

Two bonus assertions the assessor will spot-check

Bonus A — Cookies and similar technologies are lawful

PECR is not part of the DSPT toolkit text, but assessors routinely raise cookies on a clinic submission, because non-compliant cookies are the single most common cross-cutting finding. A clinic site running Google Analytics without prior consent fails PECR Regulation 6, which the assessor then notes as a related concern in the toolkit narrative.

The standard: cookieless analytics (Plausible, EU-resident, as the default), no tracking pixels, and a /cookies page that lists every cookie set with its purpose and lifetime. Where no cookies are set without consent, the disclosure is short and the assertion is easy.

Bonus B — Subject Access Requests can be handled within one month

The assessor expects a published route for a Subject Access Request. The website is the obvious channel. Most clinic sites bury SAR handling in a 2,400-word privacy notice; the assessor wants a one-click path from the homepage footer.

The standard: a /subject-access-request page with a form (or a direct mailto) and an explicit reference to the one-calendar-month statutory deadline under UK GDPR Article 12(3). Footer link in every layout.

What “compliant” looks like in markup

A clinic homepage that satisfies the website-side DSPT assertions has, at minimum, these elements visible in the page source or in curl -I:

<!-- Footer block referenced from every layout -->
<footer>
  <nav aria-label="Compliance">
    <a href="/privacy">Privacy notice (updated 3 June 2026)</a>
    <a href="/cookies">Cookies</a>
    <a href="/compliance">Sub-processors</a>
    <a href="/report-a-concern">Report a privacy concern</a>
    <a href="/subject-access-request">Subject access request</a>
    <a href="/.well-known/security.txt">Security contact</a>
  </nav>
  <p>Information Governance lead: Dr A. Practitioner ·
     <a href="mailto:ig@example.co.uk">ig@example.co.uk</a></p>
</footer>

That single footer block addresses six of the ten assertions before the assessor opens the privacy notice itself.

How a regulated-grade estate handles this

Custodiance runs this as a managed estate, in-jurisdiction, to your regulator’s standard. A DSPT-aligned clinic estate follows the same EU-sovereign foundation as the clinics GDPR briefing — the same Article 30 and Article 28 documentation pack — with the DSPT-specific controls layered in and carried continuously rather than fixed once:

  • The named IG / Caldicott contact, present on the contact page and in the footer.
  • The /report-a-concern route, posting to the IG lead’s inbox with the 72-hour SLA stated publicly.
  • The /subject-access-request route, referencing the one-calendar-month deadline.
  • The lastUpdated discipline on every compliance-adjacent page, maintained as records change.
  • The security.txt file, the hardened header set, and the supported, statically rendered stack.

At the close of onboarding the practice receives a DSPT-evidence pack: a document mapping each of the ten assertions above to the URL on its estate that satisfies it. The pack goes straight into the toolkit submission.

This is the floor of a Growth engagement (£1,495/mo). Where the practice runs multiple sites, online booking with deposits, or wants a fractional CTO owning the compliance posture and the roadmap, that is an Embedded engagement (from £6,000/mo, bespoke).

Where this fits

The equivalent regulatory failures for solicitors, accountancy practices, schools, and estate agencies follow the same residency-and-evidence pattern. The companion read is the GDPR-focused clinic briefing — same failure surface, the controller-duty framing rather than the toolkit one. The published posture behind all of this is the Custodiance framework. When a clinic’s next DSPT submission is approaching and the website has not been audited against the toolkit, the next step is to request a scoping call.

Sources & methodology

This checklist is drawn from the current published DSPT assertions, the UK GDPR articles cross-referenced, and assertion-by-assertion review of independent clinic submissions across 2025 and 2026.

Sources

  1. Data Security and Protection Toolkit (current standard) — NHS England
  2. UK GDPR Article 30 — Records of processing activities — Information Commissioner's Office
  3. UK GDPR Article 33 — Notification of a personal data breach — Information Commissioner's Office
  4. The Caldicott Principles (2020 update) — National Data Guardian for Health and Social Care
  5. Privacy and Electronic Communications Regulations (PECR), Regulation 6 — Information Commissioner's Office
  6. NHS Records Retention Schedule — NHS England

Custody, not marketing.

Have a senior partner read your estate against this.

A scoping call is a measured conversation about your obligations, your current setup, and what it would take to run it to your regulator's standard. No obligation, and no pressure.

Request a scoping call More briefings