A DPIA is a GDPR artefact, not an MDR artefact, but for most connected medical devices it becomes mandatory and it shares 80 percent of its inputs with the EN IEC 81001-5-1:2022 cybersecurity threat model and the EN ISO 14971:2019+A11:2021 risk file. Build one asset inventory and let it drive all three. All specific GDPR article numbers in this post are flagged for qualified legal review.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • A DPIA is required under GDPR when processing is likely to result in a high risk to the rights and freedoms of data subjects .
  • For most MedTech devices, processing of health data at scale, use of new technology, and systematic monitoring all push the processing into the high-risk category, which makes a DPIA mandatory in practice.
  • The DPIA should not be written in parallel with the MDR cybersecurity risk assessment. It should share the same asset inventory, the same threat model, and the same ISO 14971 hazard list. Only the final risk framing differs.
  • A DPIA that lives only in a legal file and never touches the ISO 14971 file is a DPIA that will create contradictions the moment an auditor or supervisory authority looks closely.
  • In Tibor's experience, startups who do the DPIA and the cybersecurity risk assessment together save weeks of rework and produce a more defensible submission.
  • The DPIA is also the natural place to document residual risk to data subjects that cannot be fully mitigated, which mirrors the residual risk reporting that ISO 14971 already demands for safety risks.

Why this matters (Hook)

A founder running a digital health startup is four weeks from launch. The technical file is complete, the notified body audit passed, and the cloud infrastructure has been pen tested. A hospital procurement officer asks for a copy of the DPIA before the contract can be signed. The founder's team has not written one. They have a cybersecurity risk assessment to EN IEC 81001-5-1:2022. They have a full ISO 14971 risk file. They do not have a single document labelled Data Protection Impact Assessment.

The scramble starts. Three weeks of legal help, a new document written from scratch, and the realisation halfway through that the new document mostly repeats what the cybersecurity threat model already contains. The launch slips.

This is the pattern Tibor has seen at startup after startup. The DPIA gets treated as legal paperwork, separate from the technical file. The technical file gets treated as MDR paperwork, separate from privacy. Both documents describe the same device processing the same data on the same infrastructure, and both end up referencing different asset inventories and different threat models because no one forced them together at scoping time.

The fix is not to write the DPIA earlier. The fix is to write it once, from the same inputs that already drive the cybersecurity threat model, and to accept that the output is a different register for a different reader.

What MDR actually says (Surface)

MDR does not require a DPIA. The DPIA is a GDPR obligation. What MDR does require, in Annex I Section 17.2, is that software be developed with risk management, including information security, and in Annex I Section 17.4 that manufacturers set out minimum requirements for hardware, IT networks, and IT security measures including protection against unauthorised access.

In practice, the MDR cybersecurity obligations and the GDPR DPIA obligations overlap on most of the inputs. Both need an inventory of data. Both need a threat model. Both need a set of mitigations. Both need a residual risk view. The difference is the frame: MDR frames risk as harm to the patient, GDPR frames risk as harm to the rights and freedoms of the data subject.

[MDR VERIFY] GDPR requires a DPIA before processing when the processing is likely to result in a high risk to the rights and freedoms of natural persons. It specifies certain trigger conditions, such as systematic and extensive evaluation based on automated processing, large-scale processing of special category data, or systematic monitoring of a publicly accessible area on a large scale. Supervisory authorities publish lists of processing operations for which a DPIA is always required and lists for which it is not. Member State lists vary.

[MDR VERIFY] The minimum content of a DPIA includes a systematic description of the envisaged processing, an assessment of necessity and proportionality, an assessment of the risks to the rights and freedoms of data subjects, and the measures envisaged to address those risks including safeguards, security measures, and mechanisms to demonstrate compliance.

The alignment with the MDR cybersecurity documentation is strong. The description of processing mirrors the description of the device and its data flows already documented in the technical file. The risk assessment mirrors the EN IEC 81001-5-1 threat model. The mitigations mirror the controls. Only the risk frame and the reader differ.

A worked example (Test)

Consider a SaMD startup building an AI-based triage assistant that ingests clinical notes and imaging results and produces a priority score for emergency department workflow. The processing is large-scale, involves special category health data, and uses automated decision support. All three indicators point to a mandatory DPIA.

Without integration, the startup would produce two parallel documents. The cybersecurity threat model would list assets such as "ingestion pipeline, model weights, audit log, priority score output". The DPIA drafted by an external lawyer would list assets such as "clinical note text, imaging metadata, patient identifiers, user actions". The two lists would describe the same system from two different angles and would be partially inconsistent by the time each was finalised.

With integration, one asset inventory feeds both. The inventory contains every byte the system touches, tagged by content type, by clinical sensitivity, by GDPR category, and by owner. The EN IEC 81001-5-1:2022 threat model iterates the inventory and produces a list of cybersecurity threats. Those threats are copied into the DPIA and reframed as risks to the rights and freedoms of the data subject. Mitigations are copied once, not twice.

Residual risk is reported in two places with a consistent story. The ISO 14971 risk file reports residual safety risks. The DPIA reports residual data protection risks. Both share the same hazard language because both originated from the same asset inventory.

When the hospital procurement officer asks for the DPIA, it is already written. When the notified body asks about the cybersecurity threat model, it already matches the DPIA. When the supervisory authority asks for records of processing, they reference the same inventory everyone already works from.

The Subtract to Ship playbook (Ship)

Felix's playbook for a DPIA in a MedTech startup is to refuse to let the DPIA become a separate deliverable, written at the last minute by a different person.

Step 1. Decide whether a DPIA is mandatory before the product is scoped. For most connected medical devices processing health data, the answer is yes. Document the determination and the reasoning, then stop debating it.

Step 2. Write the asset inventory once and tag it for GDPR from day one. Every asset carries tags for personal data content, special category content, safety relevance, and owner. This same inventory drives the cybersecurity threat model, the ISO 14971 risk file, and the DPIA.

Step 3. Run the threat model once under EN IEC 81001-5-1:2022. Every threat identified is a candidate for all three downstream registers. Do not re-run the threat analysis under a different name for GDPR. Reuse the output.

Step 4. Frame each threat twice, once for safety, once for data protection rights. The same confidentiality breach is a patient-trust safety hazard in the ISO 14971 file and a rights-and-freedoms risk in the DPIA. The underlying threat is one event.

Step 5. List mitigations once and reference them from both files. A single control that limits access to clinical notes satisfies both the cybersecurity obligation and the DPIA. It should not be written up twice.

Step 6. Document residual risk in both registers with consistent language. If a residual risk cannot be mitigated below the acceptance threshold, it appears in the ISO 14971 residual risk report and in the DPIA residual risk section. A divergence between the two invites findings.

Step 7. Review the DPIA at every significant change. A new feature, a new subprocessor, a new data flow, a new geographic rollout. The DPIA is not a one-off artefact any more than the cybersecurity risk assessment is.

Step 8. Name one owner for the intersection. In a startup that is usually the PRRC or the head of regulatory affairs. One person has to be accountable for keeping the three files aligned.

Reality Check

  1. Has a decision been made and documented on whether a DPIA is required for the processing activities in the product?
  2. Is there a single asset inventory that serves the DPIA, the cybersecurity threat model, and the ISO 14971 risk file?
  3. Are mitigations written once and referenced from all three files, or duplicated across them?
  4. Does the DPIA describe the same device and the same data flows that the technical file describes, in language consistent with the threat model?
  5. Are residual data protection risks reported with the same clarity as residual safety risks?
  6. Is there a named owner responsible for keeping the DPIA aligned with the technical file on every change?
  7. Was the DPIA reviewed at the last software release, or is it still in its launch-day state?
  8. Could the DPIA be handed to a hospital procurement officer today without rewriting?

Frequently Asked Questions

Is a DPIA always mandatory for a medical device that processes health data? Not strictly always, but in practice almost always. The combination of health data, new technology, and systematic processing usually pushes the processing into the high-risk category that triggers a DPIA obligation [MDR VERIFY]. Where national supervisory authority lists are available, they are the best source for a definitive answer for a specific product in a specific Member State.

Can the cybersecurity risk assessment under EN IEC 81001-5-1:2022 substitute for the DPIA? No. The DPIA is a distinct GDPR obligation with its own required content and its own reader. What the cybersecurity risk assessment can do is supply most of the inputs the DPIA needs, so that the DPIA is a short reframing document rather than a from-scratch analysis.

Who should write the DPIA in a startup that does not have a data protection officer? A qualified data protection lawyer should review it, but the drafting is usually led by the same person who owns the cybersecurity risk assessment. That person understands the system. A lawyer who has to reconstruct the system from scratch will spend billable hours that a startup does not have.

When must the DPIA be consulted on with a supervisory authority? When the residual risk after mitigation is still high, prior consultation with the supervisory authority may be required before processing begins [MDR VERIFY]. This is rare for well-engineered medical devices but is a real obligation that should be flagged if residual risk ratings do not come down after mitigation.

Does a notified body read the DPIA during an MDR audit? A notified body is not a GDPR enforcement body, so it will not audit the DPIA as such. It will notice if the cybersecurity documentation in the technical file contradicts what the DPIA says about processing. In Tibor's experience, inconsistency between the two documents generates findings, even when neither document is strictly wrong on its own.

Is a DPIA a one-time document? No. The DPIA must be kept current. A new feature, a new subprocessor, a new data flow, a new geography, or a new identified risk can all trigger a review. The same change control process that updates the technical file and the risk file should update the DPIA.

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. EN ISO 14971:2019+A11:2021, Medical devices, Application of risk management to medical devices.
  4. MDCG 2019-16 Rev.1 (July 2020), Guidance on Cybersecurity for medical devices.
  5. [MDR VERIFY] Regulation (EU) 2016/679 (General Data Protection Regulation), consolidated text. DPIA provisions and trigger criteria cited in this post are from working memory and must be verified by qualified counsel.