Technical Documentation
Technical Documentation Readiness Assessment
Harmonised Standards and How They Work in Your Technical File
Harmonised standards give you presumption of conformity — but only if you use them correctly. Here is how they work in the technical file, what the limits of presumption are, and what happens when a standard is revised or withdrawn.
Common Notified Body Findings in Technical File Reviews
The same technical documentation problems come up again and again in Notified Body reviews. Here is a plain-language rundown of the most frequent findings — and what they actually mean for your technical file.
Integrating Your Risk Management File with the Technical Documentation
Under EU MDR, risk management is not a standalone QMS process — it feeds directly into your technical file. Here is how to make the integration work in practice.
How to Structure Your Annex II Technical File
A practical walkthrough of the Annex II technical file requirements — what sections you need, what goes in each, and where most teams fall short.
Building a GSPR Traceability Matrix That Holds Up Under Scrutiny
The GSPR traceability matrix is one of the most audited sections of any technical file. Here is how to build one that actually demonstrates conformity — not just fills a table.
Design and Manufacturing Information in the Technical File
Section 2 of Annex II covers how your device is designed and made. It sounds straightforward, but this is where manufacturers with complex supply chains or multiple manufacturing sites regularly come up short. Here is what needs to be in there and why.
When Post-Market Data Requires a Technical File Update
Your technical file is not a static submission artefact — it must stay current with your post-market findings. This resource explains what triggers an update and what the update has to cover.
Labelling Requirements in Your Technical Documentation
Labelling under EU MDR is more than a packaging requirement — it is a technical file component that Notified Bodies check in detail. Here is what the requirements mean in practice and where teams regularly come up short.
The Clinical Evaluation Section of Your Technical File
Section 6 of Annex II is where clinical evidence meets technical documentation. Here is what belongs there, how it connects to the rest of the file, and why it is the most common source of major findings.
Managing Design Changes and Keeping the Technical File Current
Every design change has a documentation consequence. Here is how to assess whether a change requires a technical file update, how to manage the update itself, and what auditors look for when they check your change history.
Technical documentation is the primary artefact a manufacturer presents to demonstrate conformity. Annex II covers the full technical file — design and manufacturing information, GSPR compliance, risk management, clinical evaluation, post-market data. Annex III adds the technical documentation for post-market surveillance specifically. Getting the structure right matters, but structure alone is not enough: auditors and Notified Bodies are looking for traceability and completeness, not a well-organised folder of thin documents.
The GSPR traceability matrix is where a lot of technical files fall short. Annex I lists 23 general safety and performance requirements, and each one needs to be addressed — demonstrated by a standard, a test result, a design specification, or a documented rationale for why a requirement does not apply. Teams often treat this as a table-filling exercise rather than a genuine demonstration. A Notified Body reviewer who finds GSPRs checked off with no supporting evidence will raise a finding. The matrix is only as strong as the documents it points to.
One thing that catches manufacturers off guard is the requirement in Annex II, Section 6 to demonstrate compliance with each applicable GSPR for the specific device as manufactured — not the device as designed or intended. This means your technical documentation needs to reflect the actual production version, not a prototype. If a design changed during development, the documentation needs to reflect that change and show how the GSPR demonstration still holds. Post-approval design changes that are not tracked back to the technical file are a common audit finding.
Risk management integration is tighter under MDR than many teams expect. ISO 14971 is the harmonised standard, but the MDR requires that your risk management file directly feeds into your GSPR demonstration — the residual risks documented in ISO 14971 terms must connect to the benefit-risk assessment in Annex II. If your risk management file lives in a silo, separate from the technical documentation, you will struggle to satisfy this requirement. Teams that build their technical file and risk management file as separate processes often discover the gap only when a Notified Body points it out.
The resources in this category cover Annex II structure in detail, how to build a GSPR traceability matrix that holds up under scrutiny, how technical documentation connects to risk management and clinical evaluation, and what changes in post-market data require a technical file update. Whether you are building a technical file from scratch or reviewing one that has been through a previous cycle, the common failure modes here are consistent — and avoidable if you know what to look for.
AI Participation & Regulatory Notice
The content on this page may be partially assisted by Artificial Intelligence (AI) to improve readability and ensure clarity.
While our team audits this content, please be aware:
- Accuracy: AI-assisted interpretations may contain nuances that differ from official MDCG guidance.
- Timeliness: Medical Device Regulations (MDR) are subject to updates. Always verify critical information against the official EUR-Lex database.
- Liability: MDR Academy provides these resources for educational purposes only. They do not constitute legal advice.