Software Lifecycle and Cybersecurity Evidence under MDR Annex I Section 17

Software and cybersecurity evidence has become one of the decisive factors in EU MDR technical file review. This article explains the requirements of Annex I Chapter II Section 17, how software safety classes drive the lifecycle documentation, and how version changes interact with notified body obligations.

1. Key takeaways

Section 17 of Chapter II of Annex I sets specific requirements for devices that incorporate electronic programmable systems and software or that are software themselves. Software must be developed according to the state of the art, taking into account the principles of the development lifecycle, risk management, verification and validation. For software, the manufacturer must additionally specify the minimum hardware requirements, IT network characteristics and IT security measures, including measures to prevent unauthorised access, needed to run the software.

Cybersecurity is therefore not an optional enhancement but a verifiable line in the GSPR compliance matrix. At the same time, the definition of a serious incident in Article 2(65) turns on clinical consequences, which means a cyberattack that causes a device to stop delivering therapy falls within the scope of vigilance reporting. The evidence burden is layered by software safety class under IEC 62304, determined in combination with the Rule 11 classification under Annex VIII and the risk analysis conclusions.

In practice, the documentation set for software under the MDR should be planned as a package rather than assembled document by document: the software development plan, the risk management file for software, the verification and validation records, the cybersecurity demonstration and the release notes each reference one another. Assembling the package at design stage prevents the most common review delay, which is evidence existing but not being reachable from the GSPR matrix.

2. Legal basis

The table below lists the provisions and standards cited in this article.

The standards listed are consensus standards referenced as methods of demonstration; the binding obligations remain those of Annex I, and the software documentation must state explicitly where each standard is used to satisfy which requirement.

3. Expert insights

Insight one: the MDR writes cybersecurity into the general safety and performance requirements.

Section 17 of Annex I requires manufacturers to specify the minimum hardware, IT network characteristics and IT security measures needed to run the software, including measures to prevent unauthorised access. Cybersecurity is consequently a verifiable item in the GSPR compliance matrix, with evidence expected against each element. In parallel, the definition of a serious incident in Article 2(65) is framed around clinical consequences, so a cyberattack that causes a device to halt treatment enters the vigilance reporting regime rather than remaining an IT matter.

Insight two: the software lifecycle evidence burden is layered by safety class.

IEC 62304 assigns safety classes A, B and C according to the possible harm to patients, users or other people, and different classes carry different lifecycle activities and documentation requirements. The technical documentation must state the software safety class determination for the product and the basis for it, established by combining the Rule 11 classification outcome with the risk analysis conclusions. Understating the class to reduce documentation effort is a direct audit risk, since the class determination itself must be justified.

Insight three: software version management is a focal point of change management.

Under Annex IX Chapter III, changes that may affect conformity with the GSPR or the intended purpose must be notified to the notified body. Software products iterate frequently, so manufacturers must define in advance which version changes require notification and which only require internal records, and write this decision standard into the quality management system documentation. Without such a standard, every release either triggers unnecessary notifications or risks unnotified significant changes.

Insight four: stand-alone software and embedded software follow different evidence paths.

Stand-alone software is classified under Rule 11 and undergoes conformity assessment in its own right as a device. Embedded software is assessed together with the host device, but its lifecycle and cybersecurity evidence must still be documented separately in the file. Device manufacturers must in addition be able to trace the lifecycle evidence of software components they procure from third parties, which makes supplier documentation obligations part of the technical file rather than an external matter.

For procured software components, the traceability duty also affects supplier agreements: the device manufacturer must be able to obtain lifecycle evidence, including verification records and known vulnerability handling, from the component supplier. Where a supplier cannot provide such evidence, the gap must be documented and mitigated in the manufacturer’s own risk management, because the notified body will hold the device manufacturer accountable for the assembled product.

4. Practical recommendations

1. Organise the software lifecycle documentation according to IEC 62304, stating the safety class determination and its basis, and mark the standard as a consensus standard in the documentation.
2. Issue the cybersecurity demonstration as a standalone document covering threat modelling, access control, logging, patching and vulnerability response.
3. Record in the technical documentation the minimum hardware, IT network characteristics and IT security requirements needed to run the software.
4. Establish a decision standard for software version changes and confirm it with the notified body, so the notification duty is predictable for every release.
5. Integrate the reporting path for cybersecurity incidents into the vigilance process of Article 87, with defined timelines and responsible roles.

5. Verification checklist

• □ Software lifecycle documentation is organised by safety class (IEC 62304, consensus standard)
• □ The cybersecurity demonstration exists as a standalone document
• □ Minimum hardware, IT network and IT security requirements are written into the technical documentation
• □ The decision standard for software version changes has been confirmed with the notified body
• □ Cybersecurity incidents are integrated into the Article 87 vigilance reporting process
• □ Stand-alone software has been classified under Rule 11

Regulatory information verified as of 2026-10-29.

GRZAN supports medical device manufacturers entering and maintaining the EU market under Regulation (EU) 2017/745. Our team prepares software lifecycle and cybersecurity documentation against MDR Annex I Section 17, aligns it with IEC 62304, and structures version-change notification standards with notified bodies. For technical file and conformity support for the EU MDR market, contact info@grzanglobal.com.