EN IEC 81001-5-1:2022 is the harmonised standard that makes the cybersecurity obligations of MDR Annex I §17 auditable. It adds the security-specific lifecycle activities on top of the software lifecycle already defined in EN 62304, and it ties them into the EN ISO 14971 risk file. For a health software manufacturer, following EN IEC 81001-5-1 is the most direct route to presumption of conformity with Annex I §17.2 and §17.4.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • MDR Annex I §17 places cybersecurity obligations on all software that is a device or that is used in combination with one, with no explicit exemption for small startups.
  • EN IEC 81001-5-1:2022 is the harmonised standard that operationalises those obligations. It is the cybersecurity counterpart to EN 62304 for the software lifecycle.
  • The standard defines eight process areas: secure development planning, security requirements, secure architecture and design, secure implementation, security verification, secure release, problem resolution, and vulnerability management.
  • Each of those process areas maps onto one or more Annex I §17 obligations. The mapping is the backbone of the technical documentation argument.
  • MDCG 2019-16 Rev.1 is the guidance document that confirms notified bodies will expect EN IEC 81001-5-1 evidence for health software.
  • Following EN IEC 81001-5-1 does not replace EN 62304 or EN ISO 14971. It sits on top of them and integrates with both.

Why this matters

The typical health software startup arrives at the first notified body pre-submission with an EN 62304 development file, a risk file built on EN ISO 14971:2019+A11:2021, a penetration test report, and a short cybersecurity section in the technical documentation. The notified body reviewer then asks one question: "Against which standard did you build the cybersecurity activities?" If the answer is "we used OWASP and a pentest", the meeting gets longer.

Tibor has sat on both sides of this conversation. As a lead auditor for a notified body, the presence of a coherent EN IEC 81001-5-1:2022 plan changes the tone of the audit within 15 minutes. As a consultant guiding startups, he has seen the absence of one turn three-month certification timelines into nine-month certification timelines.

The standard matters because it is the bridge between an obligation that is deliberately open-ended in the MDR text and a set of auditable activities a small team can actually execute.

What MDR actually says

MDR Annex I Chapter II §17 is titled "Electronic programmable systems. Devices that incorporate electronic programmable systems and software that are devices in themselves". Four sub-points are load-bearing for cybersecurity.

§17.1. Devices incorporating electronic programmable systems shall be designed to ensure repeatability, reliability and performance. "In the event of a single fault condition, appropriate means shall be adopted to eliminate or reduce as far as possible consequent risks or impairment of performance." Security faults count as fault conditions.

§17.2. 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." This is the clause that explicitly names information security. The link to risk management points directly at the EN ISO 14971 risk file. The link to development lifecycle points directly at EN 62304 and its security-aware extension in EN IEC 81001-5-1.

§17.3. Software intended to be used in combination with mobile computing platforms shall be designed and manufactured taking into account the specific features of the mobile platform. Mobile-specific threat surfaces therefore belong in the security analysis.

§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. This is the clause that requires the minimum IT requirements document.

MDR Article 10(9) separately obliges manufacturers to establish, document, implement, maintain, keep up to date and continually improve a quality management system. The QMS must include the processes for design, product realisation, and post-market. Cybersecurity activities defined by EN IEC 81001-5-1 slot directly into that QMS under the EN ISO 13485:2016+A11:2021 framework.

MDCG 2019-16 Rev.1, "Guidance on cybersecurity for medical devices", is the European interpretation of these obligations. The guidance explicitly references EN IEC 81001-5-1 and treats it as the operational framework. It covers secure design, secure implementation, verification, validation, vulnerability management, incident response, and information sharing. Notified bodies use MDCG 2019-16 Rev.1 as their checklist.

A worked example

A startup in Vienna is building a Class IIa web-based clinical decision support tool. It is a software-only device. Deployment is SaaS. The team is seven engineers plus a part-time regulatory lead. The development file already covers EN 62304:2006+A1:2015 class B, the risk file is built against EN ISO 14971:2019+A11:2021, and the team has read MDCG 2019-11 Rev.1 for the Rule 11 classification decision.

Before the EN IEC 81001-5-1:2022 gap analysis, the team has the following cybersecurity artefacts: a threat model on a whiteboard, one internal pentest from six months ago, a page in the risk file called "cybersecurity risks", and a paragraph in the IFU about hospital network requirements.

After the gap analysis, mapped to the eight process areas of the standard, the team adds the following.

Secure development planning. A five-page security plan listing the activities, the roles, and the tooling. References EN IEC 81001-5-1 clauses 4 and 5 explicitly.

Security requirements. The existing software requirements document gains a security requirements section. Confidentiality, integrity, availability, authentication, authorisation, auditing, non-repudiation. Each requirement is traceable to a risk in the risk file and, where relevant, to a MDCG 2019-16 Rev.1 recommendation.

Secure architecture and design. The architecture document gains a trust boundary diagram and a short design rationale for each boundary. Threats that cross trust boundaries become items in the risk file under a cybersecurity tag.

Secure implementation. Secure coding standards are chosen. Static analysis tooling is pointed at the existing code. The list of findings becomes part of the software problem resolution process already defined for EN 62304.

Security verification. A security test plan maps each security requirement to a test case. Pentest findings become tests to prevent regression. This closes the loop between the old one-off pentest and the lifecycle monitoring process.

Secure release. The EN 62304 release procedure gains a security gate. No release signs off without the security verification record.

Problem resolution. The existing software problem resolution process is extended to handle security issues with escalation paths. Aligns with MDR Article 87 vigilance where applicable.

Vulnerability management. The SBOM is monitored against CVE feeds. The weekly ritual described in Tibor's cybersecurity lifecycle framework becomes the operational core.

The total additional effort for this seven-engineer startup was approximately six weeks of part-time work from two engineers and the regulatory lead. The notified body pre-submission conversation that followed was short. The reviewer's comment was "everything we need is here, please proceed".

The Subtract to Ship playbook

Felix's view from 44 startup engagements is that the most common mistake is not underbuilding the cybersecurity activities. It is failing to tie them to the existing files. Teams create a parallel "cybersecurity documentation set" that lives on its own SharePoint and drifts from the software lifecycle and the risk file within three months. By the surveillance audit, the parallel set is out of sync and the auditor finds it.

The Subtract to Ship approach folds EN IEC 81001-5-1:2022 into the files the team already maintains:

  1. Plan. Add a cybersecurity plan section to the existing software development plan. Do not create a standalone document unless the team is large enough to justify it.
  2. Requirements. Add security requirements to the existing software requirements specification. Tag them so a filter can produce the security-only view on demand.
  3. Risk file. Integrate security threats into the existing EN ISO 14971 risk file. Do not create a second risk file. This is the single most important integration decision.
  4. Architecture. Add trust boundaries and data flow annotations to the existing software architecture document.
  5. Verification. Add security test cases to the existing test plan. Run them in the same CI pipeline.
  6. Release. Add a security gate to the existing release procedure. One checkbox, linked to the verification record.
  7. Problem resolution. Extend the existing procedure with a security severity scale.
  8. SBOM and CVE monitoring. Add these as living artefacts maintained by the configuration management role already named in EN 62304.

The result is a technical documentation set that shows a notified body a single coherent story: software lifecycle, risk management, cybersecurity. Not three stories with inconsistent numbering.

Tibor's rule from the Round 2 interview, on the minimum viable state at first notified body engagement: risk management module for cybersecurity, plus basic penetration testing, plus full threat modelling against EN IEC 81001-5-1:2022 integrated with the risk file. That is the bar. Anything above it is good. Anything below it is delay.

Reality Check

  1. Can you point to the clauses of EN IEC 81001-5-1:2022 you claim compliance with, or have you claimed compliance with the whole standard without reading it?
  2. Is your security risk assessment a section of the EN ISO 14971 risk file, or a separate document with different hazard numbering?
  3. Does your software requirements specification include security requirements with traceability back to risks and forward to test cases?
  4. Does your release procedure include a security gate that has ever blocked a release?
  5. Is your SBOM generated from the same configuration item list your EN 62304 process uses?
  6. Does your minimum IT requirements document actually list the hospital IT assumptions under which the device is validated, including segmentation, TLS versions, and authentication methods?
  7. If a notified body auditor asked "show me the evidence for clause 5.7 of EN IEC 81001-5-1", would you know where to click?
  8. Is cybersecurity part of the post-market surveillance plan under MDR Article 83, or only part of the pre-market file?

If fewer than five of these answers are yes, the gap between the current state and conformity is likely four to eight weeks of focused integration work, not a ground-up rebuild.

Frequently Asked Questions

Is EN IEC 81001-5-1:2022 mandatory under MDR? No standard is mandatory under MDR in the strict legal sense. MDR allows any route to compliance with the general safety and performance requirements. In practice, EN IEC 81001-5-1:2022 is the only cybersecurity standard harmonised under MDR for health software at the lifecycle level, and notified bodies treat it as the expected route. Alternative routes exist but carry a much heavier justification burden.

Does the standard apply to hardware devices as well as software? The scope of EN IEC 81001-5-1 is health software and health IT systems. For hardware devices that include embedded software, the software portion is in scope. The non-software hardware security considerations, such as physical tamper resistance, live in EN 60601-1 and related particular standards. MDCG 2019-16 Rev.1 covers both sides.

How does EN IEC 81001-5-1 relate to EN 62304? EN 62304:2006+A1:2015 defines the software lifecycle. EN IEC 81001-5-1:2022 defines the security activities within and alongside that lifecycle. The two standards are designed to be used together. Clauses of EN IEC 81001-5-1 explicitly reference EN 62304 artefacts and extend them.

Do we need ISO 27001 on top of this? ISO 27001 is an information security management system standard for the organisation as a whole. It is not required by MDR. Some mature manufacturers implement it because their hospital customers require it as a procurement condition, or because they run SaaS backends at scale. For a startup, the Subtract to Ship recommendation is to implement EN IEC 81001-5-1 first and add ISO 27001 only if a specific customer requires it.

What is the cost of a formal EN IEC 81001-5-1 gap analysis? A gap analysis performed by an experienced consultant for a small health software startup typically runs between EUR 6,000 and EUR 18,000 depending on the scope and the quality of the existing development file. The gap analysis is not the expensive part. Closing the gaps is where the work lives, and most of it is integration into existing files rather than new work.

Is the standard expected to change soon? The 2022 edition is current. MDCG 2019-16 Rev.1 from July 2020 remains the reference guidance. Both are actively used by notified bodies in 2026. Founders should monitor the harmonised standards list for updates but do not need to wait for a new edition.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I Chapter II §17, including §17.1, §17.2, §17.3, §17.4. Article 10(9).
  2. MDCG 2019-16 Rev.1, Guidance on cybersecurity for medical devices, July 2020.
  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.
  4. EN 62304:2006+A1:2015, Medical device software. Software lifecycle processes.
  5. EN ISO 14971:2019+A11:2021, Medical devices. Application of risk management to medical devices.
  6. EN ISO 13485:2016+A11:2021, Medical devices. Quality management systems. Requirements for regulatory purposes.