A Data Protection Impact Assessment (DPIA) is the documented risk assessment UK GDPR requires for high-risk processing — and any UK telehealth service processing special-category patient data at scale meets the high-risk threshold. Most operators write a DPIA once at launch and don't touch it again. That's the version inspectors flag. This piece is the operator's guide to a DPIA that actually reflects the operation and survives scrutiny.
When a DPIA is mandatory for UK telehealth
UK GDPR Article 35 requires a DPIA where processing is likely to result in high risk to individuals. ICO guidance lists specific triggers that always require one: systematic and extensive profiling, large-scale processing of special-category data (health data qualifies), systematic monitoring of publicly accessible areas, and other high-risk operations.
For UK telehealth operators, the DPIA is not optional at launch — the processing meets the special-category-at-scale threshold from patient one. Operators who launched without one should complete a retrospective DPIA immediately. Operators with an existing DPIA should review it every 12 months and update after any material change to the processing.
The seven sections every UK telehealth DPIA needs
Section 1 — Systematic description of the processing: what data, from whom, for what purpose, how collected, how stored, how used, how long retained, who has access, transferred where. Section 2 — Necessity and proportionality assessment: why the processing is necessary for the purpose, why less-intrusive alternatives don't work, whether the processing is proportionate to the risk. Section 3 — Risks to data subjects: specific risks identified, likelihood and severity assessment.
Section 4 — Measures to address the risks: technical and organisational measures reducing likelihood and/or severity. Section 5 — Consultation with the Data Protection Officer. Section 6 — Consultation with data subjects if practicable. Section 7 — Sign-off, review cadence, and residual risk assessment. Each section documented; no boilerplate copying from templates that don't actually describe the operation.
What high-risk processing actually looks like in UK telehealth
Practical high-risk processing patterns UK telehealth operators should surface in the DPIA: patient data flowing to third-party dispensing partners; identity verification data captured by external providers (Onfido, Veriff, Yoti); clinical decision-support tools processing patient data; marketing platforms with patient data; support tooling with clinical context; analytics platforms with cohort data; cross-border data flows (if applicable).
Each processing pattern needs specific risk assessment. The 'we process patient data' one-line description doesn't survive scrutiny. Inspectors want the specific processing patterns documented individually with their own risks and mitigations.
Common DPIA weaknesses that fail ICO scrutiny
Six weaknesses that consistently fail. 1) Boilerplate description that doesn't reflect the actual operation. 2) Necessity assessment that reads like justification rather than analysis of alternatives. 3) Generic risks list not tied to the specific processing. 4) Mitigations claimed but not verifiable in operation. 5) DPO consultation logged but not substantively reflected in the DPIA. 6) No review since the original version despite material changes to the operation.
Any one of these weaknesses is visible on read. All six are common. Fixing them takes time — usually 2-3 weeks of focused work — but the DPIA that results is meaningfully more defensible.
How to structure DPIA review cadence
Practical cadence: full annual review, event-triggered updates when material change happens (new processing pattern, new supplier with data access, new patient demographic, new category). The DPO or nominated data protection lead runs the review; the operational leadership signs off; the version log records changes.
Material change triggers include: adding a new dispensing partner, integrating a new identity verification provider, launching a new medical category with different data patterns, changing the technology stack in ways that affect data flow, opening cross-border processing. Any of these should trigger a DPIA review before the change goes live — not after.
Sample DPIA structure for a UK telehealth brand
A workable outline for a UK telehealth DPIA: 1) Executive summary. 2) Description of processing (with subsections for consultation, prescribing, dispensing, ongoing care, marketing, support). 3) Necessity and proportionality. 4) Consultation with DPO and data subjects. 5) Risk assessment (with rows per risk covering likelihood, severity, mitigation). 6) Compliance measures against UK GDPR principles (lawfulness, fairness, transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality, accountability). 7) Sign-off and review schedule.
Length depends on operation size and complexity. Small operator: 10-15 pages. Larger multi-category operator: 30-50 pages. Padded 5-page DPIA fails scrutiny; verbose 100-page DPIA fails readability. Substance-appropriate length matters more than fitting a target.
How PExpo handles DPIA support for brand and clinic customers
PExpo's brand and clinic models include a DPIA framework covering the regulated-layer processing (dispensing, prescriber workflow, pharmacovigilance, patient record). Brand and clinic customers extend this with their own brand-side processing (marketing, patient acquisition, support tooling). The split is documented in the DPA between PExpo and the customer.
The framework accelerates DPIA completion for new brand launches — the shared-layer sections don't need to be written from scratch. Brand-side and customer-specific processing sections do. See our [brand model page](../brands.html) for the operational scope, our [DPA page](../dpa.html) for the data-processing terms, or our [UK GDPR guide](uk-gdpr-telehealth-lawful-bases.html) for the broader regulatory context.
A UK telehealth DPIA is not optional at launch — special-category patient data at scale meets the UK GDPR high-risk threshold from patient one. Most operators write a DPIA once and never touch it. That's the version inspectors flag.
Six weaknesses consistently fail ICO scrutiny: boilerplate description, justification rather than analysis, generic risks, unverifiable mitigations, superficial DPO consultation, and no review despite material change. Any one is visible on read.
A workable UK telehealth DPIA is a living document reflecting actual processing, updated when the operation materially changes, and reviewed annually as a backstop. Operators who treat it as compliance paperwork fail ICO scrutiny; operators who treat it as operational discipline pass. See our DPA page for PExpo's data-processing terms, our UK GDPR guide, or our brand model page for the DPIA framework included in the operational scope.
Frequently asked questions
When is a DPIA required for a UK telehealth service?
Before high-risk processing begins. UK telehealth processing of special-category patient data at scale meets the ICO high-risk threshold from patient one, so a DPIA is required at launch. Retrospective DPIA is required immediately if launched without one.
How often should I update the UK telehealth DPIA?
Full review annually plus event-triggered updates for material changes (new dispensing partner, new category, new integration with data access, new patient demographic, cross-border processing). Review before material changes go live, not after.
Does PExpo provide DPIA support for brand customers?
Yes — PExpo's brand and clinic models include a DPIA framework covering the regulated-layer processing. Brand-side and customer-specific processing sections are added by the customer. Split documented in the DPA. See our brand model page.
