Most technical files don't fail because the device is unsafe. They fail because the file cannot prove the device is safe — in the structure, language, and traceability the notified body expects. Here is the checklist we use when auditing a file before submission.
What the file must contain (Annex II & III)
EU MDR Annexes II and III define the required content. In practice, notified bodies expect these blocks, clearly separated and individually complete:
- Device description and specification — intended purpose, variants and accessories, classification rationale under Annex VIII, and the Basic UDI-DI. The most common gap: a classification rationale that asserts a class without walking the rules.
- Information supplied by the manufacturer — labels and IFU in the languages of every target member state, aligned with the claims in your clinical evaluation. Claims drift between IFU and CER is a classic finding.
- Design and manufacturing information — design stages, subcontractors and critical suppliers, and manufacturing process descriptions with enough depth that an auditor can follow the product through the plant.
- General Safety and Performance Requirements (GSPR) checklist — every applicable requirement mapped to the standard applied, the evidence document, and its location. This is the spine of the whole file; more on it below.
- Benefit-risk analysis and risk management — the ISO 14971 risk management file, consistent with the clinical evaluation and usability engineering file. Reviewers cross-check these three; misalignment between them is the single most frequent cause of questions.
- Verification and validation — bench testing, biocompatibility, software verification (IEC 62304), electrical safety and EMC where applicable, sterilization validation, shelf-life, and the clinical evaluation report per Article 61 and MEDDEV 2.7/1 rev 4.
- Post-market surveillance (Annex III) — the PMS plan, PMCF plan (or justification for its absence), and PSUR cadence appropriate to the device class. Under MDR this is not an appendix — it is a living section a reviewer expects to see maintained.
The traceability thread
A reviewer's favorite test is to pick one requirement and pull the thread: a GSPR line → the harmonized standard claimed → the test report that proves it → the risk file entry it controls → the IFU statement it produces. If that walk breaks anywhere, the file earns a question — and questions compound into deficiency letters.
Before submission, run the thread test yourself on five requirements chosen at random. If any walk takes longer than two minutes, a reviewer will feel it too.
The five gaps we find most often
- GSPR checklists that cite standards, not evidence. "EN 60601-1" is a claim; "Report TR-114, §5.2, pass" is evidence.
- Clinical evaluations resting on equivalence that MDR no longer supports — equivalence claims need access to the equivalent device's technical documentation, which competitors rarely grant.
- Software documentation thin on lifecycle evidence — a version list is not an IEC 62304 file.
- Orphaned risk controls — controls listed in the risk file with no verification evidence anywhere in the V&V section.
- PMS sections written once and never updated — a 2023-dated PMS plan in a 2026 submission tells the reviewer the system isn't alive.
A note on file structure
MDR does not mandate a folder structure, but notified bodies publish submission guidance — and mirroring your notified body's preferred structure measurably shortens review. If you haven't been assigned one yet, structure the file by the Annex II headings above; every reviewer can navigate that.
When to get help
If your deadline is inside twelve months and any of the five gaps above sound familiar, a structured gap assessment is worth more than any template. It converts anxiety into a dated list of tasks — and that is a very different project to manage.