Short answer: a data protection impact assessment (DPIA) is the document in which you describe a processing operation, show that it is necessary and proportionate, assess the risks to the people whose data it uses, and record the measures that bring those risks down. Article 35 of the GDPR makes it mandatory where processing is likely to result in a high risk, and names large-scale processing of special categories, which includes health data, as a case. In practice, every health app with more than a handful of users and every health data platform needs one, before processing starts, reviewed when the processing changes. The template below follows Article 35(7) and the European guidelines; download it at the end.
When it is required
A DPIA is required under GDPR Article 35 whenever processing is likely to result in a high risk, and large-scale processing of special categories such as health data is named as an automatic trigger. Under the EDPB criteria, a health app usually meets several (sensitive data, large scale, vulnerable people), so almost every health app needs one before processing starts.
Article 35(3) lists three automatic triggers: systematic and extensive profiling with significant effects; large-scale processing of special categories (Article 9) or criminal data; systematic large-scale monitoring of public areas. The European Data Protection Board's criteria (from the former Article 29 Working Party) add six more; if two or more apply, do a DPIA: evaluation or scoring; automated decisions with legal or similar effect; systematic monitoring; sensitive data; large scale; matching or combining datasets; data about vulnerable people (patients count); innovative use of technology; preventing people from exercising a right or using a service. A health app typically hits sensitive data, large scale, vulnerable people and often innovative technology. National authorities also publish lists of processing that always requires a DPIA (Article 35(4)); most include health apps and connected devices.
The checklist
A health-app DPIA checklist follows the four elements of GDPR Article 35(7): a description of the processing (purposes, data, actors, technology), an assessment of necessity and proportionality (legal basis, minimisation, rights, processors, retention), an assessment of the risks to the people whose data is used, and the measures that address those risks, followed by consultation, sign-off and periodic review.
1. Describe the processing (Art. 35(7)(a))
- Purposes, one by one: storing the person's records; sharing with a clinic; reminders; anonymised statistics; AI features.
- Data categories per purpose, with the health data marked; sources (the person, clinics, wearables, documents); recipients; retention per category; transfers outside the EU and their mechanism.
- Actors: controller(s), processors (hosting, analytics, support tools, AI providers) with their contracts; the DPO.
- Technology: architecture, where data rests, encryption, identity, logging. A data-flow diagram is the fastest way to find what you forgot.
2. Necessity and proportionality (Art. 35(7)(b))
- Legal basis under Article 6 and the Article 9(2) exception, per purpose (GDPR Article 9 explained).
- Data minimisation: for each data element, why it is needed; what you decided not to collect.
- Information to the people (Articles 13–14) and how the rights (access, rectification, erasure, portability, objection, withdrawal of consent) are exercised in the product, not by email to support.
- Processors: Article 28 contracts in place; sub-processors listed; audit rights.
- Retention and deletion: concrete periods and the mechanism that enforces them.
3. Risks to the people (Art. 35(7)(c)) Assess likelihood and severity for each of the three classic events, for each purpose:
- Illegitimate access (breach, insider, over-broad sharing, a clinic seeing more than approved);
- Unwanted modification (wrong data in a record that a clinician relies on, synchronisation errors, an AI feature writing to the record);
- Disappearance (loss of a record the person depends on; account takeover; a vendor shutting down). Then the health-specific ones: re-identification of "anonymous" statistics; inference of conditions from behaviour; discrimination if data reaches insurers or employers; harm from children's data; location data around clinics; third-party SDKs in the app sending data to advertising networks (the most common finding in regulatory audits of health apps).
4. Measures (Art. 35(7)(d)) For each risk, the control and the residual risk: encryption at rest and in transit; strong authentication; access scoped by consent and time, with logs the person can read; pseudonymisation in analytics and in logs; no third-party advertising or tracking SDKs; separate environments and synthetic data for development; backups with tested restore; vendor review; incident response with the 72-hour clock; secure development practices; staff training and confidentiality; data export and deletion in the product; a kill-switch for integrations.
5. Consultation
- The DPO's advice is recorded (Art. 35(2)); the views of the people or their representatives are sought where appropriate (Art. 35(9)), for example through a user panel or patient association.
- If a high residual risk remains, consult the supervisory authority before processing (Art. 36). Most well-controlled health apps do not reach this point; platforms processing for many clinics sometimes do.
6. Sign-off and review
- Approved by the controller's management; dated; versioned.
- Reviewed when purposes, data, technology or recipients change, and at least every year or two (Art. 35(11)).
Typical findings in health-app DPIAs
The most common findings in health-app DPIAs are analytics and crash-reporting SDKs that receive identifiers together with health context, push notifications that reveal conditions on the lock screen, support staff with unrestricted database access, backups outside the EU, data kept after an account is closed, consent screens that bundle purposes, and "anonymised" datasets that still identify people.
Each of these has a concrete fix, and the DPIA is where the fix is committed to.
The template
The DPIA template on this page is a fillable Markdown document for a health app, structured in six sections (description of the processing, necessity and proportionality, risks to the people, measures, consultation, sign-off and review) with a risk table and a measures table. It follows GDPR Article 35(7) and the EDPB criteria and is a starting structure, not legal advice.
Download the DPIA template. It can be imported into any document tool; your DPO adapts it.
In Anpheros
Anpheros maintains a DPIA for Anpheros Daily and one for Anpheros Platform as a processor, with the structure above, and the choices they led to are visible in the product: consent per purpose, access scoped and logged, no advertising SDKs, EU hosting, export and deletion in the app. See Health transparency.
This page explains regulation for product and engineering teams. It is not legal advice; the texts linked under Sources are the authority, and your data protection officer, notified body or counsel decides for your case. Last reviewed: October 2026.
Related pages
- GDPR Article 9 for health data
- De-identification of health data
- Who viewed my medical record?
- Is a health app a medical device?
- ISO 27001 vs ISO 27799
- Health data regulation map
Sources
- GDPR Article 35 and 36, EUR-Lex
- Article 29 Working Party / EDPB: Guidelines on DPIA (WP248 rev.01)
- CNIL: PIA methodology and software
- ICO: Data protection impact assessments
- EDPB: guidelines, recommendations and best practices
Frequently asked questions
Do I need a DPIA for a small app with few users?
If it processes health data, almost always yes: sensitive data plus vulnerable people already meets the two-criteria test, and several national lists name health apps explicitly. A small app's DPIA is simply shorter.
Who writes the DPIA?
The controller is responsible; in practice the product owner and engineering lead write it with the DPO's advice, because they know the data flows. Outsourcing it entirely produces a document nobody can keep current.
Must the DPIA be published?
No. It is an internal accountability document shown to the supervisory authority on request. Many organisations publish a summary; the EHDS and some national rules require transparency about certain processing.
How is a DPIA different from a risk assessment under ISO 27001?
The ISO assessment looks at risks to the organisation; the DPIA looks at risks to the people whose data is processed. They share controls and evidence, and a good security programme feeds the DPIA's measures section.
Try it free in the sandbox
Your first FHIR call in 5 minutes. An HL7 FHIR R4 API with the patient's consent built in: try it in the sandbox, then connect your own app or clinic system.
Free · 30 synthetic patients · no card
Anpheros builds a medical record that the patient controls and can share with any clinic, on an HL7 FHIR R4 platform, based in the EU. These guides help you understand and organise your health; they do not replace your doctor.
About Anpheros →
AnpherosThe more you log, the clearer your record
Your health history in one place, under your control.
Free · Works in your browser · No card
