Is 'technical file' still the correct term under EU MDR?

The MDR's own term is 'technical documentation', defined by Annexes II and III. 'Technical file' is the MDD-era name and everyone still uses it informally. Use either in conversation — but structure the content against Annex II and III, not against an old MDD technical file index.

Do Class I devices need a full technical file?

Yes. Annexes II and III apply to all device classes. For self-certified Class I devices no notified body reviews the file before CE marking, but the Declaration of Conformity asserts that it exists, and a competent authority can request it at any time.

Is there a required format or template for the technical file?

No. The MDR requires the content of Annexes II and III, presented in a clear, organised, readily searchable and unambiguous manner — but prescribes no format. Most notified bodies publish a preferred structure or expect something close to the Annex II numbering; if yours does, mirror it.

How long must the technical file be kept?

Per Article 10 of the MDR, the technical documentation must remain available to competent authorities for at least 10 years after the last device covered by it has been placed on the market — 15 years for implantable devices.

How does the EU technical file relate to the FDA's DHF and DMR?

They overlap heavily but are not the same document. The FDA's Design History File records the design process, and the Device Master Record the specifications; the EU technical file is a conformity argument addressed to a regulator. Much of the underlying evidence is shared, which is why teams maintain one body of records and generate both views from it.

EU MDR Technical File: What Goes in It (Annex II & III, Explained)

What the MDR means

"Technical file" is the nickname. Annexes II and III are the spec.

The MDR's own term is technical documentation: the body of evidence, defined in Annexes II and III of Regulation (EU) 2017/745, that demonstrates your device conforms to the regulation. "Technical file" is the old MDD name, and everyone still says it — including us. What matters is that the content follows the MDR annexes, not an MDD-era index.

Three things about it surprise teams doing this for the first time:

Every class needs one. Class III implant or self-certified Class I software — Annexes II and III apply in full. The class changes who reviews the file and when, not whether it exists.
Presentation is a regulatory requirement. Annex II demands the documentation be presented in a "clear, organised, readily searchable and unambiguous manner." A pile of PDFs with a table of contents bolted on at the end does not meet that bar, and reviewers say so.
It never closes. Annex III makes post-market surveillance part of the technical documentation itself. The file you submit for conformity assessment is the same file your post-market data flows back into, for the life of the device.

The technical file isn't a deliverable you write at the end. It's the state of your evidence, assembled continuously from day one.

Annex II

The six sections, and what reviewers look for in each.

Section	What goes in it	Watch out for
1 · Device description & specification	Intended purpose, Basic UDI-DI, classification and the Annex VIII rule that justifies it, variants and accessories, key functional elements, novel features, previous generations and similar devices on the market.	The intended purpose written here is the anchor for everything else — claims, clinical evaluation, risk file. Write it precisely; every word becomes something to evidence.
2 · Information supplied by the manufacturer	Labels on the device and its packaging, and the instructions for use — in the languages accepted by the Member States where the device is sold.	Labels and IFU are checked word-by-word against your claims and residual risks. Inconsistency here is one of the most common findings.
3 · Design & manufacturing information	The design stages applied to the device, the complete manufacturing process, and the identity of all sites where design and manufacturing are performed — including suppliers and subcontractors.	Small companies often under-document suppliers. If a subcontractor builds your PCB or hosts your software, they belong in this section.
4 · General safety & performance requirements	The GSPR matrix: which Annex I requirements apply, justification for those that don't, methods and standards used, and precise references to the evidence.	This is the section your whole file converges on — we've written a dedicated guide to building the GSPR checklist.
5 · Benefit-risk analysis & risk management	The benefit-risk analysis required by Annex I (GSPRs 1 and 8) and the results of your ISO 14971 risk management process — the risk management file, or a faithful summary that points into it.	The risk file must agree with sections 2 and 6: every residual risk disclosed in the IFU, every risk control verified in V&V.
6 · Product verification & validation	The results of all verification and validation testing: pre-clinical data, biocompatibility, electrical safety and EMC, software V&V, stability and shelf life, the clinical evaluation report with its plan, and the PMCF plan. Section 6.2 adds extra requirements for specific cases — sterile devices, measuring functions, medicinal substances, CMR/endocrine substances and more.	The largest section by volume and the one most scrutinised — see below.

Section 6, up close

Verification & validation: where small teams get caught.

Two parts of section 6 deserve special attention if you're a small company shipping your first device:

Software verification and validation. For any device that incorporates software — or is software — Annex II requires evidence describing the design and development process and validation of the software as used in the finished device, in a simulated or actual user environment, across all the hardware configurations and operating systems named in your information supplied. Unit tests alone don't satisfy this; reviewers want system-level validation in conditions that resemble real use. Your IEC 62304 lifecycle documentation is the backbone of this evidence.

Clinical evaluation. Every device needs a clinical evaluation report (per Article 61 and Annex XIV) and a post-market clinical follow-up plan — or a documented justification for why PMCF is not applicable. Under the MDR this is examined far more closely than it ever was under the MDD, and it must support each clinical claim made anywhere in the file, label or marketing material.

Annex III

Post-market surveillance: the file's living half.

Annex III folds your post-market surveillance documentation into the technical file. Three documents, depending on class:

ALL CLASSES

PMS plan

How you will proactively and systematically collect post-market data — complaints, trends, field experience, literature — and feed it back into risk management and the clinical evaluation (Article 84).

CLASS I

PMS report

A summary of post-market surveillance results and any corrective or preventive actions taken, updated when needed and available to the competent authority on request (Article 85).

CLASS IIa / IIb / III

PSUR

The Periodic Safety Update Report: post-market conclusions plus benefit-risk confirmation, updated at least every two years for Class IIa and at least annually for IIb and III (Article 86).

The practical consequence: whatever the PMS process learns has to land back in the risk management file, the clinical evaluation and — when it changes the picture — the IFU. A technical file that hasn't changed since certification is, under the MDR, a finding waiting to happen.

Organising the file

No required format — but strong expectations.

Follow the Annex II numbering unless your notified body publishes its own template, in which case follow theirs. Reviewers navigate by those section numbers.
Make it standalone. Don't cross-reference your old MDD submission or "see previous review" — notified bodies expect the MDR file to carry its evidence directly.
Every document under control. Each item in the file needs an ID, a version and an approval state, and the file's index must cite documents at the exact version reviewed. Pointers that resolve to "a newer version of something else" are the fastest way to lose a reviewer's trust.
Keep it for the long haul. Article 10 requires the documentation to stay available to competent authorities for 10 years after the last device is placed on the market — 15 for implantables. Plan storage and document control accordingly.
One body of records, many views. If you also serve the US market, most of this evidence doubles as your FDA design history file and device master record content. Maintain the records once; assemble the regulatory views from them.

Where files fail

The deficiencies that stall conformity assessments.

Internal inconsistency. The IFU claims something the clinical evaluation doesn't support; the risk file lists a control that V&V never verified; the GSPR matrix cites document versions that no longer exist. Reviewers cross-read sections against each other — most findings live in the seams between documents, not inside any one of them.
An intended purpose that drifted. The device description says one thing, the marketing claims another, the clinical evidence supports a third. Scope creep in the intended purpose quietly invalidates work across the whole file.
Software validated in the lab, not in use. Test reports that stop at unit and integration level, with no evidence of validation in a simulated or actual user environment across the supported configurations.
"Readily searchable" ignored. Thousand-page PDFs, no index, no consistent document IDs. The content may all be there; if the reviewer can't navigate it, the clock stops and the questions start.
A file frozen at submission. No PMS data flowing back in, PSURs written from scratch in a panic each cycle, the risk file untouched since certification. Annex III makes maintenance a compliance obligation, not housekeeping.

FAQ

Common questions.

Is "technical file" still the right term under the MDR?

The regulation says technical documentation, defined by Annexes II and III. "Technical file" is the MDD-era name and everyone still uses it informally — fine in conversation, as long as the structure underneath follows the MDR annexes rather than an old MDD index.

We're self-certified Class I. Do we really need the full file?

Yes. Annexes II and III apply to every class. Nobody reviews your file before you CE-mark — but your Declaration of Conformity asserts that it exists, and a competent authority can demand it at any time. Self-certified means self-evidenced.

Is there a mandatory format or template?

No. The MDR mandates the content and that it be presented in a "clear, organised, readily searchable and unambiguous manner" — the format is yours. In practice, follow the Annex II numbering or your notified body's published template if it has one.

How long do we have to keep it?

At least 10 years after the last device covered by the documentation has been placed on the market, per Article 10 — 15 years for implantable devices. That retention window outlives most tools and file shares, which is worth thinking about when you decide where the file lives.

How does this relate to the FDA's DHF and DMR?

They overlap heavily but answer different questions: the Design History File records how you designed it, the Device Master Record how to build it, and the EU technical file argues why it conforms. The underlying evidence is largely shared — maintain one body of records and generate each regulatory view from it.

The EU MDR technical file: what actually goes in it.