DPIA for Health Research: A Practical Guide
A Data Protection Impact Assessment (DPIA) for health research is the documented risk assessment that the General Data Protection Regulation (GDPR) requires under Article 35 before a project processes personal data in a way likely to create a high risk to people’s rights and freedoms. Almost every study that handles health or genetic data at scale meets that threshold, because Article 35(3)(b) names large-scale processing of special category data explicitly. A good DPIA describes the processing, tests whether it is necessary and proportionate, identifies the risks to participants, and records the measures that reduce those risks to an acceptable level.
Why DPIAs matter more now
For years many research teams treated the DPIA as a form to complete after the architecture was already chosen. That approach is getting harder to defend. The European Health Data Space regulation creates a formal regime for secondary use of health data under Article 50 and related provisions, with access through secure processing environments and oversight by health data access bodies. Supervisory authorities have also shown that they expect DPIAs to be specific to the actual data flows, not templated.
The May 2026 UK Biobank incident is the clearest recent illustration of why. Approved researchers moved data out of a centralized platform using its normal workflow. Nobody broke the access policy; the architecture simply allowed records to leave. A DPIA that assessed only whether researchers were vetted, and not whether the design made exfiltration possible, would have missed the real risk. Regulators and participants increasingly read a DPIA as evidence of how seriously a data controller has thought about architecture, not just paperwork.
When a DPIA is required
The legal test
Article 35(1) requires a DPIA where processing, “in particular using new technologies,” is likely to result in a high risk. Article 35(3) lists three cases that always qualify, including large-scale processing of special categories of data under Article 9, which covers health and genetic data. Guidance adopted by the Article 29 Working Party and endorsed by the European Data Protection Board sets out nine criteria for identifying high-risk processing and advises that meeting two or more usually means a DPIA is needed. Health research routinely meets several of them at once:
- sensitive data, such as diagnoses, genomes, and prescriptions
- data processed on a large scale, across many participants or sites
- matching or combining datasets from different sources, such as linking registry data to hospital records
- data concerning vulnerable people, including patients and children
- innovative use of technology, such as machine learning on clinical records
National supervisory authorities also publish their own lists of processing that always requires a DPIA. In the UK, the Information Commissioner’s Office (ICO) maintains such a list, and genetic data processing appears on it.
Pseudonymized data still counts
A frequent misunderstanding is that removing names takes a project out of scope. Pseudonymized data remains personal data under GDPR if the controller or anyone else can reasonably re-identify it. Only data that is truly anonymous falls outside the regulation, and genomic data in particular is very hard to anonymize. Assume the DPIA applies unless you have a documented anonymization assessment that says otherwise.
What a health research DPIA must contain
Article 35(7) sets the minimum content. In practice, a research DPIA should be organized around those four elements, each written against the real system rather than an idealized one.
| Article 35(7) element | What to document for a health study | Common weakness |
|---|---|---|
| Systematic description of the processing and its purposes | Data sources, categories of data, number of participants, every location the data is stored or processed, every copy created, recipients, retention periods, and the legal basis under Articles 6 and 9 | Data flow diagrams that stop at the platform boundary and ignore exports, downloads, and derived datasets |
| Assessment of necessity and proportionality | Why each variable is needed, why identifiable or pseudonymized data is required rather than aggregates, and how data minimization is applied | Requesting full records “in case” they are useful later |
| Assessment of risks to rights and freedoms | Likelihood and severity of re-identification, unauthorized disclosure, function creep, cross-border transfer, and loss of participant trust | Listing generic security risks without linking them to the specific data flows |
| Measures to address the risks | Technical controls, governance controls, output checking, access review, audit logging, and how each measure reduces a named risk | Controls listed without evidence that they are enforced by the system |
Two procedural requirements sit alongside the content. Article 35(2) requires the controller to seek the advice of the Data Protection Officer (DPO). Article 36 requires prior consultation with the supervisory authority if the residual risk remains high after mitigation. Article 35(11) requires review when the risk changes, which in research means new sites, new data types, new analytical methods, or new recipients.
The federated TRE angle
The single biggest factor in a health research DPIA is where the data goes. Each copy of the data is another location to secure, another retention clock to manage, and another route for disclosure. A DPIA for a centralized model has to account for the transfer from each hospital or biobank into a central store, the storage itself, researcher workspaces within it, and any downloads. Every one of those steps carries risk that needs mitigation.
A federated Trusted Research Environment (TRE) changes that picture. Analysis code is sent to each data custodian, the records are processed where they already sit, and only aggregate outputs are released after automated checking. Because data never leaves the source, whole categories of risk shrink or disappear from the assessment: there is no bulk transfer to describe, no central replica to secure, and no cross-border movement of individual-level records to justify. Our explainer on health data residency requirements covers why that matters for multi-country studies.
Lifebit’s federated TRE adds the controls a DPIA reviewer looks for. The automated airlock applies statistical disclosure control to every output before release, which gives concrete evidence for the “measures” section. Full audit logging records who ran what, against which data, and what left the environment. Role-based access and project-level isolation support the purpose limitation argument. These are system properties that can be demonstrated, which is what separates a credible DPIA from a hopeful one.
A practical DPIA workflow for research teams
- Screen early. Run the high-risk screening during protocol design, before the architecture is fixed. If two or more criteria apply, plan for a full DPIA.
- Map the real data flow. Trace every movement and every copy, including intermediate files, derived tables, model artifacts, and outputs. Include the processors and sub-processors involved.
- Justify every variable. For each field, record why it is needed. Replace identifiable fields with pseudonyms or derived values wherever the science allows.
- Score the risks. Rate likelihood and severity for re-identification, unauthorized access, inappropriate reuse, and transfer. Tie each risk to a specific step in the data flow.
- Link each control to a risk. For every high or medium risk, name the control and state how it is enforced. “Researchers sign an agreement” is weaker than “the environment blocks export of row-level data.”
- Consult and sign off. Obtain DPO advice, record the decision, and consult the supervisory authority if residual risk stays high.
- Set review triggers. Name the changes that will reopen the DPIA, such as new sites, new data categories, or new analytical tools.
A DPIA and an ethics review ask overlapping questions from different angles. Aligning them saves time, and the GDPR Article 89 research exemption is usually part of both conversations, because it governs the safeguards that allow research to rely on certain derogations.
A real-world pattern
National research programs have converged on the same design logic. The UK’s Five Safes framework, used widely by TREs, asks whether projects, people, settings, data, and outputs are safe, and it maps well onto the risk and measures sections of a DPIA. Health Data Research UK and national statistics bodies promote TREs precisely because they concentrate controls in one environment instead of relying on each researcher’s local setup. Lifebit’s deployments with custodians such as Genomics England and CanPath follow the federated version of that model, in which the custodian keeps the data within its own infrastructure and researchers bring their analysis to it. For controllers, that means the DPIA is written around a small number of well-defined data flows rather than an open-ended set of downloads.
Common pitfalls
Writing the DPIA after the build
A DPIA is meant to shape design. Completing it after the platform is procured turns it into a justification exercise and often leaves risks that could have been designed out.
Treating vetting as the main control
Researcher accreditation matters, but it does not stop an approved user from making a mistake or acting in bad faith. Architectural controls, such as preventing row-level export, carry more weight because they do not depend on behavior.
Ignoring outputs
Aggregate outputs can still disclose information about individuals, especially with small cells or rare conditions. The DPIA should describe how outputs are checked and who approves them.
Forgetting processors
Cloud providers, platform vendors, and analytics tools are processors. Each needs a contract under Article 28 and a place in the data flow diagram.
What to do next
Take your current or planned study and draw its data flow on one page, marking every place individual-level data is stored and every point where it moves. Count the copies. That single exercise usually tells you more about your DPIA risk than any template. If the count is high, consider whether a federated design would reduce it, and read Lifebit’s overview of the federated Trusted Research Environment to see how the controls fit together.
Frequently asked questions
Is a DPIA mandatory for all health research?
Not for every project, but for most. GDPR Article 35(3)(b) requires a DPIA for large-scale processing of special category data, which includes health and genetic data. Small studies may fall below the threshold, but they should still document a screening decision.
Who is responsible for completing the DPIA?
The data controller is responsible. In research that is usually the sponsoring institution or the data custodian. The controller must seek advice from its Data Protection Officer, and processors should support the assessment with information about their systems.
Does pseudonymization remove the need for a DPIA?
No. Pseudonymized data is still personal data under GDPR if re-identification is reasonably possible. Only data that has been properly anonymized falls outside the regulation, and genomic data is especially difficult to anonymize.
How does a federated TRE affect the DPIA?
It narrows the data flows the DPIA must cover. Because records are analyzed where they are held and only checked aggregates are released, there is no bulk transfer or central copy to assess, which reduces the risks associated with transfer, storage, and export.
When must the supervisory authority be consulted?
Under Article 36, the controller must consult the supervisory authority before processing begins if the DPIA shows that high risk remains after the planned mitigation measures.
How often should a research DPIA be reviewed?
Whenever the risk changes, as Article 35(11) requires. In practice that means reviewing it when new sites, data categories, recipients, or analytical methods are added, and at regular intervals during long studies.