Software as a medical device (SaMD) has to meet the same technical documentation obligations as any other device under Regulation (EU) 2017/745, and Annexes I, II and III in specific, and where AI is embedded, potentially Annex IV of the AI Act (EU) 2024/1689. What changes is the emphasis. A SaMD technical file passes or fails on how well it demonstrates the software development lifecycle, verification and validation, and cybersecurity documentation, and how clearly those link back to risk management and clinical evidence.
This checklist walks through the areas a Notified Body will expect to see, with reference to where each obligation sits in the regulation. It is a practical starting point, not a substitute for reading the applicable provisions against your specific device and intended purpose.
Where the requirement comes from
Under Article 10(4) of Regulation (EU) 2017/745, manufacturers of devices other than custom-made devices must draw up and keep up to date technical documentation that allows the conformity of the device to be assessed. The elements of that documentation are set out in Annex II (technical documentation) and Annex III (technical documentation on post-market surveillance).
Annex II asks for the documentation to be presented in a clear, organised, readily searchable and unambiguous form. For SaMD this is worth taking seriously, because software files tend to accumulate reports across many iterations. The checklist below follows the structure of Annex II.
1. Device description and specification
This is section 1 of Annex II. For SaMD, it should establish, at minimum:
- The intended purpose, and the medical conditions the software is intended to diagnose, prevent, monitor, predict, prognose, treat or alleviate.
- The intended user, intended patient population, and the clinical or care setting.
- The functional description of the software, its inputs and outputs, and the algorithms or processing methods at a level that supports the rest of the file.
- The risk class and the classification rationale, including if and how Rule 11 was applied.
- Hardware, operating systems and IT environment the software is intended to run in.
Reference to previous and, where relevant, similar generations of the device.
Whether a piece of software qualifies as a medical device, and how it classifies, depends on its intended purpose. The Medical Device Coordination Group guidance MDCG 2019-11 (latest revision) on the qualification and classification of software provides decision logic for this and is the reference most Notified Bodies expect to see reflected in the classification rationale. Additional considerations may be located in the Borderline Classification Manual (latest version) published by the European Commission.
2. Information supplied by the manufacturer
Section 2 of Annex II covers labelling and instructions for use. For SaMD, pay attention to:
- The instructions for use, including residual risks, contraindications, and any warnings.
- Minimum IT requirements and the intended operating environment.
- Cybersecurity information for the user, including the security measures the operator is responsible for, also considering implications of the GDPR 2016/679. This links to the information requirement in Annex I GSPR 23.4.
In addition, manufacturers will need to consider the implications of the e-IFU regulations (EU) 2021/2226, and the amendments set out in (EU) 2025/1234. In addition, the ISO 15223-1 and ISO 20417 provide further support in setting up the labeling materials. IEC 82304-1 and IEC 81001-5-1 should further be reviewed regarding their implications on the IFU.
3. Design and manufacturing information
Section 3 asks you to describe how the device was designed and, for software, how it was developed. For SaMD, this is where the software development lifecycle documentation belongs. IEC 62304 is the standard commonly used to structure software lifecycle processes and is a reasonable basis for demonstrating a state-of-the-art development approach. The file should let a reviewer follow the development process rather than just see its outputs.
For AI-enabled medical devices, manufacturers will want to review the implications of the NB-MED Notified Body Questionnaire and implications set out in data management standards, such as the IEC PAS 63621 and the ISO/IEC 5259 standard series.
4. General safety and performance requirements
Section 4 of Annex II is the GSPR mapping. Annex I of the MDR sets out the general safety and performance requirements, and the manufacturer must document how each applicable requirement is met, or justify why it does not apply.
For software, the specific requirement is GSPR 17.2 in Annex I. It states that software that is a device in itself, or that is incorporated into a device, shall be developed and manufactured in accordance with the state of the art, taking into account the principles of the development lifecycle, risk management including information security, and verification and validation. Section 17 also carries the cybersecurity obligations, and Section 23 covers the information supplied with the device. Each applicable GSPR should point to the specific document and location holding the evidence, not to a general statement.
When demonstrating compliance with requirements, Notified Bodies typically also expect reflecting how standards were applied to demonstrate compliance, and MDCG guidelines (including the former MEDDEV 2.7/1 Rev 4 regarding clinical evaluation).
5. Benefit-risk analysis and risk management
Section 5 covers the benefit-risk analysis referred to in Annex I Sections 1 and 8, and the risk management referred to in Annex I Section 3. ISO 14971 is the standard generally applied to the risk management process. For SaMD, the file should show:
- A risk management plan and risk management report.
- Hazard analysis covering software-specific hazards, including foreseeable misuse.
- A benefit-risk determination consistent with the clinical evidence.
- Traceability between identified risks, risk controls, and the verification that those controls work.
Information security risk should be integrated with, not separated from, device safety risk. Where security risk management is performed to a dedicated standard, e.g. IEC 81001-5-1, it should connect back to the ISO 14971 process rather than sit alongside it.
For AI-enabled medical devices, the application of ISO TR 2497-2 may be considered to support the application of risk management requirements to Artificial Intelligence techniques.
6. Product verification and validation
Section 6 of Annex II asks for the results and critical analyses of all verification and validation tests and studies undertaken to demonstrate conformity. For SaMD this is one of the most heavily scrutinised parts of the file. Expect to document:
- Software verification and validation describing the design and development process, and evidence of software validation as used in the finished device.
- Summary results of verification, validation and testing performed in-house and in a simulated or actual use environment prior to release.
- Coverage of the different hardware configurations and operating systems identified in the information supplied by the manufacturer.
Section 6 also contains the clinical evaluation and usability verification and validation through formative and summative testing. The clinical evaluation must be conducted in accordance with Article 61 and Annex XIV, and a post-market clinical follow-up plan forms part of the same annex. For SaMD, clinical evidence should address the clinical association, analytical performance, and clinical performance of the software as relevant to its intended purpose. For usability processes, the IEC 62366-1 should be consulted and applied.
Cybersecurity
Cybersecurity is not a separate section of Annex II. It runs through the GSPRs (Section 17 on electronic programmable systems and Section 23.4 on the information supplied), through risk management, and through verification and validation. IEC 81001-5-1 addresses the secure software development lifecycle for health software and is widely used to demonstrate the state of the art in this area. The MDCG 2019-16 guidance on cybersecurity for medical devices sets out pre-market and post-market expectations and serves as a useful reference for building this content.
A common finding is a technical file that addresses software cybersecurity with a single line referencing a lifecycle standard, without evidence of testing (for example, through penetration testing) or corresponding content in the instructions for use. It is worth checking that the cybersecurity story is consistent across risk management, verification and validation, and labelling.
Post-market documentation
Annex III sets out the technical documentation on post-market surveillance, including the post-market surveillance plan. This is a separate obligation from Annex II and needs to be in place at submission, not added afterwards.
A note on scope and timing
Requirements and their applicability depend on the device, its intended purpose, its classification, and the applicable version of the standards. The state of the art also moves, particularly for cybersecurity, so a file that references superseded standards may need a documented gap assessment. Where the position is evolving or depends on your specific circumstances, the applicable provisions should be assessed against the device rather than assumed.
If your team is preparing a SaMD technical file for MDR and wants a second view on classification, the GSPR mapping, or the software and cybersecurity evidence, our team is happy to discuss the approach.
We are part of a SaMD meetup group on LinkedIn for people working on software and AI-enabled medical devices. If you want to swap notes on MDR submissions and technical documentation, come and join us.
