Under the EU MDR, technical documentation is no longer a static submission pack you dust off for certification. It’s a living, interconnected system aligned to Annex II (technical documentation) and Annex III (post-market surveillance documentation) of Regulation (EU) 2017/745. Regulators are not just checking whether information exists; they are assessing how coherently it fits together across the device lifecycle.
And the pressure on reviewers is real. In the European Commission’s latest Notified Body survey data (covering MDR activity up to February 2025), Notified Bodies reported 28,489 MDR applications, 12,177 MDR certificates issued, and 5,107 applications for changes to existing MDR certificates. That volume matters. Reviewers do not have time to “hunt” for evidence scattered across folders, versions, and inconsistent narratives. Structure is no longer a nice-to-have; it directly affects review speed and outcomes.
This article explains how to structure a medical device technical file, what regulators actually expect to see under MDR, and the common mistakes that quietly cause months of avoidable rework.
Struggling with your technical documentation?
What is a medical device technical file?
A medical device technical file is the complete set of documents demonstrating that a device complies with applicable regulatory requirements throughout its lifecycle – from design and manufacture through clinical use and post-market surveillance.
Under the EU MDR, the legal backbone of the technical file sits in Annex II (core technical documentation) and Annex III (post-market surveillance documentation). Together, these annexes define not only what information must exist, but also how it must connect.
You’ll hear different terminology used – technical file, technical documentation, design dossier. Auditors don’t care which label you use. They care whether the content is complete, traceable, and logically structured.
Another common point of confusion is device-level versus family-level files. Grouping devices into families can be efficient, but it often backfires when differences in intended purpose, materials, or claims are not cleanly controlled. When families blur, reviewers lose confidence quickly.
Regardless of format, every compliant medical device technical file must be three things:
- Structured – easy to navigate, logically ordered, reviewer-friendly
- Traceable – clear links between requirements, risks, evidence, and conclusions
- Continuously maintained – not frozen at certification
Why technical file structure matters
Understanding how to structure a medical device technical file is just as important as understanding its contents.
A well-structured file reduces Notified Body review cycles, shortens clarification rounds, and prevents nonconformities caused by missing connections rather than missing documents. A badly structured file does the opposite, even if the underlying science and engineering are sound.
This matters in today’s MDR reality. MedTech Europe’s MDR/IVDR 2024 reporting highlights certification pathways that are long, resource-intensive, and frequently delayed. When submissions are unclear or internally inconsistent, every additional question adds weeks or months.
From a reviewer’s perspective, the most common pain points are depressingly consistent:
- Information is scattered across unrelated documents
- No explicit linkage between risk management, clinical evidence, and PMS
- Conflicting versions of the same story across the file
- Updates made in isolation, without ripple-effect checks
Best-practice guidance from Notified Bodies themselves increasingly emphasises clarity, indexing, and evidence mapping, not because reviewers are pedantic, but because they are overloaded.
Medical device technical file requirements
At a high level, medical device technical file requirements under the EU MDR fall into two core buckets:
- Annex II: Technical Documentation
This covers:
- Device description and specification
- Design and manufacturing information
- General Safety and Performance Requirements (GSPR) evidence
- Risk management and benefit-risk analysis
- Verification and validation (including biocompatibility, software, usability, sterilisation where relevant)
- Clinical evaluation
- Annex III: Post-Market Surveillance
This covers:
- The PMS plan
- PMS reports, PSURs, trend reporting and vigilance outputs as applicable
Depth and scrutiny scale with device class. A Class I device and a Class III implant will not be reviewed in the same way, but structural expectations apply to all classes.
One critical point manufacturers often miss: the MDR text sets the legal requirements, but MDCG guidance shapes how those requirements are interpreted in practice. Serious technical files reflect both.
Free guide: How to structure a medical device technical file
Section 1: Device description and intended purpose
Start with a clean, stable description of the device:
- Device name, variants, configurations, and UDI basics (where applicable)
- Intended purpose, indications, target users, and patient population
- Accessories, components, contraindications, and key performance claims
This section sets the scope for everything that follows. If the intended purpose here doesn’t match the IFU, labels, or clinical evaluation, the entire file becomes suspect.
Section 2: Design and manufacturing information
This section explains how the device is built and controlled:
- Design drawings, specifications, and critical characteristics
- Manufacturing overview, including special processes and validation triggers
- Critical suppliers and outsourced processes
- Change control references that show governance, not tribal knowledge
Regulators don’t need every drawing, but they do need confidence that design and manufacturing are controlled, repeatable, and traceable.
Section 3: GSPR checklist and evidence mapping
The GSPR checklist is the reviewer’s roadmap.
Each requirement must be mapped to actual evidence, not vague statements. One GSPR often links to multiple sources: standards, test reports, risk controls, clinical data, and PMS outputs.
Common failures here include:
- “Complies with ISO XYZ” with no applicability rationale
- Links to obsolete test reports
- Evidence that exists but lives somewhere else in the file with no signposting
A strong GSPR section shows reviewers you understand compliance as a system, not a box-ticking exercise.
Section 4: Risk management documentation
Risk management is the spine of the technical file.
A compliant structure includes:
- Risk management plan and file overview
- Hazard identification, risk estimation, control measures, and residual risk
- Benefit-risk conclusions
Crucially, risk must link outward:
- To design inputs and outputs
- To verification activities
- To clinical evaluation
- To PMS and vigilance feedback
If risk management feels isolated, reviewers will push hard.
Section 5: Verification and validation
This section demonstrates that the device actually performs as intended:
- Bench and performance testing, with standards and rationales
- Software validation, cybersecurity, and usability engineering, where applicable
- Biocompatibility, sterilisation, and packaging validation as relevant
Traceability matters more than volume. Reviewers want to see requirements flowing into tests and results flowing into conclusions.
Section 6: Clinical evaluation
Clinical evaluation must align tightly with the intended purpose and claims.
A robust structure includes:
- Clinical Evaluation Plan (CEP)
- Clinical Evaluation Report (CER)
- Clear data sources: investigations, literature, real-world data, PMS/PMCF
“Marketing drift” – where claims evolve faster than clinical evidence – is one of the fastest ways to invite scrutiny.
Section 7: Post-Market Surveillance and vigilance
Annex III requires PMS to be active, not theoretical.
Your file should include:
- PMS plan and applicable reports
- PMCF or equivalent clinical follow-up rationale
- Vigilance procedures and trend reporting
Most importantly, show how PMS feeds back into risk management, clinical evaluation, and IFU updates. Closed loops inspire confidence.
Common technical file mistakes and how to avoid them
Across MDR reviews, the same failures appear again and again:
- “Document dump” submissions with no hierarchy
- No master index or navigation logic
- Inconsistent terminology across documents
- Clinical or risk documents lagging behind design changes
- Weak version control that erodes reviewer trust
A structured approach prevents repeat findings, late-stage remediation, and endless Q&A cycles.
Technical file maintenance across the device lifecycle
A medical device technical file must evolve with the device.
Updates are triggered by:
- Design or manufacturing changes
- Complaint trends and CAPAs
- PMS signals
- Regulatory or standards updates
Best practice is an annual structured review, plus change-triggered updates when events occur. Devices don’t fail audits because documentation changed; they fail because documentation didn’t.
UK Angle: Technical documentation and UKCA readiness
Many manufacturers are maintaining MDR-ready technical documentation while mapping it for UK needs during the UK transition period.
UKCA guidance still expects manufacturers to retain and make available technical documentation supporting conformity assessment. For non-UK manufacturers placing devices on the GB market, UK Responsible Person considerations also apply, but only where relevant.
The practical reality: MDR-structured technical documentation is the strongest foundation for UKCA readiness.
When to get help with your technical file
External support delivers the highest return when:
- Transitioning to MDR
- Changing Notified Bodies
- Responding to major audit findings
- Scaling portfolios or adding software-heavy devices
Patient Guard supports manufacturers with:
- Technical file structuring and navigation rebuilds
- Gap assessments against Annex II and III
- Remediation and evidence mapping
- Ongoing maintenance support
Speak to an expert
Wrapping up
A compliant medical device technical file is not just one that’s complete; it is structured, traceable, and actively maintained.
Understanding medical device technical file requirements under Annex II and III, and structuring documentation accordingly, saves time, cost, and reviewer friction, especially in the overloaded MDR environment we’re in. Speak to one of Patient Guard’s experts to build or remediate your medical device technical file. Book a free consultation.
FAQ
All documentation demonstrating compliance with MDR requirements across design, risk, clinical evaluation, and post-market surveillance.
By aligning content to Annex II and III, using a clear hierarchy, and maintaining traceability across documents.
Poor structure, broken traceability, outdated documents, and inconsistent narratives.
At least annually, and whenever design, risk, clinical, or PMS changes occur.
Yes – legacy evidence must still be structured and justified against MDR expectations.
Yes. Patient Guard provides full technical documentation structuring, remediation, and maintenance support.
Patient Guards Recent Posts
IVDR Transitional Provisions: 2026 Milestones
2026 represents a significant milestone for the amended IVDR transitional provisions framework.
Cosmetics Product Information File: UK & EU Guide
If you sell cosmetics in the UK or EU, you are legally required to maintain a Cosmetics Product Information File – even if you’re a tiny indie brand mixing batches between client emails.
ISO 15223-1:2025: Your labels may be non-compliant
ISO 15223-1:2025 is the kind of update that looks “small” on paper and then detonates in an audit because it’s printed on every box you ship.
