American device companies planning a European launch usually hear the phrase "technical file" and picture a binder they will assemble at the end. That expectation is the source of most of the pain that follows. Under the EU Medical Device Regulation, technical documentation is not a summary of your project — it is the project, organized in a prescribed structure, and it has to be complete, consistent, and traceable before a notified body will spend an hour on it.
The regulation specifies the contents in two annexes: the technical documentation itself, and a separate one covering post-market surveillance documentation. Notified bodies expect both, indexed against those annexes.
How this differs from a US submission
If your reference point is a 510(k), several things are genuinely different, and assuming otherwise is expensive.
- There is no predicate. Substantial equivalence is not a European concept. You demonstrate conformity with the general safety and performance requirements on their own terms, on your own clinical evidence.
- The file is living. A 510(k) is submitted and cleared; technical documentation is maintained continuously and audited repeatedly for as long as the device is on the market.
- Your quality system is in scope, audited alongside the file — inconsistencies between the two are findings.
The wider comparison is drawn out in FDA clearance vs CE marking and the regulation itself is summarized in EU MDR explained.
Section 1: Device description and specification
The opening section establishes what the device is, and everything downstream is judged against it: trade name, intended purpose stated precisely, intended patient population and users, use environment, principle of operation, risk class with the classification rule and its justification, and the Basic UDI-DI.
It also covers previous and similar generations of the device. Include accessories, configurations, sizes, and variants explicitly — a variant that appears in your catalog but not in the file is a finding waiting to happen. Two failure patterns recur: an intended purpose written as marketing copy rather than a bounded regulatory statement, and a classification justification that names a rule without walking through why it applies.
Section 2: Information supplied by the manufacturer
Labels, packaging, and the instructions for use, in every language required by the markets you sell into — device labels, the sterile barrier label, the carton, and any patient-facing material.
This section is deceptively expensive: translation, symbol layout, and consistency between the IFU and the rest of the file all take real time, and the IFU must match what your usability work validated. Our guide to writing instructions for use covers structure; for MDR you additionally need the required warnings and residual-risk information carried through from the risk file.
Section 3: Design and manufacturing information
Enough detail for a reviewer to understand the design stages, the controls applied, and how the device is actually made: the development process, design outputs showing how requirements were met, drawings and specifications for critical components, materials and sources, and the manufacturing processes with their sites.
All manufacturing sites and critical suppliers must be identified, including subcontractors performing sterilization, coating, or software development, and special processes need validation records referenced here.
If you already run US-style design controls, most of this exists — usually organized around a design history file rather than the annex structure, so the work is mapping rather than creating. Build a table that points each annex item to the document satisfying it; it is the first thing a reviewer asks for.
Section 4: The GSPR checklist
The general safety and performance requirements are the heart of the file. You produce a table — typically several dozen rows — stating for each requirement whether it applies, why if it does not, which standard or method demonstrates conformity, and which document and section holds the evidence.
| Column | What goes in it | Common mistake |
|---|---|---|
| Requirement | The full requirement text, not a paraphrase | Abbreviating so the reviewer cannot follow |
| Applicable? | Yes / No with justification for every No | Blank cells, or "N/A" with no reason |
| Method used | Harmonized standard, common specification, or your own method | Citing a standard you did not fully apply |
| Evidence | Document number, version, and section | Pointing at a folder instead of a page |
Two rules make this section survivable: reference documents by number, version, and section — never "see risk file" — and keep it current, because a checklist pointing at superseded revisions signals that the whole file is unmaintained.
Section 5: Benefit-risk analysis and risk management
The complete risk management file: plan, hazard analysis, risk estimation and evaluation, the control measures, verification that each control works, residual risk evaluation, and the overall benefit-risk determination, all under ISO 14971.
The most frequent deficiency is a risk file that lives in isolation. Every risk control must trace to a design output and a verification test, every residual risk requiring user awareness must appear in the IFU, and the benefit side must be supported by clinical evidence rather than asserted.
Section 6: Product verification and validation
Everything that proves the device works and is safe: bench performance testing against your specifications, biocompatibility under the ISO 10993 series, electrical safety and EMC, sterilization and shelf-life validation, software verification and validation with the safety classification, usability engineering with the summative study report, transport testing, and the clinical evaluation.
The clinical evaluation is where most programs stall. Literature alone is rarely enough for anything but low-risk, long-established device types, and the equivalence route to another manufacturer's device now demands contractual access to their technical documentation, which is almost never obtainable. What the report must contain is covered in the clinical evaluation report behind a CE mark. Start it early — it drives what data you collect, not the other way around.
Section 7: Post-market surveillance and PMCF
The second annex covers what happens after launch, and it must be in the file at the time of the initial assessment, not afterward. It contains the post-market surveillance plan, the method for collecting and analyzing complaint, incident, and field data, the process for vigilance reporting and field safety corrective actions, and either a periodic safety update report or a post-market surveillance report depending on the device class.
Post-market clinical follow-up sits inside this: a PMCF plan describing how you will keep confirming safety and performance in real use, or a justification for why it is not required — a hard argument to win. The resulting obligations are described in post-market surveillance. Treat the plan as a design input, because it dictates what data your device must be capable of producing.
The declaration of conformity and the pieces around it
The EU declaration of conformity is a short document the manufacturer signs, and it is what actually permits the CE mark. It identifies the manufacturer and the Basic UDI-DI, states the device and its class, names the conformity assessment route and the notified body with its certificate, references the legislation the device conforms to, and carries a dated signature. It is short because it is a promise: everything behind it must exist and be current.
Before placing a device on the EU market you will also need a notified body engagement for anything above the lowest class, an audited ISO 13485 quality system, an authorized representative established in the EU, registration in the European database with UDI assignment, and a designated person responsible for regulatory compliance. Plan roughly a year from a complete file to a certificate; the quality system requirements behind it are in ISO 13485 requirements.
Projects House builds devices with the technical documentation structure in mind from the first design review, so the European file is an index of work already done rather than a reconstruction. Tell us about your device and your target markets through the contact form.