Most independent UK clinics — private GPs, dental practices, physiotherapy clinics, audiology, podiatry, occupational-health providers — discover 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 your 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, you are 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 looks at, and the concrete fix.

Why the website is in scope at all

The DSPT assessor does not visit your clinic. They read your 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 list below is the ten 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 have a 2018-vintage privacy notice that pre-dates UK GDPR’s named-sub-processor expectations, doesn’t list the form host, doesn’t list the analytics provider, and is silent on retention.

The fix: a privacy notice generated from the practice’s actual sub-processor inventory. Every named third party — Cloudflare for routing, Resend EU for transactional mail, Capsule for the CRM, Plausible for analytics — 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 8 years aligned with the NHS retention schedule).

2. Assertion 1.3.x — A confidentiality and security-of-personal-data leaflet/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 you submit it”). Most clinic sites have neither.

The fix: 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 (“we retain enquiries for 24 months unless you ask us to delete sooner”), and the right to complain to the ICO. Astro markup pattern:

<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 will sample-check 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 has a generic info@ instead of a named privacy contact, the assertion is questioned.

The fix: a named IG / Caldicott Guardian contact on the contact page and in the footer. Even for a five-clinician practice. The named individual doesn’t have to be a dedicated DPO (most clinics that scale aren’t 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 “tell us about a privacy concern” route that does not require them to phone reception during opening hours).

The fix: 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 fix: a statically rendered site on a maintained platform (Astro on Vercel London is the configuration we run by default at the Foundation tier and above). 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 doesn’t run nmap; they look for the headers and the .well-known/security.txt.

The fix: 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 (network tab in a browser tells them in 30 seconds whether the privacy notice is complete).

The fix: a published sub-processor list at /compliance (or equivalent), maintained per-client, named per service. Same list referenced in the privacy notice. Same list referenced in the practice’s Article 30 records of processing.

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 fix: 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 thought about 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 (“if the site is unavailable, call 0113 …”).

The fix: a status URL on a separate provider (Vercel for primary, a Cloudflare Pages mirror for status, for example) 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 fix: explicit lastUpdated dates on /privacy, /compliance, /cookies, and any other compliance-adjacent route. Surface them in the page footer. Update them 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 every assessor I’ve spoken to about a clinic submission asked about cookies 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 fix: cookieless analytics (Plausible EU is our default), no tracking pixels, and a /cookies page that lists every cookie set with its purpose and lifetime. If there are no cookies 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 fix: 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.

The fix engagement

A DSPT-aligned site rebuild for an independent clinic on the Foundation tier follows the same week-long pattern as the clinics GDPR engagement — same EU-sovereign stack, same Article 30 + Article 28 documentation pack — with the DSPT-specific additions layered in: the named IG contact, the /report-a-concern route, the /subject-access-request route, the lastUpdated discipline on every compliance page, the security.txt file. We hand the practice a DSPT-evidence pack at the end of the engagement — a PDF mapping each of the ten assertions above to the URL on their new site that satisfies it. The pack goes straight into the toolkit submission.

Talk to a builder

If your clinic’s next DSPT submission is in the next ninety days and the website hasn’t been audited against the toolkit — WhatsApp me. I’ll walk through the ten assertions above against your live site, mark the ones that already pass, and give you a specific list of what needs to change.

The next step is the clinics landing page for what a UK Web Marketing site does for an independent practice, and the managed website service for what the ongoing posture looks like across the year. Start with a free audit if you’d rather see the gaps before any conversation. The companion read is the GDPR-focused clinic post — same four failure modes, different regulator framing.

Sources & methodology

Checklist drawn from the current published DSPT assertions, the UK GDPR articles cross-referenced, and audit notes from independent clinic submissions across 2025–2026.

Data Security and Protection Toolkit (current standard) — NHS England — https://www.dsptoolkit.nhs.uk/
UK GDPR Article 30 — Records of processing activities — Information Commissioner’s Office — https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/documentation/
UK GDPR Article 33 — Notification of a personal data breach — ICO — https://ico.org.uk/for-organisations/report-a-breach/
The Caldicott Principles (2020 update) — National Data Guardian for Health and Social Care — https://www.gov.uk/government/publications/the-caldicott-principles
Privacy and Electronic Communications Regulations (PECR), Regulation 6 — ICO — https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guide-to-pecr/
NHS Records Retention Schedule — NHS England — https://transform.england.nhs.uk/information-governance/guidance/records-management-code/
Methodology: assertion-by-assertion review of independent UK clinic websites preparing or renewing DSPT submissions, 2025–2026. Last updated 3 June 2026.

Cite this article: Jordan Gilbert, “DSPT compliance for UK clinics — the website-side checklist 2026”, UK Web Marketing, 3 June 2026. https://ukwebmarketing.com/blog/dspt-compliance-uk-clinics-website-checklist

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