---
title: How to Write a Cybersecurity Risk Assessment for Your Medical Device
description: A cybersecurity risk assessment that lives inside the EN ISO 14971 risk file. Threat, asset, vulnerability flow and the minimum viable template for MDR.
authors: Tibor Zechmeister, Felix Lenhard
category: Electrical Safety & Systems Engineering
primary_keyword: cybersecurity risk assessment medical device MDR
canonical_url: https://zechmeister-solutions.com/en/blog/cybersecurity-risk-assessment-medical-device
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# How to Write a Cybersecurity Risk Assessment for Your Medical Device

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

> **A cybersecurity risk assessment for a medical device is not a separate document. It is a chapter of the EN ISO 14971:2019+A11:2021 risk file, built from a threat / asset / vulnerability flow, with the same severity and probability scales as the rest of the risk file. Tibor's minimum viable cybersecurity at first notified body engagement is a risk management module for security plus basic penetration testing, integrated with the existing risk file. Nothing fancier is required to start.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- The cybersecurity risk assessment lives inside the EN ISO 14971 risk file, not in a parallel document.
- The working unit of the assessment is the triple: asset, threat, vulnerability. Each triple becomes one or more hazardous situations in the risk file.
- Severity uses the same scale as the rest of the risk file, because the patient harm is the same kind of harm whether caused by a mechanical failure or a security exploit.
- Probability for cybersecurity hazards must be qualitative and conservative. Historical frequency rarely applies.
- Controls follow the same EN ISO 14971 hierarchy: inherent safety by design first, protective measures second, information for safety last.
- The minimum viable cybersecurity at first notified body engagement is the integrated risk file plus a penetration test. Everything beyond that is additive.

## Why this matters

A founder in Munich told Felix she had been advised by an external consultant to produce a standalone "Cybersecurity Risk Assessment" document using a bespoke template, with its own severity scale and its own numbering. Four months later, her notified body asked how the threats in that document mapped to the hazards in her EN ISO 14971:2019+A11:2021 risk file. They did not map. The severity scales disagreed. The numbering collided. The deliverable was discarded and the work was redone inside the risk file. Four months, gone.

Tibor has watched the same failure mode appear at startups across Austria, Germany, and Switzerland. The reason the failure is so common is that cybersecurity has its own vocabulary, its own culture, and its own tooling. Security engineers want to use STRIDE or CVSS. Risk engineers want to use ISO 14971. When nobody owns the integration, two parallel files appear and the notified body finds both.

The integration is not hard. It is a decision that has to be made on day one.

## What MDR actually says

MDR Annex I §17.2 requires that software is developed 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". The phrase "risk management, including information security" is the key. MDR is explicit that cybersecurity is part of risk management, not a separate regime.

MDR Annex I Chapter I, general safety and performance requirements 1 through 9, set out the risk reduction obligations. GSPR 3 requires the manufacturer to establish, implement, document and maintain a risk management system throughout the entire lifecycle of the device. GSPR 4 requires the risks to be reduced as far as possible without adversely affecting the benefit-risk ratio. This is the MDR "as low as possible" principle that Tibor flagged in his Round 2 interview: it is stricter than the ALARP principle baked into ISO 14971 section 6, and it applies equally to security risks.

MDR Annex I §17.4 requires manufacturers to set out the minimum requirements concerning hardware, IT networks characteristics and IT security measures. These minimum requirements are direct outputs of the cybersecurity risk assessment, because they represent the assumptions under which residual risks were declared acceptable.

EN ISO 14971:2019+A11:2021 is the harmonised risk management standard. Its process is intentionally hazard-agnostic. A security-caused hazard is treated with the same process as a mechanical, electrical, biological, or usability-caused hazard. The standard does not need extension to handle security. It needs competent population with security content.

EN IEC 81001-5-1:2022 is the security lifecycle standard. Clause 5 on security risk management explicitly requires integration with the ISO 14971 risk management process. It does not create a parallel risk management process. It tells the manufacturer to add security risks into the existing one.

MDCG 2019-16 Rev.1 echoes the same message: the cybersecurity risk management should be integrated with the overall risk management approach of the medical device.

The regulatory position is therefore unambiguous. One risk file. Security as a chapter inside it.

## A worked example

Consider a Class IIb home dialysis monitoring app. The clinical context is serious, the connectivity is continuous, and the data is both clinical and personal. The existing risk file has roughly 140 hazards across mechanical, electrical, usability, software, and clinical categories.

The cybersecurity risk assessment begins with an asset list. Assets are what the attacker wants to reach or damage. In this case: patient dialysis telemetry, patient identity, the device's dosing configuration, the connection to the backend, the firmware update channel, and the audit log. Six assets.

For each asset, the team asks three questions. What does this asset do for the patient? What harm results if it is disclosed, modified, destroyed, or rendered unavailable? Who might attempt those actions?

The asset "dosing configuration" is an example. Unauthorised modification could cause immediate patient harm up to and including death. The threat actor profile includes external remote attackers, malicious insiders at the clinic, and compromised clinician credentials. The vulnerabilities are the authentication method on the configuration endpoint, the transport security, the audit trail, and the default configuration values.

Each asset / threat / vulnerability triple is then translated into one or more hazardous situations in the risk file, using the same template as every other hazard. The hazard column says "unauthorised modification of dosing configuration". The sequence of events column walks through the exploit path. The harm is "dialysis dose outside prescribed range, with potential for renal failure or death". Severity uses the risk file's existing scale, in this example a five-level scale where this hazard sits at the highest level. Probability is qualitative: occasional for a device in uncontrolled home deployment.

The resulting risk score is unacceptable before controls. Controls are added in the hierarchy order Tibor has described repeatedly. First, inherent safety by design: the dosing configuration endpoint is moved behind mutual TLS with device-bound certificates, and out-of-range values are rejected by firmware regardless of the authorisation state. Second, protective measures: the audit log is append-only, cryptographically signed, and streamed to a server outside the device. Third, information for safety: the minimum IT requirements document tells the customer hospital to segment the network, rotate credentials, and monitor the audit stream.

After controls, the residual risk is re-scored. It drops to acceptable, provided the customer IT assumptions hold. The assumptions themselves become inputs to the §17.4 minimum IT requirements document.

The total effort for a reasonably mature startup to build this security chapter of the risk file, starting from scratch, is two to four weeks of focused work from a small team that includes someone with real security experience. The work product is six to twelve new hazardous situations in the risk file and one new subsection in the risk management report. Not a new document.

## The Subtract to Ship playbook

Tibor's minimum viable cybersecurity framing is worth repeating in the exact shape it takes in practice. At the first notified body engagement, the bar is a risk management module for cybersecurity plus basic penetration testing, integrated with the EN ISO 14971:2019+A11:2021 risk file. That is the floor. Below it, the conversation stalls.

Felix's Subtract to Ship approach to hitting that floor is seven steps:

1. **Open the existing risk file.** Do not start a new file. Do not start a new template. Open the file that already contains the mechanical, usability, and software hazards.
2. **Add an assets section to the risk management plan.** One page, listing what the attacker wants. Six to ten assets is typical for a startup. More than fifteen usually means overlapping definitions.
3. **Walk each asset through the CIA triad.** Confidentiality, integrity, availability. Each combination of asset and CIA dimension that is not trivially safe becomes a candidate hazard.
4. **Identify vulnerabilities for each candidate.** Vulnerabilities are the concrete technical weaknesses that make the threat realisable. Missing authentication. Weak cryptography. Default credentials. Unvalidated updates.
5. **Write each triple as a hazardous situation.** Use the same columns as every other hazard in the risk file. Do not invent new columns.
6. **Apply the risk control hierarchy.** Design first, protective measures second, information for safety last. Avoid the trap Tibor calls out: skipping straight to "we'll tell the customer in the manual".
7. **Commission a penetration test against the controls.** The pentest is external evidence that the controls exist and work. It is also the most cost-effective single item a startup can buy to support the risk file.

The total output from these seven steps is an integrated risk file with a visible cybersecurity chapter, a pentest report, and a defensible minimum IT requirements document. That is enough to walk into a notified body pre-submission and hold a serious conversation. It is not enough to claim full conformity with EN IEC 81001-5-1:2022, but it is enough to start.

Felix's observation after coaching startups through this exercise: the single biggest time saving comes from refusing to invent new vocabulary. Use the words already in the risk file. Severity is severity. Probability is probability. Hazard is hazard. Do not import STRIDE categories and CVSS scores into the risk file as primary columns. Keep them as supporting annotations only.

## Reality Check

1. Does your cybersecurity risk assessment share a file with your EN ISO 14971 risk file, or does it live in a separate document?
2. Does your asset list name every kind of data or function an attacker might target?
3. Do your security-related hazards use the same severity and probability scales as the rest of the risk file?
4. Have you applied the EN ISO 14971 risk control hierarchy to the security risks, or have you defaulted to "the customer will configure the network correctly"?
5. Does your §17.4 minimum IT requirements document reflect the assumptions under which residual security risks were declared acceptable?
6. Is your pentest scoped against the controls in the risk file, or is it a generic "attack the device" engagement with no traceability?
7. If a notified body reviewer picked three random security hazards from your risk file, could you show the asset, threat, and vulnerability behind each one in under five minutes?
8. Does the cybersecurity chapter of the risk file get reviewed every time a CVE is evaluated, or does the risk file go stale between reviews?

Any "no" above is a gap worth closing before the first notified body engagement, not after.

## Frequently Asked Questions

**Do we need a threat model in addition to the risk assessment?**
The threat model is an input to the risk assessment. Some teams document it separately for clarity and some embed it in the risk management plan. Either is acceptable. What matters is that the threats and assets end up in the risk file as hazardous situations with controls, not as a disconnected diagram.

**How detailed does the asset list have to be?**
Detailed enough that a stranger reading the list can understand what the device does and what is worth protecting. Too shallow and hazards slip through. Too granular and the list becomes unmaintainable. For a small startup, six to twelve assets is a workable range.

**Can we use CVSS scores for probability?**
CVSS is a vulnerability severity metric. It is not a probability of exploitation for a specific medical device in a specific deployment. Use CVSS as supporting information for decision-making inside the vulnerability management process, not as a replacement for the risk file probability column. The risk file must use the same probability scale across all hazard types.

**Does the assessment need to be signed by a security specialist?**
MDR does not prescribe who signs the risk file. EN ISO 14971 requires competence of the people performing the risk management activities. Where security competence is relevant, it must be represented on the team. For a small startup, this often means a part-time external security consultant contributing to the team led by the regulatory lead.

**What is the difference between a cybersecurity risk assessment and a privacy impact assessment?**
The risk assessment covers patient safety. The privacy impact assessment covers GDPR obligations. They overlap on assets that are personal data. The overlap is not a duplication: the same asset appears in both documents, with different evaluation criteria. Tibor's Q6 observation from the Round 2 interview applies here: GDPR is less a conflict with MDR than an oversight, and a simple step is to ensure PII appears in both the security risk file and the privacy policy.

**How often should the cybersecurity risk assessment be revisited?**
At minimum, whenever a CVE evaluation flags a relevant vulnerability, whenever the architecture changes significantly, and on a fixed cadence of at least once per year. The vulnerability management process from EN IEC 81001-5-1:2022 triggers most of the updates. The annual review catches anything the trigger missed.

## Related reading
- [The cybersecurity lifecycle approach under MDR](/blog/cybersecurity-lifecycle-approach-mdr). Why the risk file must be updated as vulnerabilities are disclosed.
- [MDR cybersecurity conformity and IEC 81001-5-1](/blog/mdr-cybersecurity-iec-81001-5-1-conformity). The harmonised standard that ties the risk assessment into the software lifecycle.
- [Cybersecurity risk management under MDR](/blog/cybersecurity-risk-management-mdr). The foundational post on security inside the EN ISO 14971 framework.
- [The MDR risk management process under ISO 14971](/blog/mdr-risk-management-process-iso-14971). The process the cybersecurity chapter plugs into.
- [Risk management file contents](/blog/risk-management-file-contents). What the file should physically contain, with security included.

## Sources
1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I Chapter I GSPR 1-9, Annex I Chapter II §17.2 and §17.4.
2. EN ISO 14971:2019+A11:2021, Medical devices. Application of risk management to medical devices.
3. EN IEC 81001-5-1:2022, Health software and health IT systems safety, effectiveness and security. Part 5-1: Security. Activities in the product lifecycle. Clause 5, security risk management.
4. MDCG 2019-16 Rev.1, Guidance on cybersecurity for medical devices, July 2020.
5. EN 62304:2006+A1:2015, Medical device software. Software lifecycle processes.

---

*This post is part of the [Electrical Safety & Systems Engineering](https://zechmeister-solutions.com/en/blog/category/electrical-safety) 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).*