---
title: How to Handle a Cybersecurity Breach
description: Cybersecurity breach medical device regulatory response: detection, patient impact, MDR vigilance Articles 87 to 92, FSCA and GDPR 72-hour clock.
authors: Tibor Zechmeister, Felix Lenhard
category: Risk Management Under MDR
primary_keyword: cybersecurity breach medical device regulatory
canonical_url: https://zechmeister-solutions.com/en/blog/cybersecurity-breach-medical-device-regulatory
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# How to Handle a Cybersecurity Breach

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

> **A cybersecurity breach on a medical device triggers three parallel regulatory tracks: MDR vigilance under Articles 87 to 92 if the incident qualifies as a serious incident, a field safety corrective action if the device population is affected, and GDPR breach notification on a 72-hour clock if personal data is involved. The three tracks run at the same time and must be coordinated from minute one.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- MDR Article 87 defines the manufacturer obligation to report serious incidents to the competent authority. A cybersecurity vulnerability that has caused or could have caused a serious incident falls inside scope.
- MDR Article 89 sets the reporting timelines for serious incidents. Immediately on serious public health threat, within 10 days on death or serious deterioration, within 15 days on other serious incidents.
- MDR Article 88 covers trend reporting for non-serious incidents and expected side effects, which is where many chronic vulnerabilities live.
- A field safety corrective action under MDR Article 89 may be required if a population of devices shares the same vulnerability.
- GDPR Article 33 imposes a 72-hour notification obligation on the controller from awareness of a personal data breach, which is separate from the MDR vigilance clock and runs in parallel. 
- MDCG 2023-3 Rev.2 is the current vigilance terms and concepts Q&A and the practical anchor for classification of the incident.
- MDCG 2019-16 Rev.1 gives the cybersecurity-specific interpretation of what counts as a serious incident.

## Why this matters: a story

In Tibor's follow-up interview, the anchor story for this post came out as a pattern, not a headline. A software library used inside a medical device had a publicly exploited vulnerability. It took the manufacturer several weeks to notice. The patch eventually arrived via a software change and a change control cycle. No patient was harmed in this specific case. The window was open long enough that something could have happened.

That is the instructive part. No patient was harmed. The manufacturer kept the certification. The process still failed, and it failed at the simplest step: nobody was watching the right CVE feed on the right library. The manufacturer had a PMS plan on paper. The PMS plan did not cover the software supply chain.

Felix sees the same pattern at earlier-stage startups. The team is confident that nothing has happened. They have no mechanism that would tell them if something had.

A breach playbook does not begin on the day of the breach. It begins on the day the PMS plan is written, and it is tested long before the first CVE appears.

## What MDR actually says

**MDR Article 87** requires manufacturers to report any serious incident involving devices made available on the Union market. A serious incident is defined in Article 2(65) as an incident that led, might have led or might lead to death, serious deterioration in health or a serious public health threat.

**MDR Article 88** requires reporting of trends. Any statistically significant increase in the frequency or severity of incidents that are not serious incidents, and any expected side effects, must be reported via trend reporting.

**MDR Article 89** sets out the analysis and response obligations. On becoming aware of a serious incident, the manufacturer must, without delay, perform the necessary investigations, take any corrective action and cooperate with the competent authority. The same article governs field safety corrective actions, including field safety notices to users.

**MDR Article 92** covers the electronic system for vigilance and post-market surveillance, operated via Eudamed, through which incidents and FSCAs are recorded.

**MDR Annex I Section 17.4** is where the cybersecurity requirement is anchored, and it is the GSPR against which the breach is assessed.

The operational interpretation for cybersecurity comes from two places. **MDCG 2023-3 Rev.2** is the current Q&A on vigilance terms and concepts. **MDCG 2019-16 Rev.1** is the cybersecurity-specific guidance that confirms a cybersecurity vulnerability can qualify as a serious incident when it meets the Article 2(65) criteria.

Separately, **GDPR Article 33** obliges a data controller to notify the supervisory authority of a personal data breach without undue delay and, where feasible, not later than 72 hours after becoming aware of it, unless the breach is unlikely to result in a risk to natural persons. This clock is independent of the MDR clock. 

## A worked example: a cloud inference endpoint exposed

A Class IIa diagnostic SaMD runs inference in a cloud environment. On Tuesday at 14:00, the on-call engineer sees a spike in error rates. By 15:30, investigation shows that an authentication misconfiguration exposed the inference endpoint for approximately 6 hours earlier the same day. Logs show that 180 patient records were processed through the exposed endpoint by external callers, and that output was returned to unknown recipients. No clinician at a hospital customer acted on the exposed results, but the manufacturer cannot prove this with certainty.

The timeline from 15:30 onwards, in Tibor's playbook:

**Minute 0 to 60. Contain and preserve.** The endpoint is locked down. Logs are preserved with hashes. The incident commander is named. A shared incident channel is opened. The clock starts on all three tracks.

**Hour 1 to 4. Classify.** Does the event meet MDR Article 2(65) as a serious incident. The test is whether the exposed output could have led to a serious deterioration in health. For a diagnostic SaMD, the answer is usually yes if a clinician could have acted on a manipulated or incorrect output. Does the event involve personal data under GDPR. Yes, patient records were processed. Classification sets the parallel clocks.

**Hour 4 to 24. Notify.** Under GDPR Article 33, the 72-hour clock to the data protection authority is running. The manufacturer prepares and files the initial notification with the facts known so far, and updates it as more information becomes available. Under MDR Article 89, if the serious incident qualifies as a serious public health threat, immediate notification is required. If it qualifies as an incident that might lead to serious deterioration, the 15-day clock is running.

**Day 1 to 10. Investigate and act.** Root cause analysis. Patient impact assessment, running a list of every affected record and where it went. If the device population is affected by the same vulnerability, a field safety corrective action is required under Article 89. A field safety notice is drafted for affected users. Eudamed entries are prepared via the vigilance module.

**Day 10 to 30. Follow up and close.** Final vigilance report. FSCA completion report. PMS plan updated to prevent recurrence. Risk file updated in EN ISO 14971. Cybersecurity threat model updated. Change control initiated for the patch.

**Week 6 onwards. Notified body touchpoint.** The next surveillance audit will cover the incident end to end. The manufacturer prepares a single dossier that shows detection, classification, notification, action, closure and prevention.

This is a fully documented, fully compliant response to a breach that caused no harm. The documentation is what protects the certification.

## The Subtract to Ship playbook

**Step 1. Write the breach playbook before the breach.** A six-page document that names the incident commander, the communication channels, the classification decision tree and the notification templates. Tested by a tabletop exercise at least once a year.

**Step 2. Build the detection layer.** Monitor CVE feeds for every component in the SBOM. Monitor authentication logs. Monitor anomalous query volumes on inference endpoints. A breach you do not detect is a breach you cannot report, and "we did not know" is not a defence.

**Step 3. Classify on paper, not on instinct.** The classification decision tree asks the Article 2(65) questions explicitly. Did it lead, might it have led, might it lead to death, serious deterioration or serious public health threat. Each answer is logged. Each answer has a named decider.

**Step 4. Run the clocks in parallel, not sequentially.** The GDPR 72-hour clock and the MDR 10 or 15-day clock are independent. Do not wait for one to finish before starting the other.

**Step 5. Draft the FSCA decision as soon as population impact is plausible.** An FSCA is not the same as a recall. It is a risk-reducing action across the field population. MDR Article 89 requires it when the vulnerability affects more than the single reported device.

**Step 6. Close the loop into PMS and risk management.** A closed breach is not a closed PMS entry. The PMS plan is updated. The risk file is updated. The threat model is updated. The next notified body surveillance audit expects to see all three updates.

## Reality Check

1. Do you have a written breach playbook that names the incident commander and the backup.
2. When was your last tabletop exercise of that playbook.
3. Do you monitor CVE feeds for every component in your SBOM, and who owns that monitoring.
4. Does your classification decision tree reference MDR Article 2(65) and MDCG 2023-3 Rev.2 explicitly.
5. Do you know whether you are the data controller or the data processor for each deployment of your device.
6. Can you draft and file a GDPR Article 33 initial notification within 24 hours of detection.
7. Can you distinguish a serious incident report from a trend report under MDR Article 88 without asking a consultant.
8. Is your PMS plan the plan you would defend at a surveillance audit tomorrow, or the plan you mean to update next quarter.

## Frequently Asked Questions

**Is every cybersecurity incident a serious incident under MDR.**
No. The test is MDR Article 2(65): death, serious deterioration in health or a serious public health threat. An incident that does not meet this bar may still fall under MDR Article 88 trend reporting and under GDPR if personal data is involved.

**Do we always have to run the GDPR clock.**
Only when personal data is affected and the manufacturer or its processor is the data controller under GDPR. 

**Who files the vigilance report in Eudamed.**
The manufacturer, via the vigilance module. The authorised representative can act on behalf of non-EU manufacturers.

**Is an FSCA the same as a recall.**
No. An FSCA is any action taken to reduce a risk associated with a device in the field. A recall is one type of FSCA. A software patch with a field safety notice is another.

**Can a vulnerability with no confirmed exploit still be reportable.**
Yes. MDR Article 2(65) includes events that might have led to serious harm. MDCG 2023-3 Rev.2 clarifies this in the current vigilance Q&A.

**Does the breach have to be disclosed publicly.**
Public disclosure is triggered by FSCA obligations and by data protection law, not directly by MDR vigilance reporting to the competent authority.

## Related reading
- [MDR Articles 87 to 92 vigilance framework](/blog/mdr-articles-87-92-vigilance-framework) for the full vigilance architecture.
- [Field safety corrective actions under MDR](/blog/field-safety-corrective-actions-fscas-mdr) for the FSCA process in detail.
- [Cybersecurity risk management under MDR](/blog/cybersecurity-risk-management-mdr) for the upstream risk file integration.
- [Vigilance reporting timelines under MDR](/blog/vigilance-reporting-timelines-mdr) for the clock-by-clock reference.

## Sources
1. Regulation (EU) 2017/745 on medical devices, consolidated text. Articles 2(65), 87, 88, 89, 92; Annex I Section 17.4.
2. MDCG 2023-3 Rev.2, Questions and answers on vigilance terms and concepts, January 2025.
3. MDCG 2019-16 Rev.1, Guidance on cybersecurity for medical devices, July 2020.
4. Regulation (EU) 2016/679, General Data Protection Regulation, Article 33, personal data breach notification to the supervisory authority.
5. 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.

---

*This post is part of the [Risk Management Under MDR](https://zechmeister-solutions.com/en/blog/category/risk-management) 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).*