What actually goes into a technical file?

In short: An MDR technical file follows Annexes II and III: device description and intended purpose, design and manufacturing information, GSPR conformity mapping, risk management file, verification and validation evidence, the clinical evaluation report, and post-market surveillance planning. For software, that includes lifecycle documentation under IEC 62304 and usability evidence.

The core components

MDR Annex II sets out the general technical documentation structure, and Annex III adds post-market surveillance documentation on top. In practice, a complete file has several distinct workstreams that need to come together: a clear device description and intended purpose statement (the anchor everything else is measured against), design and manufacturing information, a General Safety and Performance Requirements checklist mapping each applicable requirement to the standard applied and the evidence proving conformity, a risk management file built to ISO 14971:2019, verification and validation evidence, the clinical evaluation report, and a post-market surveillance plan. Alongside the file itself, the wider submission set also includes your Declaration of Conformity (Annex IV) and UDI assignment.

What software adds on top

For standalone software specifically, the technical file also needs lifecycle documentation aligned to IEC 62304:2006+A1:2015 (software development and maintenance processes, scaled to your software's safety classification), cybersecurity documentation, and usability evidence under IEC 62366-1:2015 if human-factors risk is relevant to your device. These aren't optional extras layered on a generic file — a Notified Body reviewing software expects to see them integrated with the rest of the documentation, not bolted on separately.

Why the GSPR checklist functions as the spine

Of everything in the file, the GSPR checklist is worth building early and treating as the index: it's the document a Notified Body reviews against most directly, and gaps in it — a requirement with no mapped standard, or a standard with no cited evidence — are among the most common sources of findings. Building the checklist first, then working outward to the supporting evidence each row requires, is a more efficient sequence than writing the supporting sections first and reconciling them against the checklist afterward.

Where next: Building an MDR Technical File and CER · What is a clinical evaluation report (CER)?

Talk to us about building your technical file. Book an expert conversation →