UK GDPR and Health Data

UK GDPR is the UK’s post-Brexit data protection law, sitting alongside the Data Protection Act 2018. For anyone building health IT systems that touch UK patient data, it is the foundational legal layer — the functional equivalent of HIPAA in the US, though the mechanisms differ substantially. Understanding the differences matters: a US-trained developer who maps HIPAA mental models directly onto UK GDPR will make wrong assumptions about consent, data sharing, and what “compliant” actually requires.

This page covers the obligations that directly shape engineering decisions. It is a technical reference, not legal advice.

For the NHS-specific technical standards layer that sits on top of UK GDPR, see NHS England Digital Standards. For the UK Core FHIR profiles, see UK Core FHIR Profiles.

UK GDPR vs EU GDPR

UK GDPR came into force on 1 January 2021 when the UK left the EU single market. It is the EU GDPR 2016/679 incorporated into UK law with minor modifications under the European Union (Withdrawal) Act 2018, read alongside the Data Protection Act 2018 (DPA 2018).

For health data purposes, the material differences from EU GDPR are small: the same principles apply, the same special category conditions exist (via Schedule 1 DPA 2018), and the same rights framework holds. The most operationally significant difference is international transfers. UK GDPR restricts transfers to third countries without adequate protection. The EU-UK adequacy decision (currently in place) means UK-to-EU transfers are permitted; UK-to-US transfers require a mechanism — Standard Contractual Clauses (UK SCCs, also called IDTA — International Data Transfer Agreement) or the UK Extension to the EU-US Data Privacy Framework where applicable.

Practical implication: If your system transfers health data to US-based cloud infrastructure, you need an IDTA or equivalent transfer mechanism in place. Using a US cloud provider for UK patient data without documented transfer basis is a compliance gap.

Health data as special category data

Health data is “special category personal data” under UK GDPR Article 9 equivalent. Processing it requires both a lawful basis under Article 6 (the general processing conditions) and a separate condition under Article 9 (the special category conditions).

This two-layer requirement is the most common source of compliance confusion. Having patient consent does not, by itself, make processing lawful — you still need a valid Article 6 basis. And having a legitimate business purpose does not, by itself, permit processing health data — you also need an Article 9 condition.

What counts as health data: physical or mental health information, including information about healthcare services provided. This is broader than it reads. Inferences that reveal health status, appointment records, prescription data, mental health history, and genomic data all qualify.

Lawful bases and special category conditions

Article 6 lawful bases most relevant to health IT

Basis	Typical health IT scenario
Consent (Art 6(1)(a))	Patient-facing apps where patients actively opt in; rarely appropriate for system-level processing
Contract (Art 6(1)(b))	Processing necessary to deliver a contracted health service to the individual
Legal obligation (Art 6(1)(c))	Mandatory reporting, statutory data sharing
Vital interests (Art 6(1)(d))	Emergency care scenarios only
Legitimate interests (Art 6(1)(f))	Healthcare organisations for internal operational use; not available to public authorities
Public task (Art 6(1)(e))	NHS bodies and public health authorities performing statutory functions

Most NHS and NHS-connected processing relies on public task (for NHS bodies) or legitimate interests (for private health IT vendors). Consent is not the default — and if you choose it, you must be able to demonstrate it was freely given, specific, and withdrawable without detriment.

Schedule 1 DPA 2018 — special category conditions

The conditions that unlock health data processing in the UK are in Schedule 1 of the DPA 2018. The most operationally relevant:

Schedule 1 condition	When it applies
Para 2 — Health and social care	Processing necessary for health or social care purposes by a health professional, or under a duty of confidentiality
Para 4 — Research, statistics, archiving	Processing for scientific/historical research or statistical purposes with appropriate safeguards
Para 7 — Occupational health	Processing by an occupational health professional
Para 10 — Preventing or detecting unlawful acts	Fraud detection in healthcare payments

Para 2 is the workhorse condition for most health IT processing. It requires that the processing be necessary for a health or social care purpose and that a duty of confidentiality is in place or the processor is a regulated health professional.

What this means for vendors: If you are a health IT vendor processing patient data on behalf of an NHS Trust, the Trust is the controller; you are the processor. The Trust relies on Para 2; your Data Processing Agreement with the Trust must reflect this. You cannot independently rely on Para 2 as a processor.

Controller and processor model

UK GDPR’s controller/processor distinction is the closest structural analogue to HIPAA’s covered entity/business associate model, but it works differently.

A controller determines the purposes and means of processing — typically the NHS Trust, GP practice, or health organisation holding the patient relationship. A processor processes data only on the controller’s documented instructions — typically the vendor or system integrator providing services to the controller.

The key obligations:

• Controllers choose processors that offer sufficient guarantees; this is usually demonstrated through ISO 27001, Cyber Essentials Plus, and DSPT completion
• Data Processing Agreements (DPAs) are mandatory whenever a controller engages a processor; the DPA must include the prescribed content from Article 28(3) UK GDPR — subject matter, nature and purpose, type of personal data, duration, controller obligations, and processor obligations
• Processors must not sub-process without prior written authorisation from the controller
• Joint controllers exist when two organisations independently determine purposes and means together — this requires a documented arrangement and a contact point for data subjects

Common error: Vendors treating themselves as controllers of patient data when they are functionally processors. If your system processes patient data purely to provide a service to an NHS organisation, you are almost certainly a processor. Claiming controller status for patient data you process on behalf of the NHS creates obligations and liabilities that are inappropriate and likely incorrect.

Data subject rights

UK GDPR grants individuals rights over their data. In health contexts, some rights are limited.

Right	Health context notes
Access (SAR)	30-day response window; fee-free; health records access has a specific regime under DPA 2018 s.182
Erasure	Not absolute — care records have statutory retention requirements; clinical safety may override erasure
Portability	Applies only to automated processing based on consent or contract; not to most NHS processing (public task basis)
Rectification	Must be honoured; implement audit trails to track corrections
Restriction	Patient can request restriction pending a dispute about accuracy
Objection	Applies to legitimate interests processing; harder to exercise against public task processing

Engineering implication for portability: Because most NHS processing relies on public task rather than consent, the right to data portability does not apply to most NHS patient data. Patient-facing apps using consent as their basis must support portability. Know which basis you’re relying on — it determines which rights apply.

Data Protection Impact Assessments (DPIA)

A DPIA is mandatory (not optional) before processing that is likely to result in high risk to individuals. Health data processing by definition involves sensitive data; in practice, most non-trivial health IT systems require a DPIA.

Mandatory DPIA triggers most relevant to health IT:

• Processing special category data (health data) on a large scale
• Systematic monitoring of individuals (e.g., continuous health monitoring devices)
• Processing involving new technologies or novel uses of existing data
• Profiling that could affect access to health services
• Processing children’s data

A DPIA must: describe the processing and its purposes; assess necessity and proportionality; identify risks to individuals; and identify measures to address those risks. If residual risk remains high after mitigation, you must consult the ICO before proceeding.

Who owns the DPIA: The controller owns it. Processors typically contribute to it by providing technical documentation, security information, and sub-processor lists. Building and maintaining a DPIA is the controller’s obligation; being an unhelpful processor on this is a commercial risk.

Security obligations

UK GDPR Article 32 requires “appropriate technical and organisational measures” to protect personal data — deliberately non-prescriptive. In health contexts, “appropriate” is calibrated against the sensitivity of health data and the potential harm from a breach.

The ICO and NHS guidance consistently expect:

• Pseudonymisation and encryption where technically feasible — data at rest and in transit; TLS 1.2 minimum, TLS 1.3 preferred
• Access control — role-based, minimum necessary access; audit logging of access to patient data
• Integrity — controls to detect unauthorised alteration
• Availability and resilience — backup and recovery capability; incident response plans
• Regular testing — penetration testing, vulnerability management

Practical floor for NHS-connected suppliers: Cyber Essentials Plus plus DSPT compliance. NHS contracts typically require this. ISO 27001 is expected for larger suppliers.

Breach notification

UK GDPR requires breach notification to the ICO within 72 hours of becoming aware of a breach (where feasible). If notification is not within 72 hours, the delay must be explained. Notification to affected individuals is required where the breach is likely to result in high risk to them.

For health data breaches, the ICO treats the risk as inherently elevated. A breach of unencrypted health records typically requires individual notification.

What counts as a breach: Not just unauthorised external access — accidental disclosure to the wrong recipient, loss of an unencrypted device, and inadvertent exposure of health data in an API response all qualify. Healthcare integrations with logging or debugging practices that capture patient data in application logs are a common and underappreciated breach risk.

Accountability and governance

UK GDPR requires controllers to be able to demonstrate compliance — not just comply passively. Key accountability artefacts:

• Records of Processing Activities (ROPA): A documented inventory of all processing activities. Required for organisations with 250+ employees or where processing carries high risk. Health IT vendors processing health data should maintain a ROPA regardless of size.
• Data Protection Officer (DPO): Mandatory for public authorities (NHS Trusts, GP practices) and organisations whose core activities involve systematic processing of special category data at scale. Many NHS suppliers appoint a DPO voluntarily for assurance purposes.
• Lawful basis documentation: For each processing activity, the lawful basis and the special category condition must be documented and available for ICO inspection.
• Privacy by design: Systems must be designed to minimise data collection, pseudonymise where possible, and enforce access controls by default — not retrofit these as afterthoughts.

ICO enforcement

The ICO (Information Commissioner’s Office) enforces UK GDPR. Penalty tiers:

Tier	Maximum penalty
Lower tier	£8.7m or 2% of global annual turnover (higher applies)
Upper tier	£17.5m or 4% of global annual turnover (higher applies)

Health data breaches, failures to complete DPIAs, inadequate processor contracts, and unlawful international transfers are all active ICO enforcement areas. NHS Trusts have received significant fines; vendors can be investigated directly or jointly with the controller. ICO investigations are triggered by complaints, mandatory breach reports, and proactive audits of high-risk sectors.

Comparison with HIPAA

Dimension	UK GDPR / DPA 2018	HIPAA
Who is regulated	Any organisation processing UK residents’ health data	Covered entities + business associates
Legal model	Controller / processor	Covered entity / business associate
Processing condition	Lawful basis + special category condition	Permitted purpose
Consent	One lawful basis option; not the default	Not required for treatment/payment/operations
Breach notification	72h to ICO; individuals if high risk	60 days to HHS; individuals within 60 days
Individual rights	Access, erasure, portability, rectification, restriction, objection	Access, amendment, accounting of disclosures
Penalties	Up to £17.5m / 4% global turnover	Up to $1.9m per violation category per year
International transfers	Restricted without adequacy/IDTA	HIPAA does not govern international transfers

The most important conceptual difference: HIPAA uses a defined list of covered entities and permitted purposes. UK GDPR applies to any organisation processing UK residents’ health data, with a principles-based assessment of lawfulness. There is no equivalent of HIPAA’s covered entity list — if you hold UK patient data, UK GDPR applies to you.

See also

• NHS England Digital Standards — DSPT, NHS number, supplier onboarding
• UK Core FHIR Profiles — FHIR profile conformance for NHS APIs
• HIPAA — US equivalent framework