---
title: GDPR and Medical Devices: Data Protection for MedTech Startups
description: GDPR medical devices data protection is not a parallel workstream. It belongs inside the cybersecurity risk file and the MDR Annex I §17 documentation.
authors: Tibor Zechmeister, Felix Lenhard
category: Cybersecurity & Data Protection
primary_keyword: GDPR medical devices data protection
canonical_url: https://zechmeister-solutions.com/en/blog/gdpr-medical-devices-data-protection
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# GDPR and Medical Devices: Data Protection for MedTech Startups

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **GDPR medical devices data protection is not a parallel legal workstream sitting next to MDR. When a device processes or stores personal data, GDPR applies to the same bytes that MDR Annex I §17 already regulates for cybersecurity. The fix is to acknowledge GDPR inside the privacy policy, inside the cybersecurity risk file, and inside the assets the device is designed to protect.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- GDPR applies whenever a medical device processes or stores personally identifiable information, which covers almost every connected device, wearable, companion app, and cloud-backed SaMD on the market today.
- In Tibor's audit experience, the most common failure is not legal complexity. It is that manufacturers simply forget GDPR applies and never reflect it in their privacy policy or in the assets listed in the cybersecurity risk file.
- MDR Annex I Section 17.2 requires software to be developed with risk management including information security. Personal data is one of the assets that information security protects.
- The practical bridge between GDPR and MDR lives in three artefacts: the privacy policy the user sees, the list of protected assets inside the EN IEC 81001-5-1:2022 threat model, and the risks those assets contribute to the ISO 14971 risk file.
- GDPR articles referenced below are flagged as [MDR VERIFY] because the authoritative source for this blog is the MDR consolidated text, not Regulation (EU) 2016/679. Legal counsel should confirm every GDPR article citation before publication or reliance.
- Startups who treat GDPR as a checkbox added after CE marking consistently end up with a change control, not a clean launch.

## Why this matters (Hook)

A telemedicine startup ships a Class IIa companion app that receives heart rate data from a wearable, stores it in a European cloud region, and displays it to a cardiologist. The submission to the notified body includes a full EN IEC 81001-5-1:2022 threat model, a clean SBOM, and pen test results. The NB approves. Six weeks later, a supervisory authority asks the startup for a copy of its privacy policy and its records of processing. The founders realise that the privacy policy on the marketing website is a generic template from the pre-device era. It says nothing about clinical data, nothing about the cardiologist as a third-party viewer, nothing about data retention when a patient cancels the subscription.

No device was unsafe. No patient was harmed. But the gap between "we have cybersecurity covered" and "we have acknowledged that GDPR applies to the same data" is exactly the gap Tibor has watched manufacturers fall into again and again.

The fix is not a new legal team. The fix is awareness during design. When a device is scoped, every byte of personally identifiable information the device will touch becomes an asset that needs protection under MDR cybersecurity requirements and also needs a lawful basis under GDPR. Those two obligations overlap almost completely at the technical level. They diverge only in the paperwork.

## What MDR actually says (Surface)

MDR does not reference GDPR by name. It does not have to. The Annex I essential requirements already cover the technical obligations a manufacturer has toward any data the device handles, personal or otherwise.

**Annex I Section 17.2.** For devices that incorporate software or for software that are devices in themselves, the software shall be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation.

**Annex I Section 17.4.** Manufacturers shall set out minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorised access, necessary to run the software as intended.

The phrase "risk management, including information security" is the hook GDPR hangs on. If personal data is present, information security must protect it. EN IEC 81001-5-1:2022, the health software security lifecycle standard referenced under MDR, formalises this by asking manufacturers to list the assets the device is responsible for. Personal data is an asset. Clinical data is an asset with heightened sensitivity. Both belong in the asset inventory that the threat model iterates over.

MDCG 2019-16 Rev.1 reinforces the point from the guidance side. It expects manufacturers to align their cybersecurity documentation with EN IEC 81001-5-1 and to integrate cybersecurity risk into the ISO 14971 risk file. Personal data confidentiality is a recognised cybersecurity property alongside integrity and availability.

**On the GDPR side** , the relevant obligations are that a controller must identify a lawful basis for processing, must implement appropriate technical and organisational measures, must be transparent about the processing through privacy information to the data subject, and must be able to demonstrate compliance on request. These obligations track the MDR cybersecurity obligations closely, but they live in a different regulation with a different enforcement authority. A notified body will not enforce GDPR. A national data protection authority will.

## A worked example (Test)

Consider a continuous glucose monitoring startup building a Class IIa wearable plus companion app. The device itself samples interstitial glucose every five minutes. The app uploads readings to a European cloud environment, stores them linked to a patient account, and allows the patient to share access with a physician.

The cybersecurity risk file, built to EN IEC 81001-5-1:2022, starts with an asset inventory. Without GDPR awareness, the inventory looks like this: "device firmware, Bluetooth pairing keys, glucose reading stream, companion app credentials, cloud API tokens". Each asset gets a threat model and a set of controls.

Now add GDPR awareness. The asset inventory is rewritten: "device firmware, Bluetooth pairing keys, glucose reading stream bound to a named patient account, companion app credentials, cloud API tokens, patient profile data including name and date of birth, physician sharing grants". Suddenly the threat model asks different questions. What happens if a breach exposes the patient profile? What happens if the physician sharing grant persists after the physician leaves the practice? What happens when the patient asks for deletion under their GDPR rights?

The safety risk file under EN ISO 14971:2019+A11:2021 is then updated in parallel. A confidentiality breach is not only a GDPR incident. If it leads to medical identity theft, or to a treating physician losing trust in the device and disabling it, the clinical consequence is real. That clinical consequence is what makes the risk belong in the ISO 14971 file and not only in the privacy policy.

The privacy policy then has actual content to describe: what data is collected, what legal basis is claimed, how long it is retained, who can access it, how the patient exercises their rights, and what happens on account closure. All three artefacts, the threat model, the risk file, and the privacy policy, now tell the same story about the same bytes.

## The Subtract to Ship playbook (Ship)

Felix's Subtract to Ship approach to GDPR in a MedTech startup is to refuse to let GDPR become its own silo. One asset inventory. One threat model. One risk file. One privacy policy that honestly describes what those artefacts already cover.

**Step 1. Write the asset inventory once, with personal data included from day one.** Do not draft a cybersecurity asset list and a separate "GDPR data map". They are the same list. Every asset carries three tags: does it contain personal data, does a breach of it affect patient safety, and who is the controller for it.

**Step 2. Feed the asset inventory into the EN IEC 81001-5-1:2022 threat model.** Let confidentiality, integrity, and availability each drive a pass over every asset. GDPR obligations on confidentiality and data subject rights become concrete technical controls at this step, not abstract legal requirements.

**Step 3. Feed the threat model outcomes into the EN ISO 14971:2019+A11:2021 risk file.** Every cybersecurity threat that could harm a patient becomes a hazard. Every GDPR-only threat that has no safety consequence stays in the privacy register, not the ISO 14971 file. The separation is clean and defensible.

**Step 4. Draft the privacy policy from the asset inventory, not from a template.** The privacy policy is the public face of everything already documented internally. If the internal documentation and the external policy disagree, the auditor or the data protection authority will find the gap.

**Step 5. Name a single owner for the intersection.** In a startup that one person is usually the PRRC or the head of regulatory affairs. They do not have to be a qualified data protection officer, but they have to be the single person who refuses to sign off on a release until the three artefacts are aligned.

**Step 6. Repeat the alignment at every software change.** In Tibor's experience, drift shows up fastest when one team updates the threat model for a new feature and another team forgets to update the privacy policy. The subtraction is not documentation. The subtraction is the parallel workstreams.

## Reality Check

1. Does the current asset inventory for the device explicitly list every type of personal data the device processes or stores?
2. Is the privacy policy on the public website written from the asset inventory, or is it a template from before the device was designed?
3. Does the cybersecurity risk file contain confidentiality as a property alongside integrity and availability?
4. If a supervisory authority requested the records of processing tomorrow, could the startup produce them in under 48 hours without drafting anything new?
5. Is there a single named owner responsible for keeping the privacy policy, the threat model, and the ISO 14971 risk file aligned?
6. When the last software change was released, were all three artefacts updated in the same change control?
7. Has anyone outside the engineering team read the privacy policy alongside the threat model to check that they describe the same device?

## Frequently Asked Questions

**Does GDPR apply to a medical device that never leaves the clinic and only stores data locally?**
Yes, if the local storage contains personally identifiable information. GDPR scope is not about whether data leaves a building. It is about whether personal data is processed. A locally stored patient record on a device held in a clinic is still personal data and still covered.

**Does a notified body check GDPR compliance during an MDR audit?**
No. Notified bodies enforce MDR. GDPR is enforced by national data protection authorities. What the notified body will check is whether the cybersecurity documentation under MDR Annex I §17 acknowledges personal data as a protected asset and handles it through the threat model and the risk file.

**Is a separate GDPR risk assessment required in addition to the ISO 14971 risk file?**
The two serve different purposes. The ISO 14971 file captures risk of harm to patients. A data protection impact assessment under GDPR, where required, captures risk to the rights and freedoms of the data subject. Both can draw from the same asset inventory and the same threat model, but the outputs live in separate registers.

**What is the minimum privacy policy a MedTech startup should ship with a connected device?**
One that is truthful, specific to the actual device, lists the categories of data processed, states the lawful basis claimed, names the controller, and explains how the patient exercises rights. Templates that refer only to "website cookies" are not sufficient for a medical device.

**Can a startup rely on the cloud provider's GDPR compliance and skip its own analysis?**
No. A cloud provider can be a processor. The manufacturer is still the controller for the personal data the device generates and uploads. Controller obligations cannot be outsourced.

**Is penetration testing required by GDPR or by MDR?**
Penetration testing is not named in either regulation as a mandatory activity, but it is named in MDCG 2019-16 Rev.1 as evidence the notified body will accept. In Tibor's experience, pentest results are rarely wasted money and also serve as evidence toward the GDPR technical measures obligation.

## Related reading
- [Cybersecurity Risk Management for Medical Devices Under MDR](/blog/cybersecurity-risk-management-mdr) on how EN IEC 81001-5-1:2022 integrates cybersecurity into the ISO 14971 risk file.
- [Health Data Under GDPR: Special Category Data Processing](/blog/health-data-gdpr-special-category) on the higher bar that applies when the personal data is clinical.
- [Data Protection Impact Assessment (DPIA) for Medical Devices](/blog/dpia-medical-devices) on when a DPIA is required and how to integrate it with the cybersecurity risk assessment.
- [SBOM for Medical Devices Under MDR](/blog/sbom-medical-devices-mdr) on keeping the configuration item list ready for post-market vulnerability response.

## Sources
1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I Sections 17.2, 17.4.
2. EN IEC 81001-5-1:2022, Health software and health IT systems safety, effectiveness and security, Part 5-1: Security, activities in the product life cycle.
3. MDCG 2019-16 Rev.1 (July 2020), Guidance on Cybersecurity for medical devices.
4. EN ISO 14971:2019+A11:2021, Medical devices, Application of risk management to medical devices.
5. [MDR VERIFY] Regulation (EU) 2016/679 (General Data Protection Regulation), consolidated text. Specific article references in this post are flagged for qualified legal review.

---

*This post is part of the [Cybersecurity & Data Protection](https://zechmeister-solutions.com/en/blog/category/cybersecurity) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*