The technical documentation is the deliverable that makes your conformity tangible: it is the first thing a notified body opens, and much of the audit turns on how consistent it is. For medical device software (SaMD), it is often underestimated — treated as an end-of-project formality rather than as the documentary backbone of the product. Here is what Annex II of the MDR actually expects, and how to organise it for software.
What is the technical documentation under Annexes II and III of the MDR?
Definition: the technical documentation is the structured set of documents through which the manufacturer demonstrates that the device conforms to the general safety and performance requirements (Annex I of the MDR). Annex II describes the content of that documentation; Annex III completes it on the post-market surveillance side.
Two things to keep in mind. First, it is not a single document but a dossier: a coherent whole where every claim points to evidence. Second, it is living: it evolves with the product and must stay current for as long as the device is on the market.
What structure for medical device software?
Annex II sets the headings; it is up to you to instantiate them for software. The main blocks:
- Description and intended purpose: what the software does, for whom, in which clinical context — the intended use, worded precisely and consistent with your communication.
- General safety and performance requirements (GSPR): the Annex I checklist, each requirement marked applicable/not applicable, with a pointer to the evidence.
- Design and development: the software life cycle in the sense of IEC 62304 — architecture, requirements, units, integration, SOUP management.
- Risk management: the ISO 14971 file, tied to the software’s real functions (not a generic table).
- Verification and validation: test plans and reports, requirements → tests traceability.
- Clinical evaluation: the demonstration of clinical benefit and of the claimed performance.
- Cybersecurity: requirements 17.2 and 17.4 of Annex I, addressed in practice via IEC 81001-5-1.
- Post-market surveillance (Annex III): the PMS plan and, where applicable, PMCF.
The thread an auditor’s eye follows: traceability.
| MDR requirement | Expected software artifact |
|---|---|
| Intended purpose / intended use | Device description, claims, context of use |
| GSPR (Annex I) | Completed GSPR checklist with pointers |
| Design (IEC 62304) | Architecture, software requirements, development plan |
| Risk management | ISO 14971 file, control measures tied to the code |
| Verification | Test reports, requirements ↔ tests traceability matrix |
| Cybersecurity | Threat analysis, SBOM, vulnerability management plan |
| Surveillance (Annex III) | PMS plan, PMCF if applicable |
The mistakes that stall an audit
They are almost never gaping holes, but rather inconsistencies the auditor unravels:
- A vague intended use, or one inconsistent with the marketing. If your website sells “diagnostic support” while the file claims a mere visualisation tool, the contradiction costs you.
- Missing traceability: requirements that do not flow down to the code and the tests, or tests that trace back to no requirement.
- Risk management disconnected from the real software: a generic ISO 14971 table, unrelated to the functions and failures actually possible.
- Cybersecurity handled as an afterthought rather than by design: no threat analysis, no SBOM, no vulnerability management plan.
- A file detached from the quality system: the technical documentation proves the conformity of one device; it must rest on an ISO 13485 QMS that describes how you work.
A good technical file is not written at the end: it is generated as development proceeds. What is traced along the way cannot be reconstructed under audit pressure.
How long does it take to compile?
Count in quarters, not weeks — and the duration depends mostly on your starting point. Three factors weigh in: the device class (the level of scrutiny rises with the class), the maturity of your QMS, and the documentary debt accumulated (existing code without traceability is the most expensive case to catch up on). The lever that changes everything: build the file during development rather than after, generating artifacts from your engineering tools.
FAQ
Is a notified body required for every class?
No. For self-declared Class I, the manufacturer draws up its own declaration of conformity without a notified body (special cases — sterile Class I, with a measuring function, reusable — are exceptions). From Class IIa onward, a notified body becomes mandatory. And under MDR Rule 11, most SaMD are at least Class IIa.
Can documentation generated by CI/CD be reused?
Yes, and it is in fact the right approach. Traceability, test reports, SBOM and release logs produced by your pipeline can feed the IEC 62304 artifacts of the file directly — provided they are structured for that purpose.
Technical documentation vs. ISO 13485 QMS: what is the difference?
The QMS describes how you design and maintain your devices (your processes). The technical documentation gathers the conformity evidence for one given device. They are distinct but inseparable: a solid file rests on processes that naturally produce its evidence.
Need a technical file scoped or audited? Book a call — together we map the next three risks to address.
Références & normes citées
- Regulation (EU) 2017/745 (MDR), Annexes II and III — technical documentation
- MDCG 2019-11 rev.1 — Qualification and Classification of Software
- IEC 62304:2006+A1:2015 — Medical device software — Software life cycle processes
- ISO 14971:2019 — Application of risk management to medical devices
- ISO 13485:2016 — Medical devices — Quality management systems